FrançaisGet started

Watching and controlling processes

Finding, testing, bounding and stopping a process from a script: pgrep, pkill, kill -0, timeout, nice, ulimit, the /proc directory, the PID file, the daemon and the zombie.

  • 32 cards
  • 5 topics
  • Free
Study this deck

The outline, topic by topic

Each topic is weighted the way the exam weighs it.

  1. Concepts
  2. Questions
  3. Sort and link
  4. Scenarios
  5. Understand

A few cards from the deck

  • Daemon: what is it?

    Show the answer

    A background process attached to no terminal, whose parent is process 1: the process that started it has left and process 1 adopted it.

    It detaches from its terminal to outlive the session. Under systemd, systemd starts and supervises it: it no longer needs to detach itself.

  • What does this script print?

    ```bash
    sleep 300 &
    kill -0 $!
    echo $?
    `

    • 0
    • 1
    • 143
    • 124
    Show the answer

    0

    $! is the PID of the background job, which exists and belongs to the user: kill -0 succeeds without sending anything. 143 would be the code of a process killed by SIGTERM, 124 that of timeout.

  • The command kill -0 PID sends no signal: it returns code … if the process exists and you may signal it, a non-zero code otherwise.

    Show the answer

    The command kill -0 PID sends no signal: it returns code 0 if the process exists and you may signal it, a non-zero code otherwise.

    It is the liveness test for a process. For a missing process, bash answers “kill: (999999) - No such process” and the code is 1.

  • PID file: what is it?

    Show the answer

    A small file where a service writes its process number at startup, so scripts can find it, test it or stop it.

    It goes stale if the service crashes without removing it, and its number can be handed to another process: before killing, test with kill -0 and compare /proc/PID/cmdline.

  • A service logs “accept: Too many open files” after a few hours. ls /proc/PID/fd | wc -l gives 1022, and /proc/PID/limits shows “Max open files 1024”. What is the likely cause and the right first answer?

    • The disk is full: spot the full file system with df, then delete the large unneeded files to free up space
    • Memory is exhausted: add RAM to the machine or reduce the number of active processes
    • It is hitting its descriptor ceiling: find what it fails to close, then raise the ceiling if the load justifies it
    • The listening port is already taken by another process: change its number in the service configuration
    Show the answer

    It is hitting its descriptor ceiling: find what it fails to close, then raise the ceiling if the load justifies it

    1022 links in /proc/PID/fd for a limit of 1024: the process has almost used up its descriptors. The service's limit is read in /proc/PID/limits, since ulimit -n only gives the current shell's. Raising the limit without looking for the leak only postpones the failure.

Study this deck