Processes and signals

A program is a file; a process is one running instance

Starting a program gives it a process ID (PID), an owner, memory, open files, a working directory, and a relationship to its parent process (PPID). Running the same program twice creates separate instances. Linux schedules runnable processes and threads onto available CPUs; a thread is an execution path within a process that shares much of its memory.

A shell starts child processes to do work. They inherit selected properties such as environment variables and open streams. fork creates a child process; exec replaces a process's program without creating another PID. These ideas explain why a server may have a manager process and several workers, and why killing an arbitrary matching name can hit the wrong instance.

Inspect before sending a signal

Use a regular user in Bash inside the Linux machine. Run these together while the child still exists:

sleep 300 &
study_child_pid=$!
ps -p "$study_child_pid" -o pid,ppid,user,stat,etime,args

& starts the command in the background. $! is the PID of this shell's most recent background child. sleep 300 waits up to 300 seconds and does no useful CPU-intensive work. An illustrative row could be:

  PID  PPID USER     STAT ELAPSED COMMAND
 4201  4100 learner  S      00:02 sleep 300

The PID identifies this instance, PPID points to its parent shell, S means interruptible sleep, and elapsed time is time since it started. Expect your actual numbers to differ. A sleeping process is not automatically broken.

Linux /proc/PID exposes information about a live process. For this known PID, readlink "/proc/$study_child_pid/cwd" shows its working directory if permitted, and ls -l "/proc/$study_child_pid/fd" shows open descriptors. Avoid dumping arbitrary process environments into notes; they can contain secrets.

Signals are requests with different rules

kill -TERM "$study_child_pid"
wait "$study_child_pid"
study_child_status=$?
printf 'child status: %s\n' "$study_child_status"

kill sends a signal; it is not limited to killing. TERM requests termination and can be handled by an application to finish work. wait asks this parent shell to collect the child's result. Expect a nonzero status because sleep was terminated by a signal; Bash on Linux commonly reports 143 for SIGTERM. The shell may also print a job message. Do not reuse the old PID later: it can be assigned to another process.

INT usually corresponds to Ctrl-C. STOP pauses and CONT resumes; KILL cannot be caught and allows no application cleanup. HUP may mean reload for one program and termination for another; consult that program's documentation. A task in uninterruptible wait may not act on a termination signal until its wait ends. A zombie has already exited; another kill signal cannot make its parent reap it.

Observe a slow system without manufacturing load

Use top (press q to exit), uptime, and free -h for an initial read-only view. Linux load averages include runnable tasks and some uninterruptible waits; high load is not proof that CPU use is high. Memory's available estimate is usually more useful than judging only unused free memory, because cache can be reclaimed. Sustained measurements and application response time are needed before declaring a bottleneck.

Why use systemctl stop for a managed service rather than repeatedly killing its PID? The manager may restart an exited process; stop expresses the intended service lifecycle. The next bite explains that manager. This fixture leaves no persistent file or child once wait completes.

Sources

Primary references: Linux signal semantics↗.