EMZETT.
Login

Service

In short: A program (also called a “service”) that runs in the background, without a user actively interacting with it.

In more detail: Usually starts automatically with the operating system and keeps running permanently, to provide certain functions — e.g. a print service, a network service, or a database server. Managed on Windows via the Services management console (linked from the Task Manager), on Linux typically via systemd.

In Depth

A service differs from a normal program mainly in that it isn’t tied to a logged-in user session — it keeps running even if nobody is logged into the machine, often already right at system startup, before a login screen even appears. On Windows, services are called “Windows Services” (manageable via services.msc); on Linux, systemd usually handles starting, stopping and monitoring (systemctl status nginx, systemctl restart nginx).

systemctl status ssh
systemctl restart nginx

Typical examples are web servers (nginx, Apache), database servers (MySQL, PostgreSQL), print services (CUPS on Linux, the print spooler on Windows), or background maintenance tasks like automatic updates. If a service crashes, the user often doesn’t notice at first — only once the dependent function (printing, a website, a database connection) fails does the problem become visible, which is why server environments usually configure services with automatic restart and monitoring.

systemd as the modern standard on Linux

For decades, Linux distributions used various, sometimes simple init systems (SysVinit with sequentially processed shell scripts), until systemd became the de-facto standard from the 2010s onward. systemd starts services in parallel instead of strictly sequentially (faster boot process), monitors them continuously, and can automatically restart crashed services. Every service is defined via a so-called unit file (/etc/systemd/system/my-service.service), which specifies, among other things, which command runs at startup and which other services it depends on:

[Unit]
Description=My example service
After=network.target
 
[Service]
ExecStart=/usr/bin/my-program
Restart=on-failure
 
[Install]
WantedBy=multi-user.target

Windows services and security context

On Windows, every service runs under its own user account (often special system accounts like LocalSystem, NetworkService or LocalService), which gets exactly the permissions the service actually needs — a service that only processes local files should ideally have no network access (principle of least privilege). Via the Services management console (services.msc), you can configure for each service whether it starts automatically, manually, or not at all, and how it reacts to errors (e.g. automatic restart after a crash).

Service vs. daemon vs. background process

The terms overlap heavily, but differ slightly in origin: “daemon” is the traditional Unix term for the same concept (often recognisable by the name ending in d, e.g. sshd, httpd), “service” is the Windows-typical term, and “background process” is the most general, platform-independent term, which can also cover simple programs not formally registered as a service that just run without a visible window.

See also: Task Manager, Windows, Linux