re: bin/41302: cron dies at startup

[matthew green <mrg%eterna.com.au@localhost>]

The following reply was made to PR bin/41302; it has been noted by GNATS.

From: matthew green <mrg%eterna.com.au@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, 
martin%duskware.de@localhost
Subject: re: bin/41302: cron dies at startup
Date: Thu, 30 Apr 2009 17:06:29 +1000

    
    From: "Jeremy C. Reed" <reed%reedmedia.net@localhost>
    To: gnats-bugs%NetBSD.org@localhost
    Cc: 
    Subject: Re: bin/41302: cron dies at startup
    Date: Wed, 29 Apr 2009 09:02:17 -0500 (CDT)
    
     I wonder if this is related to
     http://mail-index.netbsd.org/netbsd-users/2009/02/09/msg002977.html
 
 
 i think it's the same problem.
 
 that one is very strange.  clearly it is dying in daemon() right
 after fork returns... but it has something to do with SIGHUP occuring
 right at this moment:
 
 
    429      1 cron     CALL  fork
    429      1 cron     RET   fork 343/0x157
    429      1 cron     CALL  exit(0)
    343      1 cron     EMUL  "netbsd"
    343      1 cron     PSIG  SIGHUP caught handler=0x102880 mask=(): 
 code=SI_NOINFO
    343      1 cron     RET   fork 0
    343      1 cron     CALL  setcontext(0xffffffffffffb660)
    343      1 cron     RET   setcontext JUSTRETURN
    343      1 cron     CALL  getpid
    343      1 cron     RET   getpid 343/0x157, 1
    343      1 cron     CALL  gettimeofday(0xffffffffffffab40,0)
    343      1 cron     RET   gettimeofday 0
 
 
 429 is the parent, and 343 is the child.  the parent fork()'s and exits
 just like in daemon() but the child doesn't really get to run any more.
 the first thing it should do is call setsid(), but we don't see that
 before we see the failure starting (getpid/gettimeofday both are used
 to generate the failure message.)
 
 cron has a SIGHUP handler that looks like:
 
 static void
 sighup_handler(int x __unused)
 {
         log_close();
 }
 
 void 
 log_close(void) { 
         if (LogFD != ERR) {
                 close(LogFD);
                 LogFD = ERR;
         }
 }
 
 in the above log, pid 343 starts in emul netbsd, gets a SIGHUP and
 has a handler (does it run here?  i'm not sure.) but then we get
 the RET into this child right after, and then a setcontext... i'm
 not sure what exactly is going on here, but this is clearly where
 it all goes wrong.  why is a SIGHUP happening, and why is it making
 the child fail?
 
 
 .mrg.