On Linux, ps
reports kernel threads in square brackets. These are not "processes" in the normal sense of that word. That is, there is not an executable loaded from disk to start them, they aren't owned by a normal user, etc. They're just one of the many things the kernel has going on in the background.
For that reason, the name shown by ps
doesn't have to correspond to any file on your hard disk. (In the case of zombie processes, though, it does.)
In the beginning, if you had something to contribute (a patch or a bug report), you mailed it to Linus. This evolved into mailing it to the list (which was linux-kernel@vger.rutgers.edu
before kernel.org
was created).
There was no version control. From time to time, Linus put a tarball on the FTP server. This was the equivalent of a "tag". The available tools at the beginning were RCS and CVS, and Linus hates those, so everybody just mailed patches. (There is an explanation from Linus about why he didn't want to use CVS.)
There were other pre-Bitkeeper proprietary version control systems, but the decentralized, volunteer-based development of Linux made it impossible to use them. A random person who just found a bug will never send a patch if it has to go through a proprietary version control system with licenses starting in the thousands of dollars.
Bitkeeper got around both of those problems: it wasn't centralized like CVS, and while it was not Free Software, kernel contributors were allowed to use it without paying. That made it good enough for a while.
Even with today's git-based development, the mailing lists are still where the action is. When you want to contribute something, you'll prepare it with git of course, but you'll have to discuss it on the relevant mailing list before it gets merged. Bugzilla is there to look "professional" and soak up half-baked bug reports from people who don't really want to get involved.
To see some of the old bug-reporting instructions, get the historical Linux repository. (This is a git repository containing all the versions from before git existed; mostly it contains one commit per release since it was reconstructed from the tarballs). Files of interest include README
, MAINTAINERS
, and REPORTING-BUGS
.
One of the interesting things you can find there is this from the Linux-0.99.12 README:
- if you have problems that seem to be due to kernel bugs, please mail
them to me (Linus.Torvalds@Helsinki.FI), and possibly to any other
relevant mailing-list or to the newsgroup. The mailing-lists are
useful especially for SCSI and NETworking problems, as I can't test
either of those personally anyway.
Best Answer
Try the
psacct
package (GNU accounting), it should do just about everything you need, once installed and enabled (accton
), thenlastcomm
will keep report on user processes (see alsosa
anddump-acct
). See this for reference: User's executed commands log fileYou might need to upgrade the version to log PID/PPID, see https://serverfault.com/questions/334547/how-can-i-enable-pid-and-ppid-fields-in-psacct-dump-acct , otherwise I suspect it will under-report on
fork()
withoutexec()
.Update If your
lastcomm
outputsF
in the 2nd column it means the process was a fork (that never calledexec()
to replace itself with a new process). The output ofdump-acct
should show you the PID (and PPID) in acct v3 format.An alternative to psacct might be the new(ish)
taskstats
, there's not a huge amount of support for it yet AFAICT, seeDocumentation/accounting/taskstats.txt
in your kernel version source. This might help get you startedhttp://code.google.com/p/arsenalsuite/wiki/TrackingIOUsagehttps://code.google.com/archive/p/anim-studio-tools/ The specific code example istasklogger.c
, you will need to modify theprintf()
line in functionprint_delayacct2()
, firstly to replace%u
with%llu
for the__u64
types and secondly to add the fieldac_uid
(and perhapsac_gid
) that you need to track by user. Invoke it with something liketasklogger -dl -m 0-1
(where-m 0-1
indicates CPUs 0-1). You will then see realtime details as each process exits.There is also a perl module
Linux::Taskstats::Read
available on CPAN, though I have not used it.You'll need to process the data based on timestamps if you want the concurrent process count per-user, this is not a simple as it sounds.
Update 2 Ok, the things to check for the required
psacct
support are:CONFIG_BSD_PROCESS_ACCT
andCONFIG_BSD_PROCESS_ACCT_V3
enabledpsacct
) package, as noted aboveAll of the above should be true in CentOS 6, I've checked a 5.x and it does not have
CONFIG_BSD_PROCESS_ACCT_V3=y
, so you would have to rebuild your kernel to enable it.The original
psacct-6.3.2
is about 15 years old, the Red Hat/CentOS version has backported v3 and PID display support (I can't test it right now, but it should work).To check a your kernel config: