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!
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.
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).
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!
`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.
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?
