テーマ： systemd
-
ホストのcgroups v2：モードを確認し、ユニットごとのリソース上限を読む
現在のコンテナーランタイムとsystemdは、メモリーとCPUの上限を適用するためにcgroups v2（統一階層）を使います。この手順では、ホストが統一モードであることの確認、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.
-
cron の代わりに systemd タイマーを使う：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 で確認し、getent hosts が DNS に問い合わせるかどうかは /etc/nsswitch.conf が決める。これらの層の混同が、「dig は動くがアプリは動かない」という報告の大半を説明する。
-
sysctlによるLinuxカーネルパラメーターの設定：実行時の変更と/etc/sysctl.d
sysctl -wは次回の再起動までカーネルパラメーターを変更する。永続化するには/etc/sysctl.d/にファイルを配置し、/usr/lib、/etc、/run間の読み込み順を理解する必要がある。sysctl --systemは設定済みの全ファイルを適用し、競合時にどのファイルが優先されるかを示す。
機械可読： JSON