TAYBENGH%NUSDISCS.BITNET@cunyvm.cuny.edu (05/27/90)
Sorry for posted a wrong file earlier!
Hi! Netlander, Sorry to return to all of u lately.
First I have to thank all of u who replied/helped. Thank U!
Here is the summary of the replies regarding detection of process
status. Basically, I am designing a super-server to create/monitor/destroy
server processes. My main objective of monitoring the status of server
processes is detect crash of any server process. Here, I will refer polled
process as server, the process monitoring the status of the server processes
as manager.
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 , which is quite impossible to impose in my server
manager design. Moreover, kill() may not work when the server process
crashes and its process ID is re-assigned to other process.
2) Search the kernel process table (/dev/kmem):
This approach is too OS specific. Portability will be a big problem
even between different Unix OS.
3) Purposely bind a socket to the server port:
If the binding succeeds, then the server is dead since port cannot be
re-used; otherwise if the binding fails and returns an error telling
port in used, then the server is alive. However, this approach faced
the similar problem as technique 1 if the port is re-used by other
process after server crashes and before we bind the socket.
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; slow file I/O operation (read).
"grep" can be used to filter out unnecessary processes information.
I am quite surprisied that nobody suggested this way. This is probably
due to ambiguity in my question asked.
Any comments are welcomed.
- Beng Hang Tay (email: taybengh@nusdiscs)
Dept. of Info. Sys. and Comp. Sc.
National University of Singaporeguy@auspex.auspex.com (Guy Harris) (05/30/90)
> 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.