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!cat /proc/<pid>/environ would be a solid addition to this list.
I use /proc/$PID/limits quite a bit in particular
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.
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!
Especially since every other example is non-destructive...
If the blogging gods take requests I just made one.