Home/ Questions/Q 379969
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T14:56:37+00:00

I have some processes showing up as <defunct> in top (and ps ). I’ve

  • 0

I have some processes showing up as <defunct> in top (and ps). I’ve boiled things down from the real scripts and programs.

In my crontab:

* * * * * /tmp/launcher.sh /tmp/tester.sh

The contents of launcher.sh (which is of course marked executable):

#!/bin/bash
# the real script does a little argument processing here
"$@"

The contents of tester.sh (which is of course marked executable):

#!/bin/bash
sleep 27 & # the real script launches a compiled C program in the background

ps shows the following:

user       24257 24256  0 18:32 ?        00:00:00 [launcher.sh] <defunct>
user       24259     1  0 18:32 ?        00:00:00 sleep 27

Note that tester.sh does not appear–it has exited after launching the background job.

Why does launcher.sh stick around, marked <defunct>? It only seems to do this when launched by cron–not when I run it myself.

Additional note: launcher.sh is a common script in the system this runs on, which is not easily modified. The other things (crontab, tester.sh, even the program that I run instead of sleep) can be modiified much more easily.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Because they haven’t been the subject of a wait(2) system call.

    Since someone may wait for these processes in the future, the kernel can’t completely get rid of them or it won’t be able to execute the wait system call because it won’t have the exit status or evidence of its existence any more.

    When you start one from the shell, your shell is trapping SIGCHLD and doing various wait operations anyway, so nothing stays defunct for long.

    But cron isn’t in a wait state, it is sleeping, so the defunct child may stick around for a while until cron wakes up.

    Update:   Responding to comment…
    Hmm. I did manage to duplicate the issue:

     PPID   PID  PGID  SESS COMMAND
    1  3562  3562  3562 cron
 3562  1629  3562  3562  \_ cron
 1629  1636  1636  1636      \_ sh <defunct>
    1  1639  1636  1636 sleep

    So, what happened was, I think:

    • cron forks and cron child starts shell
    • shell (1636) starts sid and pgid 1636 and starts sleep
    • shell exits, SIGCHLD sent to cron 3562
    • signal is ignored or mishandled
    • shell turns zombie. Note that sleep is reparented to init, so when the sleep exits init will get the signal and clean up. I’m still trying to figure out when the zombie gets reaped. Probably with no active children cron 1629 figures out it can exit, at that point the zombie will be reparented to init and get reaped. So now we wonder about the missing SIGCHLD that cron should have processed.
      • It isn’t necessarily vixie cron’s fault. As you can see here, libdaemon installs a SIGCHLD handler during daemon_fork(), and this could interfere with signal delivery on a quick exit by intermediate 1629

        Now, I don’t even know if vixie cron on my Ubuntu system is even built with libdaemon, but at least I have a new theory. 🙂

    • 0