home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / os / linux / 10417 < prev    next >
Encoding:
Text File  |  1992-09-10  |  3.0 KB  |  90 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!rde!ksmith!keith
  3. From: keith@ksmith.uucp (Keith Smith)
  4. Subject: Re: Background processes not dying on parent exit
  5. Organization: Keith's Computer, Hope Mills, NC
  6. Date: Thu, 10 Sep 92 15:11:34 GMT
  7. Message-ID: <1992Sep10.151134.8267@ksmith.uucp>
  8. References: <1992Aug31.071515.24296@klaava.Helsinki.FI> <20189@plains.NoDak.edu> <1992Sep6.225138.11383@klaava.Helsinki.FI>
  9. Lines: 79
  10.  
  11. In article <1992Sep6.225138.11383@klaava.Helsinki.FI> wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) writes:
  12. >I said that children shouldn't be killed when their parent dies.
  13.  
  14. That depends, see below...
  15.  
  16. >
  17. >person@plains.NoDak.edu (Brett G Person ) asks in reply:
  18. >>Why is it done this way?  This is kinda sloppy.  I know that
  19. >>somethimes unix will forget to kill one of my processes, but it
  20. >>doesn't seem to happen very often.  Why would linux be designed this
  21. >>way?   
  22. >
  23. >As far as I am aware, no Unix kills children when the parent dies.  I
  24. >see no reason why processes should be killed for arbitrary reasons like
  25. >some other process dying.
  26.  
  27. That depends on the shell you are using and NATURE of the process.  It
  28. should be up to the forked process whether or not it dies, not the OS. 
  29. The DEFAULT action needs to be death!
  30.  
  31. What SHOULD happen in my experience is the CHILD process should receive
  32. a SIGHUP when the parent dies.  The DEFAULT action for SIGHUP should be
  33. death.  This is VERY important from a minimal security standpoint.
  34.  
  35. The child process can dissassociate itself from it's parent with the
  36. setpgrp() System call.  Alternately it can also choose to trap the
  37. SIGHUP signal and continue on accordingly.
  38.  
  39. In SCO ISC and SVR4 a standard forked shell job dies when you log out
  40. unless it is 'nohup'ed:
  41.  
  42. someprog < /dev/null >$HOME/someprog.out 2>&1 &
  43.  
  44. someprog:
  45. -------
  46. : # For SCO
  47. #!/bin/sh for other stuff
  48.  
  49. while true
  50. do
  51.     date
  52.     sleep 600    # 10 Minutes
  53. done
  54. -------
  55.  
  56. >
  57. >Also, do you think that the following should work:
  58. >
  59. >    #!/bin/sh
  60. >    (sleep 10; echo 10) &
  61. >    (sleep 5; echo 5) &
  62. >
  63. >A similar thing happens with some program, e.g. some mailers leave a
  64. >background child process behind to do the real work, so that the user
  65. >doesn't need to wait as long for a prompt.  Should this be impossible?
  66.  
  67. No,  The script would need to 'nohup' the background children, *OR* the
  68. script itself could be nohup'ed, *OR* the program if written in 'C' can
  69. setpgrp or trap SIGHUP.  Most mailer type jobs will fork and spool the
  70. work, otherwise the set the signal or process group to protect
  71. themselves.
  72.  
  73. >
  74. >Note that doing nohup isn't the answer: it could still be a good idea
  75. >for some leftover child processes of this kind to be killed on hangup.
  76. >
  77.  
  78. Now,  also note that certian shells (tcsh for 1 and I THINK ksh will
  79. warn you at logout, but I'm not sure on this one) Automagically nohup
  80. all the shells doing a signal(SIGHUP,SIG_IGN) before forking it off.
  81.  
  82. >--
  83. >Lars.Wirzenius@helsinki.fi
  84.  
  85.  
  86. -- 
  87. Keith Smith          uunet!ksmith!keith            5719 Archer Rd.
  88. Digital Designs      BBS 1-919-423-4216            Hope Mills, NC 28348-2201
  89. Somewhere in the Styx of North Carolina ...
  90.