Skip to content

Linux Systemd

← Back to all decks

42 cards β€” 🟒 8 easy | 🟑 14 medium | πŸ”΄ 5 hard

🟒 Easy (8)

1. How do you schedule tasks periodically?

Show answer Linux provides several tools for scheduling periodic tasks:

1. cron - Traditional task scheduler
- Edit with: crontab -e
- Format: minute hour day month weekday command
- Example: 0 2 * * * /backup.sh (runs at 2 AM daily)
- System cron: /etc/crontab, /etc/cron.d/

2. systemd timers - Modern alternative
- More flexible than cron
- Can depend on other units
- Better logging via journald

3. at - One-time scheduled tasks
- Example: echo "/backup.sh" | at 2am tomorrow

4. anacron - For machines not always on
- Runs missed jobs when system starts

2. What is systemd and how does it manage Linux services?

Show answer Systemd is a daemon (System 'd', d stands for daemon).

A daemon is a program that runs in the background without direct control of the user, although the user can at any time
talk to the daemon.

systemd has many features such as user processes control/tracking, snapshot support, inhibitor locks..

If we visualize the unix/linux system in layers, systemd would fall directly after the linux kernel.
Hardware -> Kernel -> Daemons, System Libraries, Server Display.

Remember: systemd: status, start/stop/restart, enable/disable, daemon-reload.

Gotcha: After editing unit files, always `daemon-reload` before restart.

Name origin: The d in systemd stands for daemon. Lennart Poettering and Kay Sievers created it in 2010 for Fedora.

Remember: systemd is PID 1 β€” the first process the kernel starts. It manages all other services.

3. How do you debug a service that won't start?

Show answer Check status, logs, and the unit definition, then validate dependencies and runtime environment.
- `systemctl status ` for exit codes and recent log snippets.
- `journalctl -u -e` for full logs and earlier failures.
- `systemctl cat ` to inspect unit file, overrides, and ExecStart.
- `systemctl show -p Environment,WorkingDirectory,ExecStart ` to confirm runtime settings.
- Verify permissions, missing files, or port conflicts; reproduce with `ExecStart` manually if needed.

Remember: systemd: status, start/stop/restart, enable/disable, daemon-reload.

Gotcha: After editing unit files, always `daemon-reload` before restart.

4. Explain the purpose of dmesg vs journalctl.

Show answer Both show system logs but from different sources and with different scope.

dmesg:
- Reads the kernel ring buffer directly
- Contains only kernel messages
- Hardware detection, driver loading, kernel errors
- Ring buffer = fixed size, older messages overwritten
- Works without systemd
- Command: `dmesg`, `dmesg -T` (human timestamps), `dmesg -w` (follow)
- Useful for: boot issues, hardware problems, driver errors

Example: `journalctl -u nginx --since '1 hour ago'`. `-f`=follow, `-p err`=filter.

Remember: journalctl = systemd log viewer. Binary format, fast, needs journalctl to read.

5. Walk through the Linux boot process.

Show answer BIOS/UEFI β†’ GRUB β†’ kernel + initramfs β†’ hardware init β†’ root mount β†’ PID 1 (systemd) β†’ targets/services.

Remember: systemd: status, start/stop/restart, enable/disable, daemon-reload.

Gotcha: After editing unit files, always `daemon-reload` before restart.

Remember: Boot sequence mnemonic: BIG GRUB Kernel Init Systemd Targets β€” BIOS/UEFI, GRUB, Kernel, initramfs, systemd, targets.

Gotcha: If initramfs is missing or corrupt, the kernel panics before reaching systemd.

6. Where do admin-override unit files live, and why do they take precedence over vendor unit files?

Show answer 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.

Remember: Types: .service, .socket, .timer, .mount, .target. Most common: .service, .timer.

7. What systemd target replaces traditional runlevel 3, and what does it provide?

Show answer multi-user.target replaces runlevel 3. It provides a non-graphical multi-user system with networking and all standard services running.

Remember: Targets replaced runlevels. multi-userβ‰ˆ3, graphicalβ‰ˆ5.

8. How do you view only the logs for a specific systemd service using journalctl?

Show answer Use journalctl -u . For example, journalctl -u nginx.service shows only nginx logs. Add --since or --follow for time filtering or live tailing.

Example: `journalctl -u nginx --since '1 hour ago'`. `-f`=follow, `-p err`=filter.

Remember: journalctl = systemd log viewer. Binary format, fast, needs journalctl to read.

🟑 Medium (14)

1. How to start or stop a service?

Show answer To start a service: `systemctl start `
To stop a service: `systemctl stop `

Remember: systemd: status, start/stop/restart, enable/disable, daemon-reload.

Gotcha: After editing unit files, always `daemon-reload` before restart.

Example: `systemctl restart nginx` = stop + start. `systemctl reload nginx` = send SIGHUP (re-read config without downtime).

Remember: start/stop/restart affect running state. enable/disable affect boot state. They are independent axes.

2. WantedBy vs RequiredBy?

Show answer Both create dependencies when enabled.

- WantedBy: soft dependency (`.wants`)
- RequiredBy: hard dependency (`.requires`)

Remember: systemd: status, start/stop/restart, enable/disable, daemon-reload.

Gotcha: After editing unit files, always `daemon-reload` before restart.

Example: WantedBy=multi-user.target means start this service when multi-user.target is reached β€” the most common boot target.

Remember: WantedBy goes in [Install] section. Wants/Requires go in [Unit] section. Different contexts.

3. systemd vs SysVinit - what matters operationally?

Show answer Key operational differences:

* **Dependency graph**: systemd understands service dependencies; SysVinit uses numbered scripts
* **Parallel startup**: systemd starts independent services concurrently; SysVinit is sequential
* **Unit isolation**: systemd can sandbox services with cgroups, namespaces
* **journald integration**: Structured logging vs scattered log files
* **cgroups**: Resource limits and tracking built-in

It's easier to debug failures with `systemctl status` + `journalctl -u` than parsing rc scripts and scattered logs.

Remember: systemd: status, start/stop/restart, enable/disable, daemon-reload.

Gotcha: After editing unit files, always `daemon-reload` before restart.

4. How do you safely modify vendor unit files?

Show answer Never edit vendor unit files directly in `/usr/lib/systemd/system/`. Use overrides:

```bash\nsystemctl edit myservice\n```

This creates `/etc/systemd/system/myservice.service.d/override.conf` where you can add or override directives.

Benefits:
* Keeps upgrades clean - package updates won't overwrite your changes
* Changes are diffable and auditable
* Easy to see what was customized vs stock
* Can be managed by configuration management tools

To completely replace a unit, copy it to `/etc/systemd/system/` instead.

Remember: Types: .service, .socket, .timer, .mount, .target. Most common: .service, .timer.

5. Explain the difference between systemd inhibitors, systemd-inhibit, and how to prevent accidental shutdowns in production.

Show answer Inhibitors are systemd's mechanism to delay or block system power state changes.

Using systemd-inhibit:
- `systemd-inhibit --what=shutdown --who="maintenance" --why="Patching in progress" sleep infinity`
- Blocks shutdown/reboot until the process exits or is killed

Inhibitor targets (--what options):
- shutdown - block poweroff/reboot
- sleep - block suspend/hibernate
- idle - block automatic idle action
- handle-power-key - block power button action
- handle-suspend-key - block suspend button

Remember: systemd: status, start/stop/restart, enable/disable, daemon-reload.

Gotcha: After editing unit files, always `daemon-reload` before restart.

6. Walk through the Linux Boot Process (High Level).

Show answer The boot process has five main stages from power-on to login prompt.

1. BIOS/UEFI (Firmware):
- Power-On Self-Test (POST)
- Hardware initialization
- Locates bootable device
- Loads bootloader from MBR/GPT

2. Bootloader (GRUB2):
- Displays boot menu (optional)
- Loads kernel image and initramfs into memory
- Passes kernel parameters
- Transfers control to kernel

Remember: systemd: status, start/stop/restart, enable/disable, daemon-reload.

Gotcha: After editing unit files, always `daemon-reload` before restart.

7. How to check the status of a service?

Show answer `systemctl status `

Remember: systemd: status, start/stop/restart, enable/disable, daemon-reload.

Gotcha: After editing unit files, always `daemon-reload` before restart.

Remember: `systemctl status` shows: loaded state, active state, PID, memory usage, last log lines. One command for a full health snapshot.

Example: Green dot = active. Red dot = failed. Yellow = activating/deactivating.

8. On a system which uses systemd, how would you display the logs?

Show answer `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`.

Remember: systemd: status, start/stop/restart, enable/disable, daemon-reload.

Gotcha: After editing unit files, always `daemon-reload` before restart.

Remember: journalctl key flags: -u (unit), -f (follow), -b (current boot), -p (priority), --since/--until (time range).

Example: `journalctl -u nginx -p err --since '1 hour ago'` β€” show nginx errors from the last hour.

9. What is the difference between Wants= and Requires= in a systemd unit file?

Show answer 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.

Remember: Types: .service, .socket, .timer, .mount, .target. Most common: .service, .timer.

10. How do you safely customize a vendor-provided systemd unit file without editing it directly?

Show answer 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.

Remember: Types: .service, .socket, .timer, .mount, .target. Most common: .service, .timer.

11. What command enables a service to start at boot AND starts it immediately in one step?

Show answer systemctl enable --now . The --now flag combines enable (creates symlinks for boot) and start (activates the service immediately) into a single command.

Remember: enable=boot(symlink), start=now, enable --now=both. "enable=future, start=present."

12. How does systemd enforce resource limits on services?

Show answer 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.

Remember: systemd: status, start/stop/restart, enable/disable, daemon-reload.

Gotcha: After editing unit files, always `daemon-reload` before restart.

13. What command would you use to debug slow boot times and identify which units are taking the longest?

Show answer 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.

Remember: systemd: status, start/stop/restart, enable/disable, daemon-reload.

Gotcha: After editing unit files, always `daemon-reload` before restart.

14. How to reload PostgreSQL after configuration changes?

Show answer Solution 1:

```bash\nsystemctl reload postgresql\n```

Solution 2:

```\nsu - postgres\n/usr/bin/pg_ctl reload\n```

Solution 3:

```\nSELECT pg_reload_conf();\n```

Remember: systemd: status, start/stop/restart, enable/disable, daemon-reload.

Gotcha: After editing unit files, always `daemon-reload` before restart.

πŸ”΄ Hard (5)

1. A service starts manually but fails under systemd. What are the possible causes?

Show answer systemd runs services in a different execution context than interactive shells.

Common causes:

1. Missing environment variables
- No ~/.bashrc, ~/.profile sourcing
- PATH may be minimal
- Custom vars not set
- Fix: Environment= or EnvironmentFile=

2. No TTY
- Service has no controlling terminal
- Interactive prompts hang forever
- Fix: StandardInput=tty or redesign service

Remember: systemd: status, start/stop/restart, enable/disable, daemon-reload.

Gotcha: After editing unit files, always `daemon-reload` before restart.

2. A systemd unit shows "active (running)" but the actual service process is dead. How?

Show answer This happens with Type=simple when the main process exits but systemd doesn't know.

Root cause:
- Type=simple assumes first spawned process IS the service
- If that process forks and exits, systemd thinks it's still running
- Parent PID gone, children orphaned, systemd unaware

Common scenarios:

1. Daemonizing services with Type=simple
- Service double-forks (old-school daemon pattern)
- Original PID exits immediately
- systemd: "yep, started successfully!"
- Actual service: running under PID 1

Remember: systemd: status, start/stop/restart, enable/disable, daemon-reload.

Gotcha: After editing unit files, always `daemon-reload` before restart.

3. Describe the simplified boot sequence from firmware to running services in a systemd-based system.

Show answer 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.

Remember: systemd: status, start/stop/restart, enable/disable, daemon-reload.

Gotcha: After editing unit files, always `daemon-reload` before restart.

4. What is the difference between After=/Before= and Wants=/Requires= in systemd unit files?

Show answer 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.

Remember: Types: .service, .socket, .timer, .mount, .target. Most common: .service, .timer.

5. Why must you run systemctl daemon-reload after manually editing a unit file, and what happens if you forget?

Show answer 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.

Remember: Types: .service, .socket, .timer, .mount, .target. Most common: .service, .timer.