Understanding System Services

Think of system services like background workers in a building: the web server that serves pages, the SSH server that lets you log in remotely, or the scheduler that runs tasks at certain times. They are programs that run in the background, often from the moment the computer boots, and keep running until you shut the system down. When you use ps or top, many of the processes you see are these services. Understanding what they are and how the system manages them helps you see why certain programs are always running and how to control them properly. This lesson describes how services work on an Ubuntu Server system (and other systemd-based Linux systems).

Quick Reference

Term	What It Means	Common Use
Service (daemon)	A long-running background program	Web server, SSH, cron, database
Service manager	Program that starts, stops, and monitors services	systemd on most modern Linux systems
Unit	A configuration file that describes a service (or other resource)	Defines how and when a service runs
Target	A group of units; like a "runlevel" (e.g. multi-user mode)	What runs when the system boots normally

When This Matters

• You see processes in ps or top and want to know what they are
• You need to start, stop, or restart a service (e.g. a web server)
• You want a service to start automatically when the system boots
• You're troubleshooting why a feature (e.g. SSH or a web app) isn't working

What Is a Service?

A service (also called a daemon) is a program that runs in the background. Unlike a command you run in the terminal—which runs, does something, and exits—a service keeps running. It usually has no window or terminal attached; it just does its job (accepting network connections, running scheduled tasks, and so on) until the system shuts down or someone stops it.

Common examples:

Service	What It Does
ssh	Lets you log in remotely via SSH
nginx or apache	Web server that serves web pages
cron	Runs commands on a schedule
systemd-logind	Manages logins and sessions

How the System Manages Services

On most modern Linux systems, a program called systemd is the service manager. It is responsible for:

• Starting services when the system boots
• Keeping track of which services are running
• Restarting services if they crash (when configured to do so)
• Stopping services in an orderly way when the system shuts down

You don't usually run services by hand from the command line and then leave them in the background. Instead, you tell systemd to start or stop them using the systemctl command (covered in the next lesson). That way the system knows about them and can manage them correctly.

Units and Unit Files

systemd organizes everything into units. A unit is a "thing" that systemd can manage: a service, a mount point, a timer, and so on. Each unit is defined by a unit file—a configuration file that describes what to run and how.

For a service, the unit file might specify:

• The command to run (the program and its arguments)
• Whether the service should start automatically at boot
• What to do if the service crashes (e.g. restart it)
• Which other units must be started first (dependencies)

Unit files are stored in a few places:

Location	What It's For
/usr/lib/systemd/system/	Units installed by packages (don't edit these)
/etc/systemd/system/	Local overrides and custom units (admin can edit)

Service unit files usually end in .service, for example ssh.service or nginx.service on Ubuntu. The name without the .service suffix is the unit name you use with systemctl (e.g. ssh, nginx).

Targets (Boot and Run States)

A target is a group of units. Think of it as a "mode" the system is in. When the system boots, it enters a default target (usually multi-user.target or graphical.target), and systemd starts all the units that belong to that target.

Target	What It Means
multi-user.target	Normal multi-user mode (text login, no desktop)
graphical.target	Full desktop with graphical login
rescue.target	Minimal single-user mode for recovery

When you "enable" a service, you're often saying "start this when the system reaches a certain target (e.g. multi-user)." The next lesson shows how to do that with systemctl.

Services and Processes

When you run ps aux or top, you see many processes. A lot of them are services started by systemd. They might run as the root user or as a dedicated user (e.g. www-data for a web server). So when you learn about processes (as in the ps and top lessons), you're already looking at the same programs that systemd manages—you're just viewing them from a different angle. systemctl is the right tool to start, stop, or enable them; kill can stop a process but doesn't tell systemd, so it's better to use systemctl stop for services.

Tips for Success

• Use systemctl to control services instead of running them by hand or killing them with kill
• Don't edit unit files in /usr/lib/systemd/system/; use /etc/systemd/system/ for overrides if needed
• If a feature isn't working (e.g. SSH or a web server), check whether the right service is running

Common Mistakes to Avoid

• Killing a service process with kill instead of using systemctl stop—systemd may restart it or get confused about state
• Editing unit files without understanding the syntax; small mistakes can prevent a service from starting
• Assuming every background process is a "service"—some are just programs you or another user started

Best Practices

• Use systemctl status servicename to see if a service is running and read its recent log
• Enable only services you need at boot to keep startup fast and reduce risk
• When troubleshooting, check the service status and logs before changing configuration