Operating Systems - Basic

Everyday Process Tools

A handful of commands cover most day-to-day process inspection and control.

ps aux                    # snapshot of every process on the system, with owner, CPU%, memory%
top                          # live, auto-refreshing view of the same, sorted by CPU by default
htop                         # a friendlier, colorized version of top, usually not installed by default
kill -TERM 1099                # ask a process to stop gracefully
nice -n 10 ./batch-job.sh        # start a new process with lower scheduling priority
renice -n 5 -p 1099                # change the priority of an already-running process

nice values run from -20 (highest priority, "least nice to everyone else") to 19 (lowest priority, "very nice, yields to others"). Regular users can only make their own processes nicer, not meaner; only root can lower a process's niceness (raise its priority) below what it started with. Lowering the priority of a batch job or backup script with nice is a cheap way to keep it from competing for CPU with the latency-sensitive service running on the same box, without needing to touch cgroups or containers at all.

---

File Descriptors: Everything Is a File

On Linux, almost anything a process reads from or writes to, whether that's a regular file on disk, a network socket, a pipe between two processes, or your terminal, is represented the same way from inside the process: as a small integer called a file descriptor. By convention, every process starts with three already open: 0 for standard input, 1 for standard output, 2 for standard error.

ls -l /proc/1099/fd
# lrwx------ 1 alice alice 64 Jan 5 10:00 0 -> /dev/pts/0
# lrwx------ 1 alice alice 64 Jan 5 10:00 1 -> /dev/pts/0
# lrwx------ 1 alice alice 64 Jan 5 10:00 3 -> socket:[88213]
# lrwx------ 1 alice alice 64 Jan 5 10:00 4 -> /var/log/app.log

That listing is genuinely useful during a live investigation: /proc/<pid>/fd shows you exactly what a running process currently has open, whether it's a log file it's writing to, a network connection it's holding, or a database socket it never closed. This unifying idea, that files, sockets, and pipes all look the same to a process, as a numbered descriptor it can read from or write to, is also why running out of them is a real production failure mode, not just a theoretical one: every open connection, every open log file, and every open socket consumes one, and each process has a limit on how many it can hold at once. What that limit is, how to see it, and what happens when you hit it is covered in the hard tier, but it's worth knowing now that "a file descriptor" isn't just about files on disk, it's the OS's name for any open handle to anything.