主题： systemd
-
主机上的 cgroups v2：检查模式并读取各单元的资源限制
现代容器运行时和 systemd 都依赖 cgroups v2（统一层级）实施内存和 CPU 限制。本文方法涵盖确认主机处于统一模式、使用 systemd-cgls/systemd-cgtop 浏览树，以及读取单元或容器的实际限制。
-
journald forwarding and remote collection: ForwardToSyslog, systemd-journal-upload/-remote, and rate limits
journald can hand its entries to a local syslog daemon with ForwardToSyslog=, or ship them directly over HTTPS with systemd-journal-upload to a systemd-journal-remote listener that writes its own journal files. Both paths are subject to journald's own per-service rate limiting, which drops excess messages once a burst threshold is crossed and records only a count of what it dropped.
-
用 systemd 定时器替代 cron：OnCalendar、Persistent= 与 RandomizedDelaySec
systemd 的 .timer 单元与 oneshot 类型的 .service 配对后，可以替代 crontab 条目，并增加停机后的补跑以及主机群中的随机时间抖动。本方法说明如何编写、验证和启用这对单元，并解释 Persistent= 和 RandomizedDelaySec= 的实际作用。
-
"Too many open files" (EMFILE) and the file-descriptor limit
EMFILE, reported as 'Too many open files', means a process hit its own limit on simultaneously open file descriptors, documented as RLIMIT_NOFILE. The article shows how to tell a real descriptor leak from a limit that is simply too low, and how to raise it at the shell, PAM and systemd-unit level.
-
.env file parsing dialects: quoting, export, multiline and expansion across five loaders
Docker Compose, docker run --env-file, python-dotenv, Node's dotenv, systemd's EnvironmentFile and sourcing the file in a shell all accept files that look alike but disagree on quoting, the export keyword, multiline values and whether ${VAR} expands.
-
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.
-
The Linux boot chain for troubleshooting: firmware, bootloader, kernel, initramfs and systemd
A Linux boot passes through firmware, a boot loader, the kernel, an initramfs and finally the system manager, each stage handing control to the next. Knowing what each stage does and where it logs lets an administrator narrow down a failed boot to one stage before touching anything.
-
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.
-
systemd rescue.target and emergency.target: entering them and getting back to normal
rescue.target starts the base system and a single-user shell; emergency.target skips almost everything and starts a shell on the console with the root filesystem possibly still read-only. Both are reached with a systemd.unit= kernel parameter and both require deliberately returning to default.target afterward.
-
Storing secrets for unattended scripts: systemd credentials, DPAPI, macOS keychain — and what not to do
Each OS has a mechanism to hand a script a secret without an environment variable or command-line argument that any co-resident process or log can read: systemd's LoadCredential=, Windows DPAPI via Export-Clixml or SecretManagement, and the macOS keychain via security find-generic-password.
-
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.
-
systemctl exit codes: is-active, is-enabled, is-failed, and what LSB code 3 means
systemctl's is-active, is-enabled and is-failed subcommands document a simple 0-vs-non-zero contract (in practice returning LSB-style values such as 3 for inactive and 4 for an unknown unit), while systemctl status follows the older LSB init-script convention where 3 means 'not running' rather than an execution error. Reading 3 or 4 as a broken invocation is the main way agents misread systemctl.
-
Duration and interval strings: ISO 8601, Go's ParseDuration, systemd, Prometheus, PostgreSQL and .NET TimeSpan
PT1H30M, 1h30m, '1h 30min' and 01:30:00 can all describe the same span of time, but each parser accepts a different alphabet of unit suffixes and rejects everything else, so a duration string copied between systems often simply fails to parse.
-
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.
-
诊断 systemd 主机的名称解析：resolvectl、resolv.conf、nsswitch，以及 getent 与 dig 的区别
在使用 systemd-resolved 的主机上，/etc/resolv.conf 通常只指向本地存根解析服务，实际的各链路 DNS 服务器应通过 resolvectl 查看，而 /etc/nsswitch.conf 决定 getent hosts 是否会查询 DNS。混淆这些层次，可以解释大多数“dig 正常，但应用不正常”的情况。
-
使用 sysctl 设置 Linux 内核参数：运行时更改与 /etc/sysctl.d
sysctl -w 更改内核参数，直到下次重启；要使更改持久化，需要在 /etc/sysctl.d/ 中放置文件，并理解 /usr/lib、/etc 和 /run 之间的加载顺序。sysctl --system 应用所有已配置的文件，并显示冲突时哪个文件胜出。
机器可读： JSON