EKPD daemon in /usr/local/etc/rc.d getting killed before login

[Yar Tikhiy]

On Tue, Feb 14, 2006 at 11:27:43AM +0900, Jarrod wrote:
> Hi Yar,
> 
> Thanks a lot for you comments. I've inserted some responses below.
> 
> Yar Tikhiy wrote:
> 
> >On Thu, Feb 09, 2006 at 05:30:49PM +0900, Jarrod wrote:
> > 
> >
> >>Looking around at some of the system daemons I ended up taking a leaf 
> >>out of lpd.c and changing the daemon's startup code from doing a regular 
> >>"fork()" to doing a "daemon(0, 0)" call instead.
> >>
> >>At this stage it looks like the problem is solved.
> >>
> >>My question is: Is there some documentation or warning somewhere which 
> >>would have aided me in resolving this problem?
> >>   
> >>
> >
> >Perhaps the ekpd daemon hits some configuration/communication problems
> >and chooses to terminate?  Most daemons can log their activity, so you
> >may want to investigate if it is possible by means of a configuration
> >file or command-line arguments to tell ekpd to log its actions to a file
> >or to a syslog facility.  In the latter case (syslog) you'll need to
> >make sure that the facility used really gets logged to a file -- see
> >syslog(8) and syslog.conf(5).
> > 
> >
> The code for the ekpd daemon does not appear to do much in the way of 
> logging. I put a liberal amount of trace statements in using the syslog 
> command to try and determine where and why it was shutting down, but 
> without much success.
> 
> >>I read all the material I could find on the rc.d system and but I didn't 
> >>see anything that suggested just doing a regular fork() would get you in 
> >>trouble. I assume the problem has something to do with why the 
> >>"daemon()" function exists in the first place?
> >>
> >>Is there any possibility that there could be a check somewhere in the rc 
> >>system or ports system to prevent programs that don't call "daemon()" to 
> >>initialize from being installed in rc.d?
> >>   
> >>
> >
> >This is hardly possible.  The only case I can think of is when a
> >program forks into background and then tries to do terminal IO --
> >it will receive a signal.  The daemon() function closes standard
> >IO descriptors and thus prevents the program from doing any IO on
> >them later.  If this is the case, ekpd will die if started manually
> >by running "/usr/local/etc/rc.d/ekpd start", too.
> > 
> >
> Thanks for the help here. I went and had a look at the daemon() function 
> itself:
> http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/gen/daemon.c
> 
> in the CVS repository. It seems to do three main things as far as I can 
> tell:
> 
> 1. Catches a signal that (possibly?) gets thrown when the parent exits.
> 2. Calls the setsid() function.
> 3. Closes the stdio file descriptors.
> 
> Since I couldn't see the EKPD daemon doing much IO I decided to play 
> around with the setsid() function. I let EKPD do the usual fork() 
> (taking out my daemon() call) and then did a setsid() straight after.
> 
> Voila! This seems to work. The daemon no longer bails at the end of startup.
> 
> I'm not much of an expert on UNIX processes, but is it possible that 
> when the parent shell process running all the scripts in rc.d/ finishes, 
> any child processes that haven't detached, using setsid() or similar, 
> are killed off?

While I don't fully understand this particular case, killing off such
child processes is possible.  It is documented in _exit(2):

     o   If the process is a controlling process (see intro(2)), the SIGHUP
         signal is sent to the foreground process group of the controlling
         terminal, and all current access to the controlling terminal is
         revoked.

Some cases with daemons are considered in PR bin/25462.

> From a useability perspective is it worth raising a PR? I just wonder 
> if it might not be nice to have a warning printed up somewhere when you 
> installed a script into the rc.d directory to save newbies (like me) 
> getting unnecessarily frustrated! :)

I think that the solution is to add a trivial patch substituting
daemon() for fork() in the port.  Depending on your free time etc,
you may either suggest this in the PR or include the patch in it.
A PR is a good idea in any case.

-- 
Yar