home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / misc / 4056 < prev    next >
Encoding:
Internet Message Format  |  1992-11-07  |  3.1 KB

  1. Xref: sparky comp.unix.misc:4056 comp.unix.questions:13035 comp.unix.programmer:5188
  2. Newsgroups: comp.unix.misc,comp.unix.questions,comp.unix.programmer
  3. Path: sparky!uunet!gatech!news.ans.net!cmcl2!prism.poly.edu!kapela
  4. From: kapela@prism.poly.edu (Theodore S. Kapela)
  5. Subject: Re: Daemons must never die
  6. Message-ID: <1992Nov6.142250.19952@prism.poly.edu>
  7. Organization: Polytechnic University, New York
  8. References: <id.JVJU.413@ferranti.com> <1992Nov1.114010.464@global.hacktic.nl> <Bx7Ku6.AAq@ns1.nodak.edu>
  9. Date: Fri, 6 Nov 92 14:22:50 GMT
  10. Lines: 55
  11.  
  12. In article <Bx7Ku6.AAq@ns1.nodak.edu> malenovi@plains.NoDak.edu (Nikola Malenovic) writes:
  13. >
  14. >the standard way of creating a daemon process is:
  15. >
  16.  [ TEXT DELETED }
  17. >
  18. >/* child continues!!! */
  19. >setsid();/* become a session leader! */
  20.  
  21. Most daemons also redirect stderr, stdout, and stdin to /dev/null.
  22. A dup2(2V) for each of these fits the bill.
  23.  
  24. >NOTE the following: fork() does not guarantee who will be run first - in
  25. >case that the parent gets started first, it will kill itself and the child
  26. >will receive SIGKILL too! then all the forking was futile. in order to be
  27.  
  28. This is not true.  Signals do not necesarily get passed from parent to child.
  29. If kill(2V) is passed a process id of 0, it sends the signal specified to
  30. all processes in the calling program's process group.  If the pid is
  31. a positive value, only that process receives the signal.  If the pid is
  32. negative, then all processes in the same process group as the process
  33. specified by pid will recieve the signal.  killpg(2) may also be used
  34. for this.
  35.  
  36. >SURE that the child will have time to do setsid() BEFORE the parent dies
  37. >(and kills the child by killing itself too!) you can either use the 'sure'
  38. >way - vfork(), which guarantee that the child will be run first, OR have
  39.  
  40. Ah, but vfork(2) does not *necesarily* guarantee that the parent will block
  41. until the child exits.  With SunOS 4.X, vfork(2) spawns a new process, 
  42. using all of the parent's resources (memory, file descriptors (and the 
  43. objects they reference), etc. . .) With this implementation, the 
  44. parent is blocked until the child process exits (via _exit(2V) 
  45. (*not* exit(2)) or via an execve(2V)).  If the child never exits, 
  46. the parent never continues.
  47.  
  48. With AIX 3.X, vfork(2) is implemented similar to fork(2V):  A completely
  49. new process is started, in its own address space, using none of the parent's
  50. resources.  With this implementation, the parent does *NOT* block, and
  51. may continue on.
  52.  
  53. >to loose the CPU, and if the CPU scheduling is round-robin, you hope that
  54. >between sleep(1) and the next CPU burst time of the parent, the child will
  55.  
  56. You don't need to worry about this.  BSD4.3 NET2 (and BSD4.4) have a
  57. routine daemon() in libutil that system daemons use.  It essentially does
  58. a fork(), parent exit(), child setsid(), child dup2() once each on
  59. stdin, stdout, stderr filenos.  I have used similar code many times, and
  60. it is always reliable.
  61.  
  62. -- 
  63. ..............................................................................
  64.  Theodore S. Kapela                kapela@poly.edu
  65.  Center for Applied Large-Scale Computing    
  66.  Polytechnic University
  67.