Essential Systemctl, Unit Files, Journalctl & Daemon Commands
Quick reference for creating production background daemons, auto-restarting Node.js/Next.js services, and viewing journalctl logs.
Table of Contents
Everyday systemctl Commands
Managing service states and enabling boot-time startups.
| Task | Command Syntax | Purpose |
|---|---|---|
| Start Service | `sudo systemctl start app` | Starts the specified daemon immediately. |
| Stop Service | `sudo systemctl stop app` | Gracefully terminates the running process. |
| Restart Service | `sudo systemctl restart app` | Stops and restarts the service process. |
| Enable on Boot | `sudo systemctl enable app` | Creates symlinks to start service automatically upon system boot. |
| Check Live Status | `systemctl status app` | Displays PID, memory usage, uptime, and recent console log lines. |
| Reload Unit Definitions | `sudo systemctl daemon-reload` | Must be run after modifying any file in `/etc/systemd/system/`. |
Inspecting Logs with journalctl
Querying and streaming centralized systemd journal logs.
| Log Query | Command Syntax | Behavior |
|---|---|---|
| Follow Live Logs | `journalctl -u app -f` | Streams live console output in real time like tail -f. |
| Last 100 Entries | `journalctl -u app -n 100 --no-pager` | Prints the most recent 100 log lines without pager navigation. |
| Errors Since Boot | `journalctl -u app -b -p err` | Filters for priority error/crit/emerg logs generated in the current boot. |
Interactive Client-Side Tools for this Guide
Test and run these patterns directly inside your browser with zero server uploads:
Linux Chmod Permissions Calculator & Command Generator
Calculate numerical and symbolic Linux file permissions with an interactive permission matrix. Generate terminal commands without memorizing octal values.
Online Cron Expression Generator & Human Explainer
Build cron schedule strings interactively or translate cryptic expressions into plain English. View next estimated runtimes with zero server latency.
Frequently Asked Questions
Where should custom systemd unit files be placed?
Place custom system administrator unit files in `/etc/systemd/system/app.service` (higher priority than `/lib/systemd/system/`).
Why do changes to a .service file not take effect immediately?
Systemd caches unit definitions in memory. You must run `sudo systemctl daemon-reload` before restarting the modified service.