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

[Jarrod]

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.
>
>  
>