`systemctl stop backup.service` appears to hang for a minute and a half, then returns, and the journal records that the process was killed. What did systemd do?
LPIC-1 Exam 101-500, objective 101. System architecture hard
Machine-checked — no person has signed for it. This question was read against the source cited below by an automated pass, which found no contradiction. That is a weaker claim than it sounds: the same kind of process wrote the question, so it can confirm its own mistake.
Treat it as a good draft rather than as settled fact, and read the source below before you rely on it. It is not used in mock exams here — only questions a person has signed for are.
How these questions are written — where each question comes from, what the verification ledger records, and what happens when one is found wrong.
The options
Correct It sent SIGTERM, waited for TimeoutStopSec to expire, then sent SIGKILL
Correct. That is the default stop sequence, and the default timeout of ninety seconds explains the delay before the kill.
Not correct It sent SIGKILL immediately and then waited for the process's children to exit
Wrong. An immediate SIGKILL would have returned at once and would have given the service no opportunity to shut down cleanly, which is not what stopping a unit means.
Not correct It sent SIGHUP, which the service ignored, and then gave up without killing anything
Wrong. SIGHUP is conventionally a reload signal, and it is not the default stop signal. Systemd also does not give up: the journal entry in the stem shows a kill did happen.
Not correct It sent SIGSTOP, so the process is suspended rather than terminated
Wrong. SIGSTOP suspends a process without ending it, and it cannot be part of a stop sequence because a stopped process would never exit.
Why
Stopping a unit is a two-phase operation: the signal named by KillSignal, SIGTERM by default, goes to the unit's processes, and if any are still alive when TimeoutStopSec expires the signal named by FinalKillSignal, SIGKILL, follows. The timeout defaults to DefaultTimeoutStopSec in /etc/systemd/system.conf, ninety seconds on most distributions, and a unit file may set its own. This is the same discipline to apply by hand: SIGTERM first so the process can flush and release resources, SIGKILL only when it has demonstrably refused, because SIGKILL can be neither caught nor handled.
Where this comes from
- Cited
- manual page systemd.kill(5)
Practise this
Reading one question is not practice. The trainer will draw a short set from objective 101 and space the ones you get wrong.
More questions on this objective
- You have a module file for a network driver on disk but the driver is not loaded. Which command reports the module's description, license, its dependencies and the parameters it accepts, without loading it into the kernel? machine-checked
- A module was loaded together with several modules it depends on. Which command unloads that module and then also unloads the dependencies that are left with a use count of zero? machine-checked
- You are filing a hardware bug report and the maintainer asks for the raw PCI vendor and device ID numbers rather than the human-readable names lspci normally prints. Which lspci option produces the numeric IDs? machine-checked
- A USB device is not getting the device node you expect. You want to watch, live, the kernel uevents and the resulting udev events as you unplug and replug it. Which command does that? machine-checked
- On a traditional BIOS PC, the firmware has completed its power-on self test and selected the hard disk as the boot device. What happens next? machine-checked
- A systemd-based machine fails during a normal boot because a service hangs. At the boot loader menu you want to edit the kernel command line for this one boot so the system comes up in single-user rescue mode instead. Which parameter do you append? machine-checked