All jobs / IT support / sysadmin

Linux interview questions

Linux questions a IT support / sysadmin can be asked, from first job to senior. Open one to see the strongest answer and why it works.

  1. You need a tool on a Linux server and the project’s website offers a one-line install script. What do you do?

    The strongest answer: Install it from the distribution’s package manager or the vendor’s signed repository, so it is recorded, patchable and removable — a piped script is unreviewed code running with your privileges

    Why it works: Exactly. The package manager is what will tell you next year that this is installed, at which version, and how to patch it.

    • Install what the system can track.
    • Prefer the distribution or a signed repo.
    • Untracked binaries never get patched.
    • Never pipe the web into a root shell.

  2. A service on a Linux box is misbehaving. Where do you look for its logs, and how do you watch them while you reproduce the fault?

    The strongest answer: journalctl for that unit on a systemd system, plus /var/log for services that still write their own files — then follow it live while I make the fault happen, so I see the lines it produces

    Why it works: Right. Following the log while you reproduce the fault ties a symptom to a line, which is the whole trick.

    • Follow the log while you reproduce.
    • journalctl for the unit.
    • /var/log for file-based services.
    • Never clear a log to “tidy” it.

  3. A Linux user cannot write a share. You can. First read?

    The strongest answer: User, groups, mode, mount options, and whether they are who they think they are — I do not chmod 777 to test

    Why it works: Exactly. Identity then bits then mount. 777 is a hallway with the lights off.

    • Read identity, mode, mount.
    • No 777 tests.
    • Do not casual-chown.
    • Do not add root to “help.”

  4. Starting a service returns an error and it stays dead. Talk me through your next few steps.

    The strongest answer: The unit’s status for the exit code and last lines, the journal for that unit since boot, then the config it loads — usually a bad path, a permission, or the port already in use

    Why it works: Exactly — status, journal, then the config it reads. Those three cover almost every failed start.

    • Status, journal, config — in that order.
    • Read the exit code and last lines.
    • Check path, permission, port in use.
    • Auto-restart is not a diagnosis.

  5. You add a user to a Linux group so they can write to a shared folder, but they still cannot write. Why?

    The strongest answer: Their session still carries the group list it got at login, so they need a new session before it counts — then the folder’s group and mode, and setgid if new files must inherit the group

    Why it works: Right — the login session is the thing that is stale, and setgid is what stops the next file landing in the wrong group.

    • Groups are read at login.
    • Start a new session after adding.
    • Then check folder group and mode.
    • setgid keeps new files in the group.

  6. It is a busy application server and the disk has been filling for weeks; nobody has restarted anything.

    df says the filesystem is 100% full, but adding up the directories only accounts for half of it. What is going on?

    The strongest answer: Something still holds a deleted file open, so the space is not released until that process is restarted — the open handles will show it; the other usual suspect is a directory buried under a later mount point

    Why it works: Exactly. Both explanations are about what the directory walk cannot see, which is why the two numbers disagree.

    • The gap is what the walk cannot see.
    • Deleted files still held open.
    • Directories hidden under a mount.
    • Find the writer before you delete.