Path: utzoo!yunexus!hydroesm!jtsv16!torsqnt!news-server.csri.toronto.edu!mailrus!uunet!auspex!guy From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.unix.questions Subject: Re: Correct copy of the summary of checking the status of process u... Message-ID: <3403@auspex.auspex.com> Date: 29 May 90 20:59:37 GMT Article-I.D.: auspex.3403 References: <23451@adm.BRL.MIL> Organization: Auspex Systems, Santa Clara Lines: 39 > 1) Using kill(): > This is the most popular way (judged from the number of > replies). However, I did not adopt this technique because of the > problem that the effective user ID of the server must be the same as > the manager , Nope. The error you get for "the process doesn't exist" is different from the error you get for "it exists, but you don't have permission to send a signal to it". > manager design. Moreover, kill() may not work when the server process > crashes and its process ID is re-assigned to other process. If you can detect the death soon enough, this won't be a problem on most (if not all) UNIX systems, since process IDs are assigned sequentially and it'll take a while before it gets around to reassigning it. > 4) Using "ps" command and pipe it to file: > Personaly I think this is the best and easiest solution. "ps" provides > comprehensive information such as execution filename, process ID, > process state of a process. In addition, almost every system has > similar command. The shortcomings are: overhead in using system() and > re-directing output from "ps" to file; Other disadvantages are: 1) to quote the "ps" man page in SunOS (the quote comes from V7, as I remember, so it's true of lots of versions of UNIX): BUGS Things can change while ps is running; the picture it gives is only a close approximation to the current state. While it'll probably print *something* for every process that exists, it may print complete garbage for the command line, if you're unlucky. 2) The format of "ps" differs between UNIX versions, as do the flags you use to get it to list all processes.