My go-to incantation is `ps ajxf`, (truncated and edited) sample output below<p><pre><code> 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
</code></pre>
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.
<p><pre><code> 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!</code></pre>
Interesting there's no mention of the <i>/proc</i> filesystem (<a href="https://docs.kernel.org/filesystems/proc.html" rel="nofollow">https://docs.kernel.org/filesystems/proc.html</a>).<p><i>cat /proc/<pid>/environ</i> 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.
Annoyingly, what you <i>can't</i> 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 <a href="https://stackoverflow.com/questions/2308653/can-i-use-gdb-to-debug-a-running-process" rel="nofollow">https://stackoverflow.com/questions/2308653/can-i-use-gdb-to...</a>
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.<p>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?