Detecting running processes... this one's portable

[mouse at mcgill-vision.UUCP]

[ various discussion on how to find whether process number
  such-and-such is still alive ]

> This is better than another suggestion, involving the line,
> "ps x | fgrep pid# | fgrep -v fgrep", for three reasons.  First of
> all, it's simpler.  Second, the fgrep method will often find strings
> you're not looking for:  like job number 22299 when you're looking
> for job 222
Or suppose the process you are looking for is running fgrep, or uses
fgrep as an argument on the command line....or how about finding some
joker's "expr 222 + 333" process?

I wrote a program "findproc" which forked ps and read the output
looking for a process whose "command" contained a string (which was
given as an argument to findproc).  It filtered out the ps in question
and the findproc process itself.  Something similar could be done (but
would be messy and unecessary from C, as we shall see).

By the way, anyone who wants findproc is welcome to it, but I make no
promises if you're not on 4.2BSD.

> But this all concerns the general question, "what is the most efficient 
> portable UNIX method for checking whether a process exists, given a pid#".
> In fact, it would be good enough to answer four questions:  what is the most
> efficient way to do this:
> 	1) in bsd systems, from the shell
If you know it's running, try sending it a CONT signal (kill -CONT #)
Otherwise, I suspect you will have to ps and grep for it.  Someone
recently posted some mods to ps that make it keep things like /vmunix's
nlist and the stats of /dev in a file somewhere; these should speed it
up greatly.

> 	2) in bsd systems, from a C-program
if (kill(pid,0) < 0)
 { /* process dead, or no privilege (check errno, ESRCH means it's dead) */
 }
else
 { /* process still alive */
 }
This is given in the MAN PAGE!  Why not read the manual?  You're never
gonna get more efficient than one syscall, no matter what you try....
Well, if you hack the kernel (or are running a derivative with mmap()
implemented), I suppose you could double-map /dev/kmem and search
through the process table yourself.  Highly non-portable (depends on
the exact format of the proc struct, on having support and privilege
for double-mapping kernel memory....I think we can ignore the
possibility).

> 	3) in at&t systems, from the shell
> 	4) in at&t systems, from a C-program.
Ask someone else, I have never had the misfortune to be subjected to
AT&T's excuse for UNIX to the extent necessary to learn this sort of
detail.
-- 
					der Mouse

USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse
     think!mosart!mcgill-vision!mouse
Europe: mcvax!decvax!utcsri!mcgill-vision!mouse
ARPAnet: utcsri!mcgill-vision!mouse at uw-beaver.arpa

"Come with me a few minutes, mortal, and we shall talk."
			- Thanatos (Piers Anthony's Bearing an Hourglass)