Services

What is it? #

A service is a program that runs continuously in the background: a web server, a database, your application, a background worker.

Starting one by hand in a terminal works exactly until you close the terminal, reboot the machine, or the process crashes at 3am.

A service manager solves all three. It starts programs at boot, restarts them when they fail, captures their output, and gives you one consistent way to start, stop and inspect them.

On modern Linux that manager is almost always systemd, which the next lesson covers in detail. This lesson is about the ideas.

Think of it like this #

A shop that needs to open every morning, stay open all day, and reopen if the shutters accidentally come down.

Relying on someone remembering to unlock it works until they are ill. A caretaker with a schedule and a key is the reliable version.

Simple example #

Your Python application must start when the server boots, restart if it crashes, log somewhere you can find, and stop cleanly during a deployment. Running python app.py & in an SSH session provides none of that.

Code #

# Managing any service — the same five commands for everything
sudo systemctl start myapp
sudo systemctl stop myapp
sudo systemctl restart myapp        # stop then start
sudo systemctl reload myapp         # re-read config without dropping connections
sudo systemctl status myapp         # state, recent logs, PID, memory

# Start automatically at boot
sudo systemctl enable myapp
sudo systemctl disable myapp
sudo systemctl enable --now myapp   # enable and start in one step

# What is running on this machine?
systemctl list-units --type=service --state=running
systemctl --failed                  # anything that failed

What a service manager gives you

start at boot        no manual step after a reboot
restart on failure   a crash becomes a blip rather than an outage
dependency order     the database is up before the app starts
log capture          stdout goes to the journal automatically
resource limits      memory and CPU caps per service
clean shutdown       SIGTERM with a timeout before force
one interface        the same commands for nginx, postgres and your app

Why "start it with nohup" is not enough

nohup python app.py &

- does not start after a reboot
- does not restart after a crash
- output goes to a stray nohup.out file
- no defined stop procedure, so deploys use kill
- no memory limit, so a leak can take down the machine
- no record of whether it is supposed to be running

How it works #

The five verbs — start, stop, restart, reload, status — work identically for every service on the machine. That consistency is a large part of the value.

reload differs from restart in an important way. Nginx can re-read its configuration and apply it to new connections without dropping existing ones; a restart briefly stops accepting traffic. Not every service supports reload.

enable is separate from start. Enabling registers the service to start at boot; starting runs it now. Forgetting enable produces the classic "it worked until the server rebooted".

status is the first command to run when something is wrong. It shows whether the service is active, how long it has been running, its process ID, memory usage and the last few log lines — often enough to diagnose the problem immediately.

systemctl --failed lists everything that failed to start, which is the fastest post-reboot health check.

The comparison block explains why running something with nohup is a stopgap. Every item on that list is a real incident that a service manager prevents.

Real-world use #

Every production application runs under a service manager, whether that is systemd on a virtual machine, a container orchestrator, or a platform's own process supervisor.

Deployment scripts use these commands: stop or reload the service, swap the code, start it again, then check status. A deployment that kills processes by name is fragile by comparison.

The restart-on-failure behaviour turns many incidents into non-events. A process that crashes once a week and restarts in two seconds may never be noticed by users — though it should still be investigated, which is why restart counts are worth monitoring.

Resource limits are underused. Capping memory per service means a leaking application is restarted rather than triggering the OOM killer on something more important.

In containers, the orchestrator plays this role: restart policies, health checks, resource limits and log capture are the same ideas expressed differently.

Common mistakes #

• Starting applications by hand and losing them on reboot.
• Forgetting systemctl enable, so the service does not come back after a restart.
• Using restart where reload would avoid dropping connections.
• Killing processes by name in deploy scripts instead of using the service manager.
• No resource limits, so one leaking service destabilises the whole machine.

Practice #

On a test machine, pick an installed service and practise start, stop, restart, status and enable. Then reboot and confirm which services came back automatically, and list anything that failed to start.