home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / unix / question / 14604 < prev    next >
Encoding:
Internet Message Format  |  1992-12-11  |  1.7 KB
  1. Xref: sparky comp.unix.questions:14604 comp.unix.programmer:5657
  2. Path: sparky!uunet!think.com!barmar
  3. From: barmar@think.com (Barry Margolin)
  4. Newsgroups: comp.unix.questions,comp.unix.programmer
  5. Subject: Re: Determining the state of a process on another host
  6. Date: 11 Dec 1992 20:36:52 GMT
  7. Organization: Thinking Machines Corporation, Cambridge MA, USA
  8. Lines: 27
  9. Message-ID: <1gau54INNndc@early-bird.think.com>
  10. References: <1992Dec10.154438.13881@dd.dk>
  11. NNTP-Posting-Host: telecaster.think.com
  12. Keywords: TCP IP sockets host process kill
  13.  
  14. In article <1992Dec10.154438.13881@dd.dk> wes@dd.dk (Mads Westermann) writes:
  15. >I'm currently writing a client-server application that uses BSD
  16. >sockets to communicate. At certain stages in the processing I
  17. >want to be able to determine whether the client process is
  18. >running/alive. 
  19.  
  20. If you're using a stream socket, you can try to write something to it.
  21. When the client process died, the remote system should have closed the
  22. connection.  If you try to write to a closed connection you should get an
  23. error (EPIPE, I think).
  24.  
  25. >        If the client is running on the same machine I
  26. >can just do a kill(..,0), but if the client is running on another
  27. >machine - what do I do then ?? I have the hostname, the remote pid,
  28. >the username and the remote tty-name available on the server. Is 
  29. >there any way of doing a remote kill(...,0) ??
  30.  
  31. You could implement a process_status daemon server that runs on the client
  32. machine.  You send it a pid, it performs the kill(pid,0), and sends the
  33. result back to you.  Should be trivial to write using RPC utilities, or
  34. even using straight UDP.
  35.  
  36. -- 
  37. Barry Margolin
  38. System Manager, Thinking Machines Corp.
  39.  
  40. barmar@think.com          {uunet,harvard}!think!barmar
  41.