A Linux troubleshooting interview is not a contest to name the most commands. The useful answer shows how one observation changes the next question. TecMint’s source runs through server problems involving disk accounting, inodes, boot-time services, DNS, and a web server reachable only from localhost. The common thread is not a magic command. It is using the smallest piece of evidence that separates one cause from another.
I would answer each scenario in the same order: state what the symptom proves, name what it does not prove, run a check that narrows the gap, and explain the least disruptive fix supported by the result. That structure makes technical knowledge audible without turning the interview into a command dump.
Treat the mismatch as evidence
Consider a filesystem reported as full after a developer deletes a large log. The source’s example explains why df and du can disagree: df reports filesystem allocation, while du walks named files and directories. A process can keep writing to a file after its directory entry has been removed. The blocks remain allocated until the process closes the file, but a directory walk cannot find the nameless file.
That distinction changes the interview answer. Repeating rm does not address a file descriptor that is still open. The source suggests comparing df -h /var with a directory-size check, then using lsof +L1 to look for open files with no links. Its example shows a Java service holding a deleted log open. The relevant conclusion is not “the disk tool is wrong.” It is “the filesystem and directory walk are measuring different things.”
The source offers two remedies with different operational costs: restart the service to close the file, or truncate the process’s open file descriptor when a restart is not possible. It also says to prefer truncating a busy log over deleting it and to check log rotation behavior. In an interview, I would state the safer operational constraint before suggesting a command that changes a live process. The goal is to explain why the evidence points to the remedy, not to sound decisive at any cost.
Separate bytes from file counts
A different symptom can look similar: an application reports “No space left on device,” while the disk still has room. In the source’s inode scenario, the missing resource is not data blocks but inodes (filesystem records that hold file metadata). A filesystem can run out of those records while plenty of byte capacity remains.
The first distinction is between df -h, which reports space in human-readable units, and df -i, which reports inode use. If inode use is exhausted, the next question is where the file count is concentrated. TecMint demonstrates counting inodes by directory, then identifies a large pile of PHP session files in the example. It warns that expanding a wildcard across a very large set can exceed the shell’s argument limit, and shows find as a way to delete older files without constructing one enormous argument list.
That example contains a useful interview signal: do not stop at making the error disappear. The source points to a cleanup job, such as PHP session garbage collection or a systemd-tmpfiles rule, as the underlying mechanism to repair. It also distinguishes ext4, whose inode count is fixed at filesystem creation, from XFS, which allocates inodes dynamically. Those are source-specific details, so I would use them only when the scenario’s filesystem is known. Otherwise, first ask which filesystem is in use.
The safest spoken answer separates diagnosis from cleanup. Find the directory that owns the count, identify which files are safe to remove, and repair the process that should have removed them. Deleting files before confirming their role can replace a capacity problem with an application problem.
Ask why the service behaves differently after boot
A service that works when started manually but fails after reboot has not necessarily become unreliable. The manual start and the boot sequence may happen under different conditions. TecMint’s example first checks whether the service is enabled to start at boot. If it is enabled, the source recommends reading the current boot’s journal for the unit and looking for the actual failure message.
The example log says the application tried to reach a network address before the network was available. That observation matters: it points to ordering, not to a bad application binary. The source notes that After=network.target means the network stack has started, but does not guarantee a usable connection. For a service that needs working network connectivity, it recommends ordering around network-online.target instead.
There is a second operational lesson in the fix. Rather than editing a packaged unit file that a package update could overwrite, the source uses a drop-in override. It then reloads systemd and enables the service. I would describe that as a maintainability choice: keep the local change separate from the vendor-provided file, and validate the configuration path before assuming the unit is fixed.
Trace network failures one layer at a time
A server that can reach an IP address but cannot resolve a host name points toward DNS. TecMint distinguishes two messages: “Name or service not known” indicates an answer saying the name does not exist, while “Temporary failure in name resolution” usually means the DNS server could not be reached. The next step is to inspect which resolver the machine is using, not to change the web server or firewall before the evidence calls for it.
The source’s examples differ by distribution. On Rocky Linux, AlmaLinux, and RHEL, it says NetworkManager writes the real DNS addresses into /etc/resolv.conf. On Ubuntu, that file points to the local systemd-resolved stub, so resolvectl status reveals the upstream servers. The article then tests the DNS server directly with dig. If a direct query returns addresses, attention shifts to local resolver configuration. If it times out, the DNS service or path to it needs investigation.
The other network scenario starts with a narrower clue: Nginx answers on localhost, but a remote machine cannot load the site. The source says to distinguish connection refused, no route to host, and timeout, because those messages point to different stages of the path. On the server, ss -tlnp shows the listening address. A listener bound only to 127.0.0.1 accepts local connections, not traffic arriving on the server’s network address. Searching the Nginx configuration for its listen directive then identifies where that binding is set. The source recommends checking the configuration with nginx -t before reloading it.
I would not jump straight from “remote browser failed” to “open the firewall.” First establish whether the service is listening on an address the remote client can reach. Then test the configuration and reload only after it passes. That order keeps a firewall change from masking a binding problem.
Make the reasoning easy to follow
In an interview, a concise answer can still show depth. Say what you observed, identify what that observation rules out, and choose one check that separates the remaining possibilities. Then state how you would limit risk while applying the fix. A five-part checklist keeps the response grounded:
- Name the symptom. Repeat the important mismatch or error, not the whole prompt.
- Identify the layer. Filesystem allocation, inode count, boot ordering, DNS, or listening address.
- Choose one discriminating check. Explain what each likely result would mean.
- Protect the live service. Prefer a reversible or lower-impact change when the source supports one.
- Verify the result. Recheck the original symptom after the fix.
That checklist is advice, not a claim about what every interviewer expects. It is a way to make the source’s scenarios easier to reason through under pressure. If a prompt gives an unfamiliar system detail, ask for it rather than silently substituting a familiar default.
Trade-offs
The quickest-looking fix is not always the safest one. Restarting a service may release an open deleted file, but the source explicitly gives truncation through the file descriptor as an alternative when a restart cannot happen during business hours. Deleting a large number of files may clear inode pressure, but the source also makes clear that the cleanup mechanism matters. Editing a network listener can restore remote access, but a configuration test should come first.
There is a balance between thoroughness and noise. Listing every possible cause makes an answer sound uncertain; choosing a fix before a check makes it sound careless. The useful middle is a short hypothesis, one targeted test, and a clear branch for each result. I would rather hear “this result would move me to resolver configuration” than a list of five commands with no explanation.
What I would tell past me
Do not memorize the command before you understand the symptom. A deleted file still held open, an exhausted inode table, a service starting before its dependency, a DNS failure, and a localhost-only listener are different problems even when each appears as “the server is broken.” Name the layer, gather the next useful observation, and let that evidence earn the fix.