There is absolutely no difference between a thread and a process on Linux. If you look at clone(2) you will see a set of flags that determine what is shared, and what is not shared, between the threads.
Classic processes are just threads that share nothing; you can share what components you want under Linux.
This is not the case on other OS implementations, where there are much more substantial differences.
Here are some examples to find pids of processes named "apache2". There are minor differences (newlines in output) between these and pidof but otherwise ought to work the same, in pipelines, etc.
Using pidof:
$ pidof apache2
31751 31750 31749 31748 31747 31489 31488 31487 31486 31485 1500
Newline-separated:
$ ps aux | grep apache2 | grep -v grep | awk -n '{print $2}'
1500
31485
31486
31487
31488
31489
31747
31748
31749
31750
31751
Space-separated:
$ ps aux | grep apache2 | grep -v grep | awk -n '{printf $2" "}'
1500 31485 31486 31487 31488 31489 31747 31748 31749 31750 31751
I did some silly timings of the above commands.
$ date +%T:%N; pidof apache2 ; date +%T:%N
17:06:05:627088798
31751 31750 31749 31748 31747 31489 31488 31487 31486 31485 1500
17:06:05:634500908
$ date +%T:%N; ps aux | grep apache2 | grep -v grep | awk -n '{printf $2" "}' ; date +%T:%N
17:06:29:887314682
1500 31485 31486 31487 31488 31489 31747 31748 31749 31750 31751
17:06:29:903997288
pidof: 7,412,110 nanoseconds
ps | grep | awk : 16,682,606 nanoseconds
On my machine, pidof is loads faster (as expected).
The output of pidof seems to be sorted reverse, so this would be my preferred alternative incantation:
$ ps aux | grep apache2 | grep -v grep | awk -n '{print $2}' | sort -rn
31751
31750
31749
31748
31747
31489
31488
31487
31486
31485
1500
Best Answer
No, not by default. There is such a thing as too much logging (especially when you start risking logging the action of writing a log entry…).
BSD process accounting (if you have it, run
lastcomm), if active, records the name of every command that is executed and some basic statistics, but not the arguments.The audit subsystem is more general and more flexible. Install the
auditpackage and read the SuSE audit guide (mostly the part about rules), or tryOr: instead of killing it,
kill -STOPit. The STOP suspends the process, no questions asked. You get the option to resume (kill -CONT) or terminate (kill -KILL) later. As long as the process is still around, you can inspect its command line (/proc/12345/cmdline), its memory map (/proc/12345/maps) and so on.Or: attach a debugger to the process and pause it. It's as simple as
gdb --pid 12345(there may be better options for a Java process); attaching a debugger immediately pauses the process (if you exit the debugger, the process receives a SIGCONT and resumes).Note that all this only catches OS-level processes, not JVM threads. You need to turn to JVM features to debug threads.