home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / sun / admin / 6240 < prev    next >
Encoding:
Internet Message Format  |  1992-09-10  |  2.1 KB
  1. Xref: sparky comp.sys.sun.admin:6240 comp.unix.admin:4980
  2. Newsgroups: comp.sys.sun.admin,comp.unix.admin
  3. Path: sparky!uunet!mcsun!sun4nl!eur.nl!pk
  4. From: pk@cs.few.eur.nl (Paul Kranenburg)
  5. Subject: Re: biff not biffing
  6. Message-ID: <1992Sep9.123044.27574@cs.few.eur.nl>
  7. Sender: news@cs.few.eur.nl
  8. Reply-To: pk@cs.few.eur.nl
  9. Organization: Erasmus University Rotterdam
  10. References: <1992Aug29.190229.19212@europa.asd.contel.com> <1992Aug29.202158.22016@europa.asd.contel.com> <1992Aug29.211845.21326@ccu.umanitoba.ca> <BtxGD1.1sM@cs.psu.edu>
  11. Date: Wed, 9 Sep 1992 12:30:44 GMT
  12. Lines: 32
  13.  
  14. In <BtxGD1.1sM@cs.psu.edu> kenh@leps5.phys.psu.edu (Ken Hornstein) writes:
  15.  
  16. >In article <1992Aug29.211845.21326@ccu.umanitoba.ca> mills@ccu.umanitoba.ca (Gary Mills) writes:
  17. >>In <1992Aug29.202158.22016@europa.asd.contel.com> pascoe@rocky.gte.com (Dave Pascoe) writes:
  18. >>
  19. >>>commented out comsat in /etc/inetd.conf and sent a kill -1 to inetd
  20. >>>and then uncommented comsat and sent another kill -1.
  21. >>
  22. >>>The comsat daemon was out to lunch for some reason.  This is a common
  23. >>>problem on machines which handle a lot of mail, since the comsat
  24. >>>daemon can tend to get confused at to what state it's in when a SIGHUP
  25. >>>to inetd comes along.
  26. >>
  27. >>I have seen this same behavior with other daemons started from inetd,
  28. >>and I suspect that the bug is in inetd.  It apparently assumes that
  29. >>a particular daemon is running when it rereads its config file and then
  30. >>refuses to start another one.
  31.  
  32. >I've seen this happen before with tftpd.  At our site we use tftpd to download
  33. >fonts to our X terminals.  More than once I was adding or deleting a service
  34. >to inetd.conf and when I sent inetd the HUP signal it refused to run tftpd
  35. >again ("Hey, why do I suddenly get the error message 'Cannot load 8x12'?").
  36. >Whoops :-)  Killing and restarting inetd fixed the problem.
  37.  
  38. It definitely is a bug in Sun's inetd. It doesn't honour the "wait" field
  39. when processing a HUP signal (while the service is "active").
  40.  
  41. I have reported this bug a long time ago to our local Sun helpdesk (Netherlands)
  42. but never received a fix. I ended up modifying the BSD inetd to replace Sun's
  43. (we needed other functionality anyway).
  44.  
  45. -pk
  46.