Systemd deep dive: services, targets, and timers. ⏱️

(Due to technical issues, the search service is temporarily unavailable.)

---

Systemd Deep Dive: Services, Targets, and Timers

Systemd is the modern init system and service manager in RHEL 8/9, replacing legacy SysVinit. It provides parallel startup, dependency management, and fine-grained control over system processes. Below is an advanced breakdown of services, targets, and timers for experienced administrators:

---

1. Systemd Services

What is a Service Unit?

• A .service file defining how to manage a daemon or application (e.g., Apache, PostgreSQL).
• Located in /usr/lib/systemd/system/ (default) or /etc/systemd/system/ (custom overrides).

Key Sections in a Service File:

[Unit]
Description=My Custom Service
After=network.target       # Dependencies

[Service]
Type=simple                # simple, forking, oneshot, notify, dbus
ExecStart=/usr/bin/myapp   # Command to start the service
Restart=on-failure         # Restart policy
User=appuser               # Run as non-root
LimitNOFILE=65535          # Resource limits

[Install]
WantedBy=multi-user.target # Enable the service to start at boot

Advanced Service Management:

• Reload Systemd After Editing Units:

  systemctl daemon-reload

• View Service Status and Logs:

  systemctl status myapp.service
  journalctl -u myapp.service --since "10 minutes ago"

• Custom Restart Policies:

  Restart=always           # Always restart
  RestartSec=5s            # Wait 5 seconds before restarting
  StartLimitInterval=60s   # Restart max 3 times in 60 seconds
  StartLimitBurst=3

• Resource Control (cgroups):

  MemoryMax=2G             # Limit memory usage
  CPUQuota=80%             # Limit CPU

• Sandboxing for Security:

  ProtectSystem=strict     # Read-only /usr, /boot, etc.
  PrivateTmp=true          # Isolate /tmp and /var/tmp
  NoNewPrivileges=true     # Prevent privilege escalation

---

2. Systemd Targets

What is a Target?

• A target is a group of services and other units (similar to SysVinit “runlevels”).
• Used to define system states (e.g., graphical, rescue, multi-user).

Common Targets:

Target	Purpose
graphical.target	GUI interface with networking.
multi-user.target	CLI-only multi-user mode.
rescue.target	Single-user rescue shell.
emergency.target	Bare-minimal environment (no services).

Advanced Target Operations:

• Change the Default Target:

  systemctl set-default multi-user.target

• Start a Temporary Target:

  systemctl isolate rescue.target

• Create Custom Targets:
  Define a new target file (e.g., /etc/systemd/system/myapp.target):

  [Unit]
  Description=My Custom Target
  Requires=network.target httpd.service  # Dependencies
  AllowIsolate=yes

• List Dependencies of a Target:

  systemctl list-dependencies multi-user.target

---

3. Systemd Timers

What is a Timer Unit?

• Replaces cron for scheduling tasks.
• Uses .timer files to trigger .service units at specific times or intervals.

Advantages Over Cron:

• Logs via journalctl.
• Calendar events with systemd.time syntax (e.g., Mon *-*-* 00:00:00).
• Monotonic timers (e.g., run 15 minutes after boot).
• Dependency management (e.g., wait for network).

Example Timer Setup:

1. Create a Service Unit (/etc/systemd/system/backup.service):

   [Unit]
   Description=Database Backup

   [Service]
   Type=oneshot
   ExecStart=/opt/scripts/backup.sh

2. Create a Timer Unit (/etc/systemd/system/backup.timer):

   [Unit]
   Description=Daily Backup at Midnight

   [Timer]
   OnCalendar=*-*-* 00:00:00     # Daily at midnight
   Persistent=true               # Run if missed during downtime
   Unit=backup.service

   [Install]
   WantedBy=timers.target

3. Enable and Start the Timer:

   systemctl enable backup.timer --now
   systemctl list-timers         # Verify scheduled jobs

Timer Types:

• Realtime (Calendar-Based):

  OnCalendar=Mon,Fri *-*-* 14:30:00  # Every Mon/Fri at 2:30 PM
  OnCalendar=*-*-01 00:00:00         # First day of the month

• Monotonic (Elapsed Time):

  OnBootSec=15min        # 15 minutes after boot
  OnUnitActiveSec=1h     # 1 hour after last run

Advanced Timer Features:

• Randomized Delay:

  RandomizedDelaySec=30m  # Add a random delay up to 30 minutes

• Conditional Execution:

  ConditionPathExists=/var/run/network-online  # Run only if file exists

• Transient Timers (One-Time):

  systemd-run --on-calendar="2024-01-01 00:00:00" /opt/scripts/yearly-job.sh

---

Best Practices for Advanced Admins

1. Use Drop-In Overrides:
   Modify services without editing original unit files:

   systemctl edit httpd.service  # Creates /etc/systemd/system/httpd.service.d/override.conf

2. Socket Activation:
   Start services on-demand when traffic arrives (e.g., for rarely used services).
3. Template Units:
   Create generic units for multiple instances (e.g., docker@.service).
4. Debugging Failed Services:

   systemd-analyze verify myapp.service  # Validate unit syntax
   systemd-analyze critical-chain        # Identify boot bottlenecks

5. Security Hardening:
   Use ProtectHome, PrivateDevices, and CapabilityBoundingSet to restrict service privileges.

---

Comparison: Systemd vs. SysVinit

Feature	Systemd	SysVinit
Boot Speed	Parallel startup	Sequential
Dependencies	Declarative (e.g., After=)	Script-based (chkconfig)
Logging	Centralized with journalctl	Scattered in /var/log/
Scheduling	Timers with calendar syntax	Cron
Resource Control	Built-in cgroups limits	Manual ulimit

---

Troubleshooting Tips

• Diagnose Service Failures:

  journalctl -u myapp.service -b -p err  # Show errors since last boot
  systemctl status myapp.service         # Check exit code and logs

• Simulate a Service Start:

  systemctl start myapp.service --dry-run

• Reset a Failed Service:

  systemctl reset-failed myapp.service

By mastering systemd, you gain precise control over services, streamline boot processes, and automate tasks more reliably than with legacy tools.