Sujet : systemd
-
cgroups v2 on the host: checking the mode and reading per-unit resource limits
Modern container runtimes and systemd both rely on cgroups v2 (the unified hierarchy) to enforce memory and CPU limits. This methodology covers confirming the host is in unified mode, browsing the tree with systemd-cgls/systemd-cgtop, and reading a unit's or container's actual limits.
-
systemd timers as a cron replacement: OnCalendar, Persistent= and RandomizedDelaySec
A systemd .timer unit paired with a oneshot .service can replace a crontab entry while adding catch-up runs after downtime and random jitter across a fleet. This methodology writes, validates and enables such a pair and explains what Persistent= and RandomizedDelaySec= actually do.
-
Running Podman containers as systemd services with Quadlet
Quadlet lets systemd manage Podman containers directly from declarative .container unit files, replacing the deprecated podman generate systemd workflow. This methodology covers file locations for system and user services, activation, and the auto-update label.
-
Scheduled jobs compared: cron, systemd timers, launchd, Task Scheduler and AIX cron/at
Every scheduler answers one question differently: what happens to a job whose scheduled time passed while the machine was off or asleep? Comparing cron, systemd timers, launchd's calendar keys, and Windows Task Scheduler shows that only launchd catches up after sleep by default, and the others catch up only if configured to.
-
Service managers compared: systemd, launchd, the Service Control Manager, SRC and rc.d/OpenRC
Every general-purpose OS has something that starts, stops, supervises and boots services, but the commands and the persistence model differ. This reference maps start, stop, status, enable-at-boot and log access across systemd, launchd, Windows' Service Control Manager, AIX's SRC, and FreeBSD's rc.d and Alpine's OpenRC.
-
Querying the systemd journal with journalctl: unit, boot, priority, time range and JSON output
journalctl can filter the systemd journal by unit, boot, priority and time range and emit machine-readable output, but only if the journal is configured to persist across reboots. This methodology covers precise queries, persistent storage, and the size caps in journald.conf.
-
Identifying an unknown Linux host before changing anything on it
Before an agent or operator changes configuration on a Linux machine it did not build, it should establish the distribution, kernel, virtualization or container status, init system, package manager and mandatory access control state — each with one cheap, non-destructive command.
-
Editing /etc/fstab safely: UUIDs, nofail, x-systemd options and findmnt --verify
A bad /etc/fstab line can drop a system to an emergency shell on the next boot. This methodology uses UUID= instead of device names, nofail and x-systemd.device-timeout= for optional mounts, and findmnt --verify plus mount -a to test the file before rebooting.
-
Reading Linux memory pressure: free, swap, the OOM killer and OOMScoreAdjust
The 'available' column in free, not 'free', is the number that indicates real headroom, and a process killed under memory pressure leaves a record in the kernel log or journal, not a silent disappearance. This article explains what to read and how to bias which process the OOM killer picks.
-
Diagnosing name resolution on a systemd host: resolvectl, resolv.conf, nsswitch and getent versus dig
On a systemd-resolved host, /etc/resolv.conf usually only points at a local stub listener, the real per-link DNS servers live in resolvectl, and /etc/nsswitch.conf decides whether getent hosts even asks DNS. Confusing these layers explains most "dig works but the application doesn't" reports.
-
Setting Linux kernel parameters with sysctl: runtime changes versus /etc/sysctl.d
sysctl -w changes a kernel parameter until the next reboot; making it persistent means dropping a file into /etc/sysctl.d/ and understanding the load order across /usr/lib, /etc and /run. sysctl --system applies every configured file and reports which one wins on a conflict.
Lisible par machine : JSON