lkml.org 
[lkml]   [1998]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Possible bug in wait4(), 2.1.126-129 ?
    Date
    Ion Badulescu writes ("Re: Possible bug in wait4(), 2.1.126-129 ?"):
    >
    > 4. the program *must* be run from cron, doesn't matter which user.
    >[snip]
    >
    > wait4: No child processes

    The different behaviour comes from cron, not the kernel.
    Have a look at /proc/self/status for a process run from cron.
    On a libc5, 2.0.35 system running vixie-cron 3.0.1, I found:
    SigIgn: 80000000
    On a libc6, 2.1.125 system running vixie-cron 3.0.1, I found:
    SigIgn: 0000000000010000
    ^
    Ignoring SIGCHLD causes automatic child reaping.

    The difference comes from vixie-cron-3.0.1/do_command.c:

    #ifdef USE_SIGCHLD
    /* our parent is watching for our death by catching SIGCHLD. we
    * do not care to watch for our children's deaths this way -- we
    * use wait() explictly. so we have to disable the signal (which
    * was inherited from the parent).
    */
    (void) signal(SIGCHLD, SIG_IGN);
    #else
    /* on system-V systems, we are ignoring SIGCLD. we have to stop
    * ignoring it now or the wait() in cron_pclose() won't work.
    * because of this, we have to wait() for our children here, as well.
    */
    (void) signal(SIGCLD, SIG_DFL);
    #endif /*BSD*/

    I suspect the difference is in the way that the configure script
    interacted with the libc. In the USE_SIGCHLD case, you need
    signal(SIGCLD, SIG_DFL) below the vfork to reset the signal handling
    for the grandchild process.

    Peter

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:45    [W:0.021 / U:1.044 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site