Date: Tue, 21 Mar 2006 10:09:06 +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: <441F5232.9060701@yahoo.com> In-Reply-To: <20060218011020.GD90689@comp.chem.msu.su> References: <43EAFDB9.9040106@yahoo.com> <20060210085607.GF66940@comp.chem.msu.su> <43F1401F.30102@yahoo.com> <20060218011020.GD90689@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Yar, Thanks for your help with the EKPD problem. I have (finally!) managed to find time to raise a PR on the issue. Please have a look at PR ports/94690. Have a good one. Kind Regards, Jarrod. Yar Tikhiy wrote: >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. > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?441F5232.9060701>