Mastering Systemd: Creating and Managing Custom Services

init.d scripts are dead. Long live Systemd. It is the standard init system for almost all modern Linux distributions (timeless debates aside). It manages the boot process and services.

Why Systemd?

• Parallel Startup: Booting is faster.
• Dependency Management: "Start WebServer only after Network is up".
• Respawn: Automatically restarts crashed services.
• Logging: Centralized binary logging journal.

Creating a Service Unit

Let's say you have a Node.js app. Don't run node server.js and leave the terminal open. Create a service.

File: /etc/systemd/system/myapp.service

[Unit]
Description=My Node App
After=network.target postgresql.service

[Service]
Type=simple
User=appuser
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/node server.js
Restart=always
RestartSec=10
Environment=NODE_ENV=production

[Install]
WantedBy=multi-user.target

Breakdown

1. After: Waits for Network and Database.
2. User: Runs as appuser (Security!).
3. Restart: If it crashes, it waits 10s and tries again.
4. WantedBy: Tells systemd to start this when booting into standard multi-user mode.

Enabling and Running

sudo systemctl daemon-reload   # Scan for new files
sudo systemctl enable myapp    # Start on boot
sudo systemctl start myapp     # Start now

Debugging with Journalctl

Systemd stores logs in a binary format. Use journalctl to query them effectively.

• journalctl -u myapp: Show logs for specific unit.
• journalctl -f: Follow logs (like tail -f).
• journalctl -p err: Show only errors.
• journalctl --since "1 hour ago": Time travel.

Systemd gives you production-grade reliability with simple configuration.