A server can carry forty background jobs that nobody remembers installing. Each one holds memory, opens ports, and widens the attack surface.
systemctl reports what runs right now, what failed at boot, and what starts on its own next time. This guide covers the listing commands, the five unit states, and the follow-up commands that start, stop, or block a daemon.
What Linux Services and Daemons Do in the Background
A service runs apart from any login session. Web hosting, scheduled jobs, and remote SSH access all work this way, and systemd supervises them on current distributions.
A daemon is the same thing under an older Unix name. It starts at boot, attaches to no terminal, and waits for work. Apache, MySQL, and sshd all qualify, and the daemon(3) manual page covers the fork-and-detach routine behind the label.
Two of these come up constantly. Cron handles timed work, and you can translate a crontab schedule into plain English before trusting it. SSH access depends on sshd, which reads settings you can draft with an SSH config builder.
Why systemd Replaced SysVinit on Most Distributions
Fedora 15 shipped systemd as the default in 2011. Red Hat Enterprise Linux 7 and CentOS 7 followed in 2014, then Debian 8 and Ubuntu 15.04 landed in April 2015.
Boot runs in parallel now, so machines come up faster. Shell scripts gave way to declarative unit files, dependencies are spelled out, and journald collects logs without extra tooling. The adoption figures across distributions show how little of the market SysVinit still holds.
Ubuntu 16.04+, CentOS 7+, and Debian 8+ all run systemd. If you inherited a box and cannot recall its release, confirm the Ubuntu version before assuming which commands apply.
Run systemctl list services for a Full Inventory
sudo systemctl list-unit-files --type=serviceThat prints every service definition installed on disk, its state, and the preset the vendor shipped. Loaded units are a shorter set:
sudo systemctl list-units --type=serviceListing needs no privileges. Starting, masking, and disabling do, which is a smaller concern than most teams assume once you read what root access actually exposes.
Filter systemctl list services by Running or Failed State
sudo systemctl list-units --type=service --state=runningUse this to separate what occupies memory from what merely sits installed. The failed list matters more:
sudo systemctl list-units --type=service --state=failedA unit that died during boot while nobody watched explains a lot of strange behaviour hours later. Run systemctl --failed after every reboot, since blind spots in uptime monitoring cause most server outages.
Listing Services Without systemd
Where SysVinit or the older wrapper survives, one command still works:
service --status-allA plus sign marks a running service, a minus sign marks a stopped one, and a question mark means the state could not be read.
Reading the Five Service Unit States
| State | What it means |
|---|---|
| enabled | A symlink under /etc/systemd/system/ pulls the unit in at boot |
| disabled | Skipped at boot, but you can still start it by hand |
| masked | Blocked outright; nothing starts it until the mask comes off |
| static | No install section, so it runs only when another unit needs it |
| failed | Startup was attempted and the process exited with an error |
Commands to Run After systemctl list services
| Goal | Command |
|---|---|
| Start now | sudo systemctl start nginx |
| Stop now | sudo systemctl stop nginx |
| Full restart | sudo systemctl restart nginx |
| Re-read config only | sudo systemctl reload nginx |
| Turn on autostart | sudo systemctl enable nginx |
| Turn off autostart | sudo systemctl disable nginx |
| Autostart plus immediate launch | sudo systemctl enable –now nginx |
| Inspect current state | sudo systemctl status nginx |
Starting and stopping take effect at once and survive nothing. After a reboot the unit follows whichever boot setting it carries.
Reload beats restart on something like nginx, where a restart drops live connections for a moment. Not every daemon accepts a reload, and custom units only behave well when the file is written right, so a systemd unit file generator saves a round of debugging.
The status output reports whether the service is alive or broken, its main process ID, memory held, and the last ten journal entries.
Pulling Service Logs With journalctl
systemd captures whatever a unit writes to output. Read the history for one service:
sudo journalctl -u nginxWatch entries arrive live with sudo journalctl -u nginx -f, or trim the view to the newest hundred lines with sudo journalctl -u nginx -n 100.
Service Hygiene Worth Keeping
Audit the running list on a schedule and question anything you did not install. Mask what must never start, because a package update can flip a disabled unit back on.
Pair --now with enable and disable so the boot setting matches the live state. In production, reload before you restart.
FAQs
Which command lists every running service?
Run sudo systemctl list-units --type=service --state=running. For the full catalogue regardless of state, use sudo systemctl list-unit-files --type=service, which also shows each unit’s boot setting.
How do I start a service on Linux?
Run sudo systemctl start service-name with a real unit such as nginx, mysql, or sshd. Add enable --now instead if the service should also come up at boot.
How do I switch on autostart at boot?
sudo systemctl enable service-name writes the symlinks systemd reads during startup. Append --now to start the unit in the same command rather than waiting for a reboot.
Where do stop and disable differ?
Stop kills the running copy and leaves boot behaviour alone. Disable removes the boot symlinks while the current process keeps going. sudo systemctl disable --now service-name does both.
Do I need sudo to list services?
No. Listing and status commands work as a normal user. Root or sudo is required only to start, stop, restart, enable, disable, or mask a unit.
