start, stop, restart Linux services (daemon HUNTING!!) // Linux for Hackers // EP 6

Linux runs on background services—often called daemons—that start automatically, keep systems functioning, and handle tasks like networking, time sync, and remote access. The practical takeaway is that these “demons” are just processes managed in a structured way, and mastering their lifecycle—start, stop, restart, reload, and enable/disable—turns troubleshooting from guesswork into a repeatable routine.

The foundation starts with distinguishing interactive processes from daemon processes. When a user launches an app like Sublime Text or opens Nano, the resulting processes appear and disappear as the program starts and closes. By contrast, many processes running on a system without user interaction are daemons—services that “just do their thing.” A quick way to spot them is by name: daemon services commonly end with a trailing “d” (for example, sshd for SSH and ntpd for Network Time Protocol). Using process inspection commands such as ps with filtering (ps -aux | grep <name>) helps confirm what’s running and what stops when an application exits.

Control of those daemons centers on systemd, the master service manager and init system used on modern Linux distributions. systemd is the first process created during boot (with PID 1) and then forks into other processes, which can be visualized with tools like ps tree. systemd’s job is twofold: it initializes the system during startup and manages services afterward. In systemd terminology, daemons are “units,” which can represent services, sockets, timers, mounts, and more.

The command-line workhorse is systemctl. With it, administrators can stop and start services (e.g., sudo systemctl stop sshd, then sudo systemctl status sshd to verify it’s inactive or active), restart them, and sometimes reload configuration without a full restart. systemctl also handles boot behavior: sudo systemctl disable <service> prevents a unit from starting on the next reboot, while sudo systemctl enable <service> schedules it to start automatically later. Quick checks like systemctl is-active and systemctl is-enabled help confirm both runtime state and boot-time configuration.

Finding what’s running requires knowing how systemctl lists units. systemctl list-units shows units systemd has loaded and is actively aware of, so a service that isn’t loaded may not appear. To locate services that exist but aren’t active, systemctl list-unit-files is used, revealing states like disabled. A troubleshooting scenario with nginx shows the workflow: enable it for boot, attempt to start it, then use journalctl (systemd’s logging facility) to diagnose failures. In the example, nginx fails because port 80 is already in use, and the logs point directly to the binding conflict.

Overall, the episode frames daemon management as essential Linux admin and hacker skill: identify services, control them through systemd/systemctl, and use journalctl to resolve failures quickly and accurately.