So, what can you do with a process ID?

  • My go-to incantation is `ps ajxf`, (truncated and edited) sample output below

       PPID   PID  PGID   SID TTY      TPGID STAT   UID   TIME COMMAND
          0     1     1     1 ?           -1 Ss       0   0:57 /sbin/init splash
          1   978   978   978 ?           -1 Ss       0   0:00 /usr/sbin/sshd -D
        978 11441 11441 11441 ?           -1 Ss       0   0:00  \_ sshd: ghostpepper [priv]
      11441 11445 11441 11441 ?           -1 S     1000   0:00      \_ sshd: ghostpepper@pts/4
      11445 11446 11446 11446 pts/4    11641 Ss    1000   0:00          \_ -bash
      11446 11641 11641 11446 pts/4    11641 R+    1000   0:00              \_ ps ajxf
    
    Another thing some might not know is that kill (the command / syscall) can send a lot of other signals than KILL (the signal). Not all processes know how to gracefully handle them, so you need to be careful, but for example a lot of daemons can catch SIGHUP and re-load their config file from disk.

  •   Way hay we're out of memory
      Way hay our disk is thrashing
      Way hay I need more coffee
      Early in the morning!
    
      What can you do with a process ID
      What can you do with a process ID
      What can you do with a process ID
      Early in the morning?
    
      Send a SIGKILL to its process
      Send a SIGKILL to its process
      Send a SIGKILL to its process
      Early in the morning!

  • Interesting there's no mention of the /proc filesystem (https://docs.kernel.org/filesystems/proc.html).

    cat /proc/<pid>/environ would be a solid addition to this list.

  • On Linux one of my favourite tools to display metrics about a process in real time, such as cpu/memory/io utilisation, which can also be broken down per thread (with friendly thread names displayed if your application sets them), is pidstat from the sysstat package.

  • And with strace -p pid you can somewhat "spy" on what a process is doing.

  • Annoyingly, what you can't always do is use it to uniquely identify a process. After a process exits, its PID can be reused. On Linux this (by default) only happens after PID 32767 is assigned, but generally it's implementation-defined. A rare edge case, of course, but it can have security implications.

  • On modern kernels you can do some really interesting things like "pidfd_open" and "pidfd_getfd" to get a duplicate file descriptor from the process referred to by the pidfd.

  • Another nice addition would have been debuggers such as gdb -p PID to hook into the running code, see for instance https://stackoverflow.com/questions/2308653/can-i-use-gdb-to...

  • Could have written disclaimer in the 'kill -HUP' example that they should be only sent when it is known that the destination process will handle it, as the default for most signals is to terminate the process.

    Especially since every other example is non-destructive...

  • I know about some of these tricks. However, containers are popular and typically don’t have the tools installed, and you can’t necessarily sudo either. What do people replace these tricks with, in some cloud container or k8s pods?

  • For a moment I thought the topic was about PID controllers. That would have been cool.

    If the blogging gods take requests I just made one.

  • When I was a chemist we used photoionization detectors to detect VOCs in groundwater.