Date: Tue, 14 Feb 2006 11:27:43 +0900 From: Jarrod <jofsama@yahoo.com> To: Yar Tikhiy <yar@comp.chem.msu.su> Cc: freebsd-rc@freebsd.org Subject: Re: EKPD daemon in /usr/local/etc/rc.d getting killed before login Message-ID: <43F1401F.30102@yahoo.com> In-Reply-To: <20060210085607.GF66940@comp.chem.msu.su> References: <43EAFDB9.9040106@yahoo.com> <20060210085607.GF66940@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
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? 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! :) Cheers, Jarrod.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43F1401F.30102>