kill(pid, 0) is also a classic trick for detecting crappy rootkits; cycle through all ~65k possible pids, and see if the ESRCH results agree with "ps -axo pid". A patched ps, a patched KVM library, or even a patched procfs can still miss the code path used by the kill(2) syscall.

How enlightening. I wish sites like commandlinefu.com had more insight into interesting command line tricks like this.

When I read that, I thought why didn't I know about this? So I checked the man page (not that I often read the man pages) and, at least on the version for my Mac, the man page doesn't describe signal zero. Sigh. How do people find out about these things?

You learn these things when you are a junior X from someone who is a senior X who learned it the exact same way. I bet you can trace these little nuggets all the way back to some junior sysadmin who was looking over Ken Thompson's shoulder at Bell Labs in the early 70s. Other examples include lsof, vmstat, netstat -p, and doing anything useful in a Makefile.

Any defined interface is -- by definition -- documented, and any undefined interface (and thus undocumented) can not be relied upon.

Empiric lore is ultimately detrimental to genuine understanding.

It's referenced by the kill(2) syscall documentation:

'A value of 0, however, will cause error checking to be performed (with no signal being sent). This can be used to check the validity of pid.'

On Mac OS X, the actual kernel implementation is: if (uap->signum) psignal(p, uap->signum);

So if signum == 0, no signal is sent, but this occurs after the destination (and permissions) are checked for validity.

I'm guessing a zombie'd process won't respond either. Which is good if you are checking for validity of a process and not just the mere presence of a pid in the process list.