mouse@mcgill-vision.UUCP (08/08/86)
[ 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@uw-beaver.arpa "Come with me a few minutes, mortal, and we shall talk." - Thanatos (Piers Anthony's Bearing an Hourglass)