Linux, Networking & SRE
Learn one boundary at a time: process, files, shell, names, routes, sockets, HTTP, capacity, evidence, incidents, and verified local recovery.
A first process map: program, process, identity, files, and exit
Objective Explain one running program through its parent, identity, working directory, standard streams, kernel requests, and exit status.
Core explanation
A program is stored instructions and data; a process is one running instance of a program. The process has a process ID, a parent that started it, an operating-system identity, a current working directory used to resolve relative paths, and numbered file descriptors. By convention descriptor 0 is standard input, 1 is standard output, and 2 is standard error. The process cannot directly control hardware: it asks the Linux kernel to open files, allocate memory, communicate, wait, and exit through system calls. An exit status is the small result the process returns to its parent; zero conventionally means success and a nonzero value means a classified failure. The first example is deliberately a frozen model, so every learner can predict the same five lines before touching a Linux machine. It teaches the names and relationships but does not claim to inspect the host kernel. The optional laboratory then maps those same fields to one exact process in an owned disposable Linux shell.
Separate the stored program from the running process
A program is instructions and data stored in a file or other executable artifact. A process exists only while one instance is running. Starting the same program twice creates two processes, each with its own process ID and state. Editing a stored file and stopping a process are therefore different actions. The example names observer.mjs as the artifact and course-observer as the modeled process so the two ideas cannot collapse into one label.
A process ID, usually shortened to PID, identifies one process inside an operating-system process namespace while it exists. Linux can reuse the number after exit, so serious observations pair PID with start time, user, and executable. A command name alone is not a safe target because several users or versions may have processes with the same name. In the first model, PID 4201 is frozen for learning; it is not claimed to be a PID from the learner’s host.
Read parent, identity, and working directory as ownership facts
The parent process is the process that created or launched the child. A terminal shell can be a parent; later, a service supervisor can be the parent. Parent identity helps answer who started the process, who waits for its completion, and where inherited settings came from. The model uses parent 4100 only to make that relationship visible. A real observation must name the exact parent rather than assume every command came directly from the terminal.
The operating-system user and groups determine which files and operations the process may access. UID 10001 in the model stands for an ordinary learner identity, while UID 0 represents root and is rejected to teach least privilege. The current working directory, or cwd, is the base from which relative paths are resolved. A file named notes.txt can therefore refer to different objects for processes with different working directories.
Connect standard streams and file descriptors to the kernel boundary
A file descriptor is a small integer a process uses to refer to an open kernel-managed object. By convention, 0 is standard input, 1 is standard output, and 2 is standard error. They may connect to a terminal, file, pipe, or another kind of object. Printing to standard output does not mean text appears on a screen; it means the process writes to whatever object descriptor 1 currently references.
User-space code does not directly command a disk, network card, or CPU scheduler. It asks the Linux kernel to open, read, write, wait, create processes, communicate, allocate memory, and exit through system calls. A language runtime can wrap several system calls behind one convenient function. The frozen Node.js model validates relationships but performs no Linux inspection, so it proves only that the teaching contract and assertions behave as written.
Use exit status and a controlled adapter to close the loop
When a process finishes, it returns an exit status to its parent. Zero conventionally reports success; a nonzero value reports a failure category chosen by the program. An exit status is not the printed output and does not by itself prove the requested business result. The model accepts integer exit status 0 and rejects an unknown value, making completion evidence explicit instead of assuming that printed text means success.
After predicting and running the exact five-line model, move to an owned disposable Linux shell under an ordinary user. Start one bounded child, record its exact PID and start time, and observe parent, user, working directory, descriptor targets, and exit status. Do not inspect every process, print environment values, kill by broad name, or use root. Values from that laboratory are evidence about that adapter at that time; they do not retroactively turn the frozen model into a kernel probe.