systemctl
systemdPackage: systemd
Drives systemd units: start, stop, enable at boot, read the state. status says what is happening now, is-enabled what will happen at the next boot; those are two different questions.
What its options do in the lessons
From the same glossary the lessons render under their commands, so the two cannot disagree.
systemctl --now- With
enableordisable, also acts now:enable --nowenables at boot *and* starts the service immediately. systemctl --failed- Lists only the units in a failed state.
systemctl --no-pager- Opens no interactive pager for long output such as
systemctl status. In a script with no terminal, without it the pager waits for a keypress and the run hangs. systemctl --all- Includes inactive units, which the default listing leaves out.
systemctl --type- Restricts to one unit type (
--type=service). systemctl --state- Restricts to one state (
--state=failed). systemctl --quiet- Prints nothing and answers through the exit code alone. That is what makes
is-active --quietusable in anif. systemctl --plain- Prints a plain list rather than a tree.
systemctl --no-legend- Drops the header and summary, so the output can be read by a script.
systemctl -P- Like
-p, but prints the value alone, without the leadingName=. The form for scripts, where you want the value and nothing else. systemctl -n- How many journal lines
systemctl statusshows at the bottom of its output. systemctl --after- With
list-dependencies: the units this one waits for — what must start *before* it. Ordering, not dependency. systemctl --before- The reverse of
--after: the units that wait for this one. systemctl --reverse- With
list-dependencies: what depends on this unit, rather than what it depends on. The question to ask before stopping something. systemctl --drop-in- With
edit: names the drop-in file instead of the defaultoverride.conf. Useful for keeping two independent tweaks apart under<unit>.d/. systemctl --full- With
edit: copies the whole unit into/etcinstead of a drop-in. You stop receiving the package’s fixes from then on — almost always the wrong choice. systemctl --runtime- The change does not survive a reboot: it is written under
/run. For trying a setting before committing to it. systemctl --version- The installed systemd version — which matters because some directives only exist from a given version.
systemctl -p- Shows only the named property of the unit (
-p MainPID).
Lessons that teach it
- Signals, and why kill -9 is the last resortLinux Fundamentals
- Reading a status, and the four verbsManaging services with systemd
- Units, targets and what depends on whatManaging services with systemd
- Disabling a service is not stopping itManaging services with systemd
- Your first systemd unitManaging services with systemd
- Configuration and secrets a unit can readManaging services with systemd
- Changing a packaged unit without losing your changeManaging services with systemd
- Restart policies, and the crash loop they hideManaging services with systemd
- The exposure score is not a verdictManaging services with systemd
- Moving SSH to key authenticationUsers, sudo and SSH access
- Where a file's permissions come fromUsers, sudo and SSH access
- Works on the server, refused from outsideNetworking: how your server is reached
- Your first server blockHosting a web application with Nginx
- Reading the access log: what one line already provesHosting a web application with Nginx
- Reverse proxying a Node applicationHosting a web application with Nginx
- Ninety days, and nothing will warn youHosting a web application with Nginx
- Which server block answers, and why the wrong site sometimes doesHosting a web application with Nginx
- The limits that refuse: 413 and 504Hosting a web application with Nginx
- The headers you think you setHosting a web application with Nginx
- Scheduling a task: cron or a systemd timerBash scripting for administrators
- When the previous run has not finishedBash scripting for administrators
- A script you can run twiceBash scripting for administrators
- Rebuilding the whole machine, in the right orderBackups and restores
- The undo you schedule before you need itFirewall and hardening
- The periodic checkFirewall and hardening
- Hardening the SSH daemon without locking yourself outFirewall and hardening
- Controlling log growthMonitoring a server
- An automated check that is worth havingMonitoring a server
- Getting the alert to a humanMonitoring a server
- Trends, not instantsMonitoring a server
- What an output proves, and what "success" does notDiagnosing a failure: what each output proves
- Revealed is not caused: dating the fault rather than the symptomDiagnosing a failure: what each output proves
- How wide a fix may be, and the record it leavesDiagnosing a failure: what each output proves
- What the fix proved, and what expired on its ownDiagnosing a failure: what each output proves
- Installing Docker: the official repository, not Ubuntu'sDocker: containers for hosting a Node application
- The log file nothing is rotatingDocker: containers for hosting a Node application
- What reaches the server: source, artefact or imageDeploying: releases, the switch and rolling back
- Releases and a symlink: the switch as one operationDeploying: releases, the switch and rolling back
- Verify before declaring success, and what a rollback does not undoDeploying: releases, the switch and rolling back
- Roles and pg_hba.conf: why psql gets in and the application is refusedAdministering PostgreSQL: access, connections and growth
- A hundred connections, and the arithmetic that exceeds themAdministering PostgreSQL: access, connections and growth
- Reachable from elsewhere: four gates, four different refusalsAdministering PostgreSQL: access, connections and growth
- pg_wal fills, and something is holding itAdministering PostgreSQL: access, connections and growth
- Finding the slow queries, not the slow momentAdministering PostgreSQL: access, connections and growth
- The build, step by stepThe capstone: from repository to production
- The release that breaks: roll back first, diagnose secondThe capstone: from repository to production
- The five proofs: demonstrate, do not assertThe capstone: from repository to production
