So, what can you do with a process ID? | Hacker News Reader

So, what can you do with a process ID?

will-keleher.com

90 pointsgcmeplz25 comments

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!

But what do you do with a zombie process? I haven't found the lyrics that tell me.

https://en.wikipedia.org/wiki/Drunken_Sailor

Love it, couldn't help but sing!

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.

Yep - a bunch of ways to read/use proc in arguably roundabout ways (things you may not be able to install)... but no mention of /proc

I use /proc/$PID/limits quite a bit in particular

True, but as written it has advice applicable to non-linux environments like MacOS, which don't have /proc.

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.

There us a hugely non-trivial (on the order of 100x) slowdown in code running when strace does its thing.

Brendan Gregg's work in the field of performance analysis (eBPF to the rescue) is quite useful in this regard, though not without tradeoffs (AFAIK: need compiler tools on the system to compile eBPF code).

Using `perf` may be a decent middle ground.

This. (Combine with sudo too!)

Now if I could just track NFS client traffic on a client associated with a PID (without having NFS server access). All I can get is all-PID/client-kernel data info vi nfsstat, nothing tying to a PID, filename, directory or inode to tell me which PID is causing all the NFS traffic!

    iotop?

Tried it, I think the problem is the nfs io comes from the kernel and is not tied to a PID?

`lsof -p pid` can also be a good way of determining what a process is doing at a given point in time, if you're just trying to figure out what files it has open.

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?

If /proc is mounted in the container you can grab the same information (more tediously) by looking at /proc/<pid>

Some things are there, but real tedious, yes. I haven’t found something convenient and if you’re not root, some of the useful things are inaccessible.

Could you copy in (or sideload) a statically linked "top" binary?

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.

In the meantime, we've macroexpanded that acronym in the title above.

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

Reply on news.ycombinator.com