⚙️ Processes & Services

Processes & Services: Every running program on Linux is a process — an isolated unit with its own PID (process ID), memory space, file descriptors, and signal handlers — and the

Every running program on Linux is a process — an isolated unit with its own PID (process ID), memory space, file descriptors, and signal handlers — and the OS scheduler hands each one CPU time in turn, just as Java's JVM schedules threads. But here is the question: if a process is running fine, why would you ever need `ps`, `kill`, or `systemctl`? Because in QA automation, processes get stuck. A Selenium Grid hub that was supposed to stop after the test suite keeps listening on port 4444 and blocks the next pipeline run. A pytest session that hit an unhandled exception left a zombie process consuming memory. A mock server launched with `nohup` in the background is still running two hours after the test ended, and now the disk is 98% full of its access logs. In Java terms, managing Linux processes is like managing `Thread` lifecycle — you need `isAlive()` (`ps aux | grep`), `interrupt()` (`kill SIGTERM`), and sometimes `stop()` (`kill -9 SIGKILL`), plus the wisdom to know that `SIGTERM` should always be tried first because it lets the process clean up its resources and close open files, while `SIGKILL` bypasses all cleanup and can leave corrupted temp files or locked ports behind.

Viewing & Controlling Processes

Finding and stopping a stuck process

🎬 The Signal Ladder: From SIGTERM to SIGKILL

selenium-node (PID 4821)

Locked port / partial file

The suite finished, but the next pipeline run cannot start: port 4444 is still BUSY. Something is alive that should be dead.

`ps aux | grep selenium` finds the culprit: PID 4821 at 98.7% CPU — a selenium-node that forgot to shut down after the tests ended.

The FIRST rung of the ladder: `kill 4821` — sends SIGTERM: "please shut down". The process CAN catch this signal: it closes its open files, releases the port, removes its temp — a graceful goodbye.

Check again: `ps aux | grep selenium` — still on the list. The process ignored SIGTERM (or is stuck in a loop and cannot handle the signal). The polite request did not work.

The LAST rung of the ladder: `kill -9 4821` — SIGKILL. This signal never even REACHES the process; the kernel destroys it directly. Instant death, zero cleanup chance.

Contrast — the price of SIGKILL: a half-written temp file, an unreleased lock, a port that still looks "busy" may remain. That is exactly why the ladder has an order: TERM first (cleanup chance), KILL only when there is no response.

Final — the proof: `ps aux | grep selenium` now returns EMPTY; port 4444 is free, the next run can start. The Java bridge: SIGTERM ≈ `Thread.interrupt()` (politely ask it to stop), SIGKILL ≈ the deprecated `Thread.stop()` — and these cleanup problems are exactly WHY forced stopping was deprecated.

Micro Lab: ps & kill