--- tags: - linux - l1 - flashcard-deck - linux-systemd --- [Portal](../../../../library/portal/index.md) | **Level:** [L1: Foundations](../../../../library/portal/levels.md) | **Topics:** [systemd](../../../../library/portal/topics.md) | **Domain:** Linux id category difficulty tags question answer source_path linux-systemd/0bf2bf7a1ecf linux-systemd medium linux, systemd How to start or stop a service? To start a service: `systemctl start `\nTo stop a service: `systemctl stop `\n\nRemember: systemd: status, start/stop/restart, enable/disable, daemon-reload.\n\nGotcha: After editing unit files, always `daemon-reload` before restart.\n\nExample: `systemctl restart nginx` = stop + start. `systemctl reload nginx` = send SIGHUP (re-read config without downtime).\n\nRemember: start/stop/restart affect running state. enable/disable affect boot state. They are independent axes. projects/knowledge/interview/linux/172-how-to-start-or-stop-a-service.txt linux-systemd/36d8ea84009c linux-systemd medium linux, systemd, services, dependencies WantedBy vs RequiredBy? Both create dependencies when enabled.\n\n- WantedBy: soft dependency (`.wants`)\n- RequiredBy: hard dependency (`.requires`)\n\nRemember: systemd: status, start/stop/restart, enable/disable, daemon-reload.\n\nGotcha: After editing unit files, always `daemon-reload` before restart.\n\nExample: WantedBy=multi-user.target means start this service when multi-user.target is reached — the most common boot target.\n\nRemember: WantedBy goes in [Install] section. Wants/Requires go in [Unit] section. Different contexts. projects/knowledge/interview/linux/546-wantedby-vs-requiredby.txt linux-systemd/640120b09c3c linux-systemd hard linux, systemd, services, troubleshooting A service starts manually but fails under systemd. What are the possible causes? systemd runs services in a different execution context than interactive shells.\n\nCommon causes:\n\n1. Missing environment variables\n - No ~/.bashrc, ~/.profile sourcing\n - PATH may be minimal\n - Custom vars not set\n - Fix: Environment= or EnvironmentFile=\n\n2. No TTY\n - Service has no controlling terminal\n - Interactive prompts hang forever\n - Fix: StandardInput=tty or redesign service\n\nRemember: systemd: status, start/stop/restart, enable/disable, daemon-reload.\n\nGotcha: After editing unit files, always `daemon-reload` before restart. projects/knowledge/interview/linux/507-service-manual-ok-systemd-fail.txt linux-systemd/72baf2188b1d linux-systemd easy linux, cron, systemd, scheduling How do you schedule tasks periodically? "Linux provides several tools for scheduling periodic tasks:\n\n1. cron - Traditional task scheduler\n - Edit with: crontab -e\n - Format: minute hour day month weekday command\n - Example: 0 2 * * * /backup.sh (runs at 2 AM daily)\n - System cron: /etc/crontab, /etc/cron.d/\n\n2. systemd timers - Modern alternative\n - More flexible than cron\n - Can depend on other units\n - Better logging via journald\n\n3. at - One-time scheduled tasks\n - Example: echo ""/backup.sh"" | at 2am tomorrow\n\n4. anacron - For machines not always on\n - Runs missed jobs when system starts" projects/knowledge/interview/linux/329-how-do-you-schedule-tasks-periodically.txt linux-systemd/74c72b12554b linux-systemd medium linux, system systemd vs SysVinit - what matters operationally? Key operational differences:\n\n* **Dependency graph**: systemd understands service dependencies; SysVinit uses numbered scripts\n* **Parallel startup**: systemd starts independent services concurrently; SysVinit is sequential\n* **Unit isolation**: systemd can sandbox services with cgroups, namespaces\n* **journald integration**: Structured logging vs scattered log files\n* **cgroups**: Resource limits and tracking built-in\n\nIt's easier to debug failures with `systemctl status` + `journalctl -u` than parsing rc scripts and scattered logs.\n\nRemember: systemd: status, start/stop/restart, enable/disable, daemon-reload.\n\nGotcha: After editing unit files, always `daemon-reload` before restart. projects/knowledge/interview/linux/447-systemd-vs-sysvinit-what-matters-operationally.txt linux-systemd/9a132fca76b4 linux-systemd medium linux, system How do you safely modify vendor unit files? Never edit vendor unit files directly in `/usr/lib/systemd/system/`. Use overrides:\n\n```bash\nsystemctl edit myservice\n```\n\nThis creates `/etc/systemd/system/myservice.service.d/override.conf` where you can add or override directives.\n\nBenefits:\n* Keeps upgrades clean - package updates won't overwrite your changes\n* Changes are diffable and auditable\n* Easy to see what was customized vs stock\n* Can be managed by configuration management tools\n\nTo completely replace a unit, copy it to `/etc/systemd/system/` instead.\n\nRemember: Types: .service, .socket, .timer, .mount, .target. Most common: .service, .timer. projects/knowledge/interview/linux/449-how-do-you-safely-modify-vendor-unit-files.txt linux-systemd/a95de5273483 linux-systemd easy linux, control-flow, kernel, processes What is systemd and how does it manage Linux services? Systemd is a daemon (System 'd', d stands for daemon).\n\nA daemon is a program that runs in the background without direct control of the user, although the user can at any time\ntalk to the daemon.\n\nsystemd has many features such as user processes control/tracking, snapshot support, inhibitor locks..\n\nIf we visualize the unix/linux system in layers, systemd would fall directly after the linux kernel. \nHardware -> Kernel -> Daemons, System Libraries, Server Display.\n\nRemember: systemd: status, start/stop/restart, enable/disable, daemon-reload.\n\nGotcha: After editing unit files, always `daemon-reload` before restart.\n\nName origin: The d in systemd stands for daemon. Lennart Poettering and Kay Sievers created it in 2010 for Fedora.\n\nRemember: systemd is PID 1 — the first process the kernel starts. It manages all other services. projects/knowledge/interview/linux/171-what-is-systemd.txt linux-systemd/b64b3e0af1f8 linux-systemd easy linux, systemd, troubleshooting, services How do you debug a service that won't start? Check status, logs, and the unit definition, then validate dependencies and runtime environment.\n- `systemctl status ` for exit codes and recent log snippets.\n- `journalctl -u -e` for full logs and earlier failures.\n- `systemctl cat ` to inspect unit file, overrides, and ExecStart.\n- `systemctl show -p Environment,WorkingDirectory,ExecStart ` to confirm runtime settings.\n- Verify permissions, missing files, or port conflicts; reproduce with `ExecStart` manually if needed.\n\nRemember: systemd: status, start/stop/restart, enable/disable, daemon-reload.\n\nGotcha: After editing unit files, always `daemon-reload` before restart. projects/knowledge/interview/linux/545-debug-service-wont-start.txt linux-systemd/bb3770c5ade3 linux-systemd medium linux, systemd, administration, production, safety Explain the difference between systemd inhibitors, systemd-inhibit, and how to prevent accidental shutdowns in production. "Inhibitors are systemd's mechanism to delay or block system power state changes.\n\nUsing systemd-inhibit:\n- `systemd-inhibit --what=shutdown --who=""maintenance"" --why=""Patching in progress"" sleep infinity`\n- Blocks shutdown/reboot until the process exits or is killed\n\nInhibitor targets (--what options):\n- shutdown - block poweroff/reboot\n- sleep - block suspend/hibernate\n- idle - block automatic idle action\n- handle-power-key - block power button action\n- handle-suspend-key - block suspend button"\n\nRemember: systemd: status, start/stop/restart, enable/disable, daemon-reload.\n\nGotcha: After editing unit files, always `daemon-reload` before restart. projects/knowledge/interview/linux/512-systemd-inhibitors-prevent-shutdown.txt linux-systemd/bb56b987569c linux-systemd easy linux, logging, dmesg, journalctl, systemd Explain the purpose of dmesg vs journalctl. "Both show system logs but from different sources and with different scope.\n\ndmesg:\n- Reads the kernel ring buffer directly\n- Contains only kernel messages\n- Hardware detection, driver loading, kernel errors\n- Ring buffer = fixed size, older messages overwritten\n- Works without systemd\n- Command: `dmesg`, `dmesg -T` (human timestamps), `dmesg -w` (follow)\n- Useful for: boot issues, hardware problems, driver errors"\n\nExample: `journalctl -u nginx --since '1 hour ago'`. `-f`=follow, `-p err`=filter.\n\nRemember: journalctl = systemd log viewer. Binary format, fast, needs journalctl to read. projects/knowledge/interview/linux/528-dmesg-vs-journalctl.txt linux-systemd/c653bed58538 linux-systemd medium linux, boot-process, kernel, systemd, fundamentals Walk through the Linux Boot Process (High Level). The boot process has five main stages from power-on to login prompt.\n\n1. BIOS/UEFI (Firmware):\n - Power-On Self-Test (POST)\n - Hardware initialization\n - Locates bootable device\n - Loads bootloader from MBR/GPT\n\n2. Bootloader (GRUB2):\n - Displays boot menu (optional)\n - Loads kernel image and initramfs into memory\n - Passes kernel parameters\n - Transfers control to kernel\n\nRemember: systemd: status, start/stop/restart, enable/disable, daemon-reload.\n\nGotcha: After editing unit files, always `daemon-reload` before restart. projects/knowledge/interview/linux/532-linux-boot-process.txt linux-systemd/cc8039c273ff linux-systemd medium linux, systemd How to check the status of a service? `systemctl status `\n\nRemember: systemd: status, start/stop/restart, enable/disable, daemon-reload.\n\nGotcha: After editing unit files, always `daemon-reload` before restart.\n\nRemember: `systemctl status` shows: loaded state, active state, PID, memory usage, last log lines. One command for a full health snapshot.\n\nExample: Green dot = active. Red dot = failed. Yellow = activating/deactivating. projects/knowledge/interview/linux/173-how-to-check-the-status-of-a-service.txt linux-systemd/cd07b3935938 linux-systemd easy linux, boot-process, kernel, systemd Walk through the Linux boot process. BIOS/UEFI → GRUB → kernel + initramfs → hardware init → root mount → PID 1 (systemd) → targets/services.\n\nRemember: systemd: status, start/stop/restart, enable/disable, daemon-reload.\n\nGotcha: After editing unit files, always `daemon-reload` before restart.\n\nRemember: Boot sequence mnemonic: BIG GRUB Kernel Init Systemd Targets — BIOS/UEFI, GRUB, Kernel, initramfs, systemd, targets.\n\nGotcha: If initramfs is missing or corrupt, the kernel panics before reaching systemd. projects/knowledge/interview/linux/549-linux-boot-process-concise.txt linux-systemd/ecdb97196941 linux-systemd hard linux, systemd, services, process-management "A systemd unit shows ""active (running)"" but the actual service process is dead. How?" "This happens with Type=simple when the main process exits but systemd doesn't know.\n\nRoot cause:\n- Type=simple assumes first spawned process IS the service\n- If that process forks and exits, systemd thinks it's still running\n- Parent PID gone, children orphaned, systemd unaware\n\nCommon scenarios:\n\n1. Daemonizing services with Type=simple\n - Service double-forks (old-school daemon pattern)\n - Original PID exits immediately\n - systemd: ""yep, started successfully!""\n - Actual service: running under PID 1"\n\nRemember: systemd: status, start/stop/restart, enable/disable, daemon-reload.\n\nGotcha: After editing unit files, always `daemon-reload` before restart. projects/knowledge/interview/linux/508-systemd-active-running-dead.txt linux-systemd/f23ad22929b4 linux-systemd medium linux, logging, systemd On a system which uses systemd, how would you display the logs? `journalctl` — the systemd journal viewer. It displays logs from all systemd units, the kernel, and other sources. Filter by unit with `-u`, by time with `--since/--until`, or follow live with `-f`.\n\nRemember: systemd: status, start/stop/restart, enable/disable, daemon-reload.\n\nGotcha: After editing unit files, always `daemon-reload` before restart.\n\nRemember: journalctl key flags: -u (unit), -f (follow), -b (current boot), -p (priority), --since/--until (time range).\n\nExample: `journalctl -u nginx -p err --since '1 hour ago'` — show nginx errors from the last hour. projects/knowledge/interview/linux/174-on-a-system-which-uses-systemd-how-would-you-displ.txt linux-systemd/a1b2c3d4e5f6 linux-systemd easy systemd, unit-files, paths Where do admin-override unit files live, and why do they take precedence over vendor unit files? Admin overrides live in /etc/systemd/system/. Vendor unit files live in /usr/lib/systemd/system/. Admin overrides win because /etc/systemd/system/ has higher priority in the systemd unit file search path.\n\nRemember: Types: .service, .socket, .timer, .mount, .target. Most common: .service, .timer. training/library/topics/linux-ops-systemd/primer.md linux-systemd/b2c3d4e5f6a7 linux-systemd easy systemd, targets, runlevels What systemd target replaces traditional runlevel 3, and what does it provide? multi-user.target replaces runlevel 3. It provides a non-graphical multi-user system with networking and all standard services running.\n\nRemember: Targets replaced runlevels. multi-user≈3, graphical≈5. training/library/topics/linux-ops-systemd/primer.md linux-systemd/c3d4e5f6a7b8 linux-systemd easy systemd, journalctl, logs How do you view only the logs for a specific systemd service using journalctl? Use journalctl -u . For example, journalctl -u nginx.service shows only nginx logs. Add --since or --follow for time filtering or live tailing.\n\nExample: `journalctl -u nginx --since '1 hour ago'`. `-f`=follow, `-p err`=filter.\n\nRemember: journalctl = systemd log viewer. Binary format, fast, needs journalctl to read. training/library/topics/linux-ops-systemd/primer.md linux-systemd/d4e5f6a7b8c9 linux-systemd medium systemd, dependencies, wants-requires What is the difference between Wants= and Requires= in a systemd unit file? Wants= is a soft dependency: if the wanted unit fails to start, the depending unit still starts. Requires= is a hard dependency: if the required unit fails, the depending unit also fails to start. Wants= is preferred for most cases to avoid cascading failures.\n\nRemember: Types: .service, .socket, .timer, .mount, .target. Most common: .service, .timer. training/library/topics/linux-ops-systemd/primer.md linux-systemd/e5f6a7b8c9d0 linux-systemd medium systemd, override, daemon-reload How do you safely customize a vendor-provided systemd unit file without editing it directly? Use systemctl edit to create a drop-in override file at /etc/systemd/system/.d/override.conf. Use systemctl edit --full to create a full replacement copy. After any manual edit, run systemctl daemon-reload.\n\nRemember: Types: .service, .socket, .timer, .mount, .target. Most common: .service, .timer. training/library/topics/linux-ops-systemd/primer.md linux-systemd/f6a7b8c9d0e1 linux-systemd medium systemd, systemctl, commands What command enables a service to start at boot AND starts it immediately in one step? systemctl enable --now . The --now flag combines enable (creates symlinks for boot) and start (activates the service immediately) into a single command.\n\nRemember: enable=boot(symlink), start=now, enable --now=both. "enable=future, start=present." training/library/topics/linux-ops-systemd/primer.md linux-systemd/a7b8c9d0e1f2 linux-systemd medium systemd, cgroups, resources How does systemd enforce resource limits on services? systemd uses cgroups (control groups). Every service runs in its own cgroup slice, which allows systemd to enforce CPU, memory, and I/O limits using directives like CPUQuota=, MemoryMax=, and IOWeight= in the unit file's [Service] section.\n\nRemember: systemd: status, start/stop/restart, enable/disable, daemon-reload.\n\nGotcha: After editing unit files, always `daemon-reload` before restart. training/library/topics/linux-ops-systemd/primer.md linux-systemd/b8c9d0e1f2a3 linux-systemd medium systemd, systemd-analyze, boot What command would you use to debug slow boot times and identify which units are taking the longest? systemd-analyze blame lists units by startup time. systemd-analyze critical-chain shows the critical path of the boot sequence. systemd-analyze plot > boot.svg generates a visual SVG timeline of the entire boot.\n\nRemember: systemd: status, start/stop/restart, enable/disable, daemon-reload.\n\nGotcha: After editing unit files, always `daemon-reload` before restart. training/library/topics/linux-ops-systemd/primer.md linux-systemd/c9d0e1f2a3b4 linux-systemd hard systemd, boot-sequence, pid1 Describe the simplified boot sequence from firmware to running services in a systemd-based system. firmware -> bootloader -> kernel -> initramfs -> systemd (PID 1) -> default.target (usually multi-user.target or graphical.target) -> dependency tree of units. systemd as PID 1 manages the entire service dependency tree from that point.\n\nRemember: systemd: status, start/stop/restart, enable/disable, daemon-reload.\n\nGotcha: After editing unit files, always `daemon-reload` before restart. training/library/topics/linux-ops-systemd/primer.md linux-systemd/d0e1f2a3b4c5 linux-systemd hard systemd, dependencies, ordering What is the difference between After=/Before= and Wants=/Requires= in systemd unit files? After= and Before= control ordering only: they determine the sequence in which units start but do not create a dependency. Wants= and Requires= create actual dependencies (pull in units) but do not control order. To both require a unit and ensure it starts first, you need both Requires= and After= together.\n\nRemember: Types: .service, .socket, .timer, .mount, .target. Most common: .service, .timer. training/library/topics/linux-ops-systemd/primer.md linux-systemd/e1f2a3b4c5d6 linux-systemd hard systemd, daemon-reload, unit-files Why must you run systemctl daemon-reload after manually editing a unit file, and what happens if you forget? daemon-reload tells systemd to re-read all unit files from disk. If you forget, systemd continues using the cached in-memory version of the unit file, so your changes have no effect. systemd will log a warning that unit files have changed on disk and suggest running daemon-reload.\n\nRemember: Types: .service, .socket, .timer, .mount, .target. Most common: .service, .timer. training/library/topics/linux-ops-systemd/primer.md linux-systemd/8a2e5f6e7d69 linux-systemd medium linux, system How to reload PostgreSQL after configuration changes? Solution 1:\n\n```bash\nsystemctl reload postgresql\n```\n\nSolution 2:\n\n```\nsu - postgres\n/usr/bin/pg_ctl reload\n```\n\nSolution 3:\n\n```\nSELECT pg_reload_conf();\n```\n\nRemember: systemd: status, start/stop/restart, enable/disable, daemon-reload.\n\nGotcha: After editing unit files, always `daemon-reload` before restart. projects/knowledge/interview/linux/075-how-to-reload-postgresql-after-configuration-chang.txt --- ## Wiki Navigation ### Related Content - [Case Study: Systemd Service Flapping](../../../../library/case-studies/linux_ops/systemd-service-flapping/README.md) (Case Study, L1) — systemd - [Cron & Job Scheduling](../../../../library/topics/cron-scheduling/index.md) (Topic Pack, L1) — systemd - [Deep Dive: Linux Boot Sequence](../../../../library/deep-dives/linux.boot.sequence.md) (deep_dive, L2) — systemd - [Deep Dive: Systemd Architecture](../../../../library/deep-dives/systemd.architecture.md) (deep_dive, L2) — systemd - [Deep Dive: Systemd Service Design Debugging and Hardening](../../../../library/deep-dives/systemd.service.design.debugging.and.hardening.md) (deep_dive, L2) — systemd - [Deep Dive: Systemd Timers Journald Cgroups and Resource Control](../../../../library/deep-dives/systemd.timers.journald.cgroups.and.resource.control.md) (deep_dive, L2) — systemd - [Deep Dive: Systemd Units Dependencies and Ordering](../../../../library/deep-dives/systemd.units.dependencies.and.ordering.md) (deep_dive, L2) — systemd - [LPIC / LFCS Exam Preparation](../../../../library/topics/lpic-lfcs/index.md) (Topic Pack, L2) — systemd - [Linux Boot Process](../../../../library/topics/linux-boot-process/index.md) (Topic Pack, L1) — systemd - [Linux Logging](../../../../library/topics/linux-logging/index.md) (Topic Pack, L1) — systemd