The large format printer at a print shop in Ghent stopped accepting jobs on a Tuesday, and the machine driving it looked perfectly healthy: the desktop was up, the network was fine, and the print spooler appeared in the task list. It was running. It was not working, and those are different questions that need different commands.
ps reports what is running; systemctl reports what is supposed to be. A process can exist and be doing nothing useful, and a service can be configured, enabled, failed and restarted six times in a minute while a list of processes shows it present each time you look. The operating system knows the difference, and the whole of this topic is learning to ask it the right question.
The four jobs it is doing while you are not looking
An operating system is not the desktop. It is the thing that decides which process gets the processor next, which one is allowed to open which file, how much memory each may hold, and what happens when two of them want the same device at the same time. None of that is visible until it goes wrong, which is why the jobs you never see it doing is the cluster that makes the rest legible.
The Ghent machine's answer came from the service manager rather than the process list.
systemctl status cups- prints
Active: failed (Result: exit-code)and the last three log lines journalctl -u cups -n 50
journalctl -u cups -n 50 prints the last fifty lines for one service, which is the difference between reading a log and reading everything the machine has ever said. The fifty lines named a permissions error on the spool directory, which somebody had moved to a shared drive the previous week.
The three numbers that explain most permission faults
Permissions on a Unix system are not a list. They are three digits, and each digit is a small sum. Four is read, two is write, one is execute, and the digit is those added together for one audience: the owner, the group, then everybody else.
chmod 644 means the owner writes and everyone reads. Six is four plus two, which is read and write for the owner. Four is read for the group and four is read for everybody. A directory needs the execute bit to be entered at all, which is why 644 on a folder produces the specific confusion of a directory that exists, is listed, and cannot be opened, and why 755 is the ordinary answer for one.
The Ghent spool directory had arrived on the shared drive with 644 and an owner who was not the print service. Two commands closed the ticket, and neither of them was a restart.
The state that cannot be killed
The other confusion worth having in advance concerns a process that will not go away. A process in D state is waiting on disk and cannot be killed, because it is not asleep in the ordinary sense: it is inside a system call that has not returned, and the signal cannot be delivered until it does. Sending it progressively more forceful signals achieves nothing and produces the belief that the machine is broken. The thing that is broken is usually underneath: a network file system that has gone away, or a disk that is failing. The process is a symptom, and the correct move is to find out what it is waiting for rather than to keep sending signals at it. On the Ghent machine the same state appeared once, on a job pointed at the shared drive after the drive had been unmounted underneath it.
Three systems, two questions
What transfers between them, and what has to be learned twice
Whether the system is in the Unix family, and whether you are likely to administer it centrally. The pair decides how much of one job carries into the next.
administered one at a time
administered centrally
It says nothing about which is better, and the cell somebody works in is chosen by their employer far more often than by them.
The three desktops, and why the choice is rarely yours
Almost nobody picks their operating system on the merits. It arrives with the job, with the hardware, or with the software that has to run, and the practical skill is being able to work on whichever one is in front of you. The command line is the part that transfers furthest: a person comfortable in what most servers run, and increasingly desktops is already most of the way to administering the Unix desktop, and administering it, and the reverse is also true.
The one that does not share the family is the desktop most organisations run, and it is where the majority of the world's support work actually happens. Its shell is PowerShell, its permissions are access control lists rather than three digits, and its central administration is a directory and a policy engine with no counterpart on the Unix side. Somebody who has only ever worked in a terminal will find that almost nothing carries across except the habit of asking the machine rather than guessing, and that habit is worth more than any of the syntax.
The Ghent shop runs all three, which is ordinary rather than unusual: the printer is driven by Linux, the design workstations are Macs, and the accounts machine is Windows because the accounting software is. Being able to move between them is the practical shape of this topic and of the machines, the networks between them, and keeping both standing.
Where people stall
The stall is the command line, and it is not the syntax. People learn a dozen commands, can move around a filesystem, and then stop, because nothing they have learned yet composes into anything. The step that unlocks the rest is realising that the output of one command is the input of the next, and that the small commands are small on purpose. Until that lands, the terminal is a slower way of clicking, which is a fair description of it and a reason to give up. After it lands, it is the only way to do the same thing to four hundred files, and that is the argument in the interface that scales past clicking.
What to open, in 2026
On any Linux made in the last decade, systemd is the service manager and journalctl is how you read what it did. It replaced init scripts and scattered text logs, which is what documentation older than about 2015 still describes, and the transition was unpopular enough that a great deal of that older advice is still the first search result.
For trying an unfamiliar system without owning it, a virtual machine is free and reversible, which is the entire argument of running another operating system inside this one. VirtualBox remains free, and on Apple hardware UTM fills the same role. Both replaced the practice of keeping a second machine under the desk to try things on.
What none of this covers is what happens when the fault is not on the machine at all, which is the question the next topic exists for and the reason its first move is to establish which layer is lying.