On a Linux host you run `pgrep postgres-exporter` and it prints nothing, even though `ps` clearly shows the process running. What is `pgrep` matching against, and what changes when you add `-f`?

## Two different strings, two different matches Every process on Linux carries two textual identities: - `/proc/<pid>/comm` — the short **process name**, set from the executable's basename at exec and changeable at runtime. The kernel stores it in a fixed-size buffer of 16 bytes, so it holds at most **15 characters** plus the terminator. This is what `ps` shows in the `comm` column and what `top` shows by default. - `/proc/<pid>/cmdline` — the full **command line**, a NUL-separated list of argv entries. This is `ps`'s `args` column. `pgrep` and `pkill` match against `comm` by default and against `cmdline` with `-f`. That single sentence explains the failure: any pattern longer than 15 characters, or any pattern that only appears in an argument rather than in the binary's name, cannot match without `-f`. A Java service is the extreme case — its `comm` is simply `java`, and everything identifying it lives in the arguments. ``` ps -eo pid,comm,args | head ``` Run that once and the truncation is obvious: the `comm` column is clipped while `args` shows the whole line. ## Why -f is sharper than it looks With `-f`, the pattern is an extended regular expression evaluated against the whole command line, unanchored. Everything on that line is fair game — the interpreter, the script path, every flag, every value. Consequences that show up in real incidents: - `pkill -f python` kills every Python process on the box, including the deployment agent you are standing on. - A pattern that appears in an unrelated process's arguments matches it too: `less /var/log/postgres-exporter.log` matches `-f postgres-exporter`. - A shell that was started with the pattern in its own argv — `bash -c 'restart postgres-exporter'`, or the `ssh` command line you used to get in — matches as well. `pgrep` and `pkill` never report or signal *themselves*, which is the one thing they do protect you from, and they will not signal PID 1. Everything else you have to reason about. ## The flags that make it safe - **`-a`** lists the full command line beside each PID, so `pgrep -af <pattern>` shows you exactly the set `pkill -f <pattern>` would hit. Dry-run first, always. (`-l` gives just the name.) - **`-x`** requires the pattern to match the whole string exactly rather than as a substring. `pgrep -x nginx` will not match `nginx-debug`. - **`-u`** restricts to a user, `-P` to children of a given parent, `-s` to a session — narrowing by ownership is usually safer than making the regex cleverer. - **`-n`** and **`-o`** select only the newest or the oldest match, which is how you target the most recent instance of something. - **`-c`** counts matches instead of listing them, useful in a monitoring one-liner. - On `pkill`, **`-e`** echoes what was killed, giving you an after-the-fact record, and the signal is chosen the same way as with `kill` — `pkill -HUP nginx` to reload rather than terminate. ## Why not just ps | grep The `ps aux | grep foo` idiom has a well-known defect: the `grep` process's own command line contains `foo`, so it matches itself, and any script that counts the lines is off by one. The traditional dodge is to bracket a character, `grep [f]oo`, so the pattern text no longer equals the string being searched. `pgrep` removes the class of problem, returns PIDs directly rather than text you have to cut columns out of, and gives a meaningful exit status: 0 if something matched, 1 if nothing did. That makes it the right primitive when you are deciding whether to act. ## The pkill discipline Because `pkill -f` is a pattern that expands into a kill list at the moment it runs, the set it hits is whatever happens to be running then — not what was running when you tested it. Treat it as you would `rm -rf` with a glob: 1. `pgrep -af '<pattern>'` and read every line. 2. Narrow with `-u`, `-x`, or an anchored pattern until only intended processes remain. 3. Only then run the same pattern under `pkill`, and prefer a service manager (`systemctl restart`) when the process is a managed service, because killing it directly can race the supervisor's own restart handling. If you can state the `comm`-versus-`cmdline` distinction, name the 15-character limit, and describe the dry-run habit, you have shown the interviewer that you have been burned by this once and learned from it.