Unix PIDs are a unique identifier for processes. They are assigned to each process when it is started, and they remain the same for the life of the process. This makes it easy to identify a process even if you don’t know its name. ..

Whenever a process is created in a Linux system, it is given a new number that identifies it to other applications. This is the process ID, or PID, and it is used throughout the system to manage running processes.

How Processes Work In Linux

The first process Linux runs is called systemd, which is given PID 0. All other processes are spawn as children of systemd. The first few will usually be low-level Linux stuff that you won’t need to worry about, but further down the tree the system will start launching user-level processes like MySQL and Nginx.

Each process also has a PPID, which stores the PID of the parent that process was created by. There’s also a processes TTY, which stores the ID of the terminal you used to launch the process, and UID, which stores the ID of the user that created it. Any process missing a TTY is usually called a daemon, a term used to denote system processes running in the background that do not have a controlling terminal.

Whenever a process closes, that PID is then available for another process to use. Every process also closes with an exit code, usually used to denote whether or not an error occurred. Exit code 0 is a clean exit, anything greater is a specific error.

On a more technical note, PIDs are an important part of Linux namespaces. Namespaces hide certain parts of the system from processes running in different namespaces, which powers containerization tools like Docker. With namespaces, the PID tree is cut off at a certain branch, and only that branch is given to the containerized process. This branch restarts from PID 1, so it appears to the container as if it is running in an entirely fresh Linux install.

Viewing Processes

To get a full list of processes, you can run the ps command:

Which will output a very long list of every running process, which is admittedly a bit hard to scroll through.

You can filter the results by piping the output to grep, as ps doesn’t have a built-in search function:

Though you should be warned that, oddly enough, this will also match the newly created grep process, as ps shows command arguments, which includes your matching string, that obviously matches itself. If you just need the PID of a given process name, the pgrep command  simply returns the PID and nothing else.

A much more useful viewer is the top command, which acts like a Task Manager from your terminal. It shows all processes ordered by CPU usage, as well as some general system stats:

If you’re running a Linux desktop, this also shows currently running apps, though most apps will multithread themselves, hence why this list is filled by Google Chrome running on multiple processes with different PIDs.

Stopping Processes

Realistically, you won’t be doing much with the actual process other than turning it off, as you won’t have to manage process creation. (It’s handled automatically when you run a command or script.) The command to do that is succinctly named kill, which takes a given PID and shuts that process down:

You can also kill all processes with a given name using the killall command. For example, to free up some RAM on your system you could run:

Obviously this isn’t the best way to shut down desktop apps, but most processes won’t throw too much of a fuss being shut down this way.

However, if the process is a Linux service, you’ll want to instead use the service command to interact with it. For example, reloading nginx:

Or turning it off:

PID Files

A process ID only uniquely identifies a process for as long as that process is running. If you have to restart Nginx, it may be given a new process ID.

This is where PID files come into play; they’re a form of inter-process communication, essentially a file that stores the current PID of a given process. Another process can read this file and inherently know, for example, what the PID of MySQL is. When MySQL starts up, it writes its own PID to this file for the whole system to see.

Usually, PID files are stored in /var/run/, though this is only common practice and not required, similarly to how log files are stored in /var/log/.

Most processes with PID files will also only have one running at a time, which is done with the help of lockfiles. Lockfiles are way of setting flag that only allows one process to be started at a time. When a process like Nginx starts, it checks if the lockfile exists, and if it doesn’t, it will proceed with launch as  normal. But if it’s already there, Nginx will throw an error, and refuse to start.