Log into any running Linux server and, even if you haven’t started anything yourself, dozens of programs are already busy. Something is listening for network connections, something is writing logs, something is keeping the clock in sync. None of it appears on a screen, because servers usually don’t have one. So how do you know what’s running, and how do you take control of it? That’s what processes and services are about.
These two words get thrown around a lot, and they’re related but not the same. Once you can tell them apart and know the handful of commands that go with each, a Linux server stops feeling like a black box. You’ll be able to see exactly what’s alive on the machine, why, and what to do when something misbehaves.
What a process actually is
A process is a running program. That’s the whole definition. When you launch anything on Linux — a text editor, a web server, a one-line script — the operating system loads it into memory, gives it a slice of CPU time, and from that moment on it’s a process.
The key word is running. A program sitting on disk as a file is not a process; it’s just instructions waiting to be used. The instant you run it, the kernel creates a process around it: a live instance with its own memory, its own state, and its own identity. Run the same program three times and you get three separate processes, even though they all came from one file.
Every process gets a number called a PID (Process ID). The PID is how the system — and you — refer to a specific running program. If you want to stop a runaway program, you don’t say its name; you point at its PID. The kernel hands out PIDs in order as processes start, and reuses them after a process exits.
FILE ON DISK PROCESS (running)
───────────── ─────────────────
/usr/bin/myapp run → PID 4821 myapp
(just bytes) ├─ owns memory
├─ uses CPU time
└─ has a state (running/sleeping)Processes also have a parent. Almost every process was started by another process, which means they form a family tree. At the very top sits the first process the kernel starts at boot, usually with PID 1. Everything else descends from it. When you open a shell and type a command, your shell is the parent and the command becomes its child.
A process is more than just 'the program'
The same program can run as many independent processes at once, and each one is isolated. If one crashes, the others keep going, because the kernel keeps them in separate boxes of memory. This is why a web server can handle thousands of visitors without one bad request taking down the whole machine — under the hood, the work is spread across processes (or threads inside them) that don’t share each other’s memory by accident.
Seeing what’s running
You can’t manage what you can’t see, so the first real skill is listing processes. There are two commands you’ll reach for constantly.
The classic one is ps. On its own it only shows your own shell’s processes, which isn’t very useful, so it’s almost always run with flags to show everything:
ps auxThat prints a table of every process on the machine. The columns worth knowing:
USER PID %CPU %MEM ... STAT TIME COMMAND
root 1 0.0 0.1 ... Ss 0:04 /sbin/init
www 842 1.2 3.4 ... S 2:11 /usr/sbin/web-server
jane 1503 0.0 0.0 ... R 0:00 ps aux- USER — who owns the process (which Linux user it runs as).
- PID — its unique number.
- %CPU / %MEM — how much processor and memory it’s using right now.
- STAT — its state:
Rrunning,Ssleeping (waiting for something),Zzombie (finished but not cleaned up yet). - COMMAND — what’s actually running.
ps gives you a snapshot — a single freeze-frame. When you want a live, updating view, you use top (or its friendlier cousin htop if it’s installed):
toptop fills the screen with a constantly refreshing list, sorted by CPU use by default, so the process eating your processor floats to the top. It’s the first thing most people open when a server feels slow — one glance tells you whether something is pegging the CPU or eating all the memory.
Find one process fast
When you only care about a specific program, piping into grep saves a lot of scrolling: ps aux | grep web-server lists just the matching lines. If your system has pgrep, it’s even cleaner — pgrep -a web-server prints the PIDs and command lines of anything matching the name. Knowing the PID is usually the first step before you stop or restart something.
Controlling processes: signals
So you’ve found a process you want to stop. How? You don’t reach in and switch it off — you send it a signal. A signal is a small message the kernel delivers to a process, telling it something happened or asking it to do something. Stopping a process is just sending the right signal.
The command for this is bluntly named kill, even though most of the time you’re asking politely rather than force-killing:
kill 4821 # ask process 4821 to shut down cleanly
kill -9 4821 # force it to stop immediately (last resort)Plain kill sends the TERM signal, which means “please wrap up and exit.” A well-behaved program catches this, finishes what it’s doing, saves anything it needs to, and exits cleanly. That’s what you want almost always.
kill -9 sends KILL, which the program can’t catch or ignore — the kernel simply removes it. It stops instantly, but it gets no chance to clean up, so use it only when a process is truly stuck and ignoring the polite request.
kill (TERM) → "please stop" → process tidies up, exits
kill -9 (KILL) → forced removal → process gone instantlyThere are other signals too — one common one tells a program to reload its configuration without fully restarting, which is handy for long-running services. But for day-to-day work, the polite kill and the forceful kill -9 cover most situations.
From process to service
Now the important shift. A process you start by typing a command in your shell lives and dies with that shell — close the terminal, and it’s usually gone. That’s fine for a quick script. But a server’s whole job is to keep things running: a web server has to stay up at 3 a.m. whether anyone is logged in or not.
A service (also called a daemon) is a process designed to run continuously in the background, independent of any logged-in user. It starts when the system boots, keeps running on its own, and is managed by the system rather than by your terminal. The web server answering requests, the database accepting queries, the scheduler firing off timed jobs — these all run as services.
The naming hint is everywhere in Linux: programs meant to run as background services often end in d, for daemon. sshd is the SSH service. crond runs scheduled jobs. The d is your clue that it’s built to sit quietly in the background, not to be launched by hand each time.
ORDINARY PROCESS SERVICE (daemon)
──────────────── ────────────────
you start it in a shell system starts it at boot
dies when shell closes keeps running on its own
you babysit it restarts itself if it crashes
e.g. a script you run e.g. sshd, the web serverSo a service is a process — but a special kind: long-lived, system-managed, and detached from any user session. The difference isn’t the program itself; it’s how it’s run and who’s in charge of it.
Managing services
Because services need to survive reboots and start in the right order, you don’t launch them by hand. A dedicated piece of the operating system manages them: it starts them at boot, restarts them if they crash, and gives you simple commands to control them.
On the great majority of modern Linux servers, that manager is systemd, and the command you use to talk to it is systemctl. The everyday verbs are exactly the words you’d guess:
systemctl status web-server # is it running? show recent logs
systemctl start web-server # start it now
systemctl stop web-server # stop it now
systemctl restart web-server # stop then start (apply changes)
systemctl enable web-server # start automatically at every boot
systemctl disable web-server # don't start at bootTwo of these are worth separating in your head, because beginners mix them up constantly. start affects the service right now, this moment, until the next reboot. enable affects whether it comes back after a reboot. A service can be running now but not enabled (so it won’t survive a restart), or enabled but currently stopped. You usually want both: enable it so it survives reboots, and start it so it’s up immediately without waiting for one.
The one command you’ll run most is status. It tells you in plain language whether a service is active or failed, when it last started, and the last few lines of its log — which is often exactly enough to spot what went wrong:
● web-server.service - Example Web Server
Loaded: loaded (/etc/systemd/system/web-server.service; enabled)
Active: active (running) since Mon 2026-09-21 09:14:02 UTC
Main PID: 842 (web-server)Active: active (running) is what you hope to see. failed means it tried and couldn’t stay up — and the log lines underneath usually point straight at the reason.
Stopping a service isn't the same as disabling it
If you stop a service to troubleshoot something and then reboot the machine, an enabled service will come right back on its own — your stop didn’t stick. The reverse trap is just as common: people disable a service expecting it to stop immediately, but disable only prevents it from starting next boot; it’s still running right now until you also stop it. When you genuinely want a service gone now and after reboot, do both: stop it and disable it.
How it fits together
Step back and the whole picture is fairly small. Everything running on the server is a process — a live instance of a program, identified by a PID. You see processes with ps and top, and you control them by sending signals with kill. Some processes are ordinary and tied to your session; others are services, long-lived background programs that the system itself starts, watches, and restarts. You manage those through the service manager — systemctl on most servers today — with verbs like start, stop, restart, enable, and status.
That’s genuinely most of what day-to-day server operation comes down to: knowing what’s running, why it’s running, and how to make it start, stop, or behave. Once these commands are in your fingers, a Linux box feels far less mysterious — you can walk up to an unfamiliar server, list what’s alive on it, and reason about it instead of guessing.
If the commands here are new, it’s worth getting comfortable at the Linux command line first, since that’s where all of this happens. And the services you’ll most often start and stop are the ones installed through your distribution’s package tools, which differ a little between Linux distributions — worth a look if you’re not sure which family your server belongs to.
Wrapping up
The short version, all in one place:
- A process is a running program — a live instance with its own memory, state, and a unique PID. The same program can run as many separate processes at once.
- See what’s running with
ps auxfor a snapshot ortopfor a live, updating view; usegreporpgrepto find one fast. - Control a process by sending a signal with
kill: plainkillasks it to exit cleanly,kill -9forces it to stop as a last resort. - A service (or daemon) is a process built to run continuously in the background, started by the system at boot and independent of any logged-in user — names ending in
d(sshd,crond) are the giveaway. - Manage services with
systemctl:status,start,stop,restart, plusenable/disableto control whether they come back after a reboot.startis now;enableis for next boot — they’re not the same.
The natural next step is to look closer at the manager itself — what systemd actually is, how it decides what runs and in what order, and how you’d define your own service so a program of yours starts at boot and stays up.
