Warum Prozesse hervorgebracht, die von cron am Ende Karteileichen?

Habe ich einige Prozesse zeigt sich als <defunct> im top (und ps). Ich habe gekochte Dinge nach unten aus der real-Skripte und Programme.

In meinem crontab:

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

Den Inhalt launcher.sh (das ist natürlich als ausführbar gekennzeichnet):

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

Den Inhalt tester.sh (das ist natürlich als ausführbar gekennzeichnet):

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

ps zeigt Folgendes:

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

Beachten Sie, dass tester.sh nicht angezeigt-es beendet sich nach dem starten der hintergrund-job.

Warum launcher.sh stick herum, markiert <defunct>? Es scheint nur dies zu tun, wenn es gestartet wird, indem cron - nicht dann, wenn ich es mir selber.

Zusätzlicher Hinweis: launcher.sh ist ein gemeinsames Skript in das system läuft auf, die nicht leicht modifiziert werden. Die anderen Dinge ( crontab , tester.sh auch das Programm, dass ich laufen statt sleep) modiified viel leichter.

InformationsquelleAutor der Frage John Zwinck | 2009-10-01

  1. 11

    Weil Sie noch nicht Gegenstand einer wait(2) system nennen.

    Da jemand kann warten, bis diese Prozesse in der Zukunft, kann der kernel nicht vollständig von Ihnen befreien oder Sie werden nicht in der Lage zu führen Sie die wait system nennen, weil es nicht den exit-status oder Beweise für seine Existenz nicht mehr.

    Beim start aus der shell die shell ist trapping SIGCHLD und macht verschiedene Operationen warten sowieso, also nichts bleibt stillgelegt lang.

    Aber cron nicht in einen wait-Zustand, es schläft, so dass der aufgelösten Kind bleiben, um für eine Weile, bis der cron aufwacht.

    Update:   Reagiert mit Kommentar...
    Hmm. Ich habe es geschafft, die doppelte Frage:

     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

    Also, was geschah, war, glaube ich:

    • cron-Gabeln und cron Kind beginnt shell
    • shell (1636) beginnt der sid pgid 1636 und beginnt zu schlafen
    • shell beendet, SIGCHLD gesendet cron-3562
    • signal wird ignoriert oder misshandelt
    • shell verwandelt zombie. Beachten Sie, dass Schlaf ist reparented init, so wird, wenn der Ruhezustand beendet ist, wird init Sie das signal bekommen und zu bereinigen. Ich bin immer noch versuchen, herauszufinden, Wann der zombie bekommt geerntet. Wahrscheinlich ohne aktive Kinder cron 1629 zahlen, es beenden kann, an diesem Punkt die zombie sein reparented auf init bekommen und genutzt. So, jetzt Wundern wir uns über die fehlende SIGCHLD, dass cron sollte verarbeitet haben.
      • Es ist nicht unbedingt vixie cron Schuld. Wie Sie hier sehen können, libdaemon installiert ein SIGCHLD-handler während daemon_fork()und dies könnte stören die Signalübermittlung auf eine schnelle Ausfahrt durch zwischen 1629

        Nun, ich weiß gar nicht, ob vixie cron auf meinem Ubuntu system ist selbst gebaut mit libdaemon, aber zumindest habe ich eine neue Theorie. 🙂

    InformationsquelleAutor der Antwort DigitalRoss

  2. 4

    Ich vermute, dass cron wartet für alle Teilprozesse in die Sitzung zu beenden. Siehe wait(2) mit Bezug auf negative pid-Argumente. Sie können sehen, das SESS mit:

    ps faxo stat,euid,ruid,tty,tpgid,sess,pgrp,ppid,pid,pcpu,comm

    Hier ist, was ich sehe (bearbeitet):

    STAT  EUID  RUID TT       TPGID  SESS  PGRP  PPID   PID %CPU COMMAND
Ss       0     0 ?           -1  3197  3197     1  3197  0.0 cron
S        0     0 ?           -1  3197  3197  3197 18825  0.0  \_ cron
Zs    1000  1000 ?           -1 18832 18832 18825 18832  0.0      \_ sh <defunct>
S     1000  1000 ?           -1 18832 18832     1 18836  0.0 sleep

    Beachten Sie, dass die sh und der Schlaf sind in der gleichen SESS.

    Verwenden Sie den Befehl setsid(1). Hier tester.sh:

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

    Bemerken, die Sie nicht brauchen &setsid stellt es in den hintergrund.

    InformationsquelleAutor der Antwort bstpierre

  3. 3

    Ich würde empfehlen, dass Sie das problem lösen, indem Sie einfach nicht mit zwei separaten Prozessen: launcher.sh dies auf seiner letzten Zeile:

    exec "$@"

    Dadurch wird der überflüssige Prozess.

    InformationsquelleAutor der Antwort Teddy

  4. 3

    meiner Meinung nach verursacht durch den Prozess CROND (erzeugt durch crond für jede Aufgabe) erwartet eine Eingabe auf stdin ist eine Pipe an den stdout/stderr von Befehl in die crontab. Dies geschieht, weil cron ist in der Lage, senden Ausgabe per E-mail an den Benutzer.

    So CROND wartet auf EOF, bis der Benutzer den Befehl und alle seine Kind-Prozesse erzeugt haben geschlossen, die Leitung. Wenn dies geschehen ist CROND setzt sich mit der wait-Anweisung und dann die aufgelösten user-Befehl verschwindet.

    So, ich denke, Sie haben explizit trennen Sie alle gespawnt Teilprozess in Ihrem Skript in form der Leitung (z.B. durch umleiten in eine Datei oder /dev/null.

    also die folgende Zeile sollte in die crontab :

    * * * * * ( /tmp/launcher.sh /tmp/tester.sh &>/dev/null & )

    InformationsquelleAutor der Antwort hp4

  5. 1

    Fand ich diese Frage, während ich war auf der Suche für eine Lösung mit einem ähnlichen Problem. Leider Antworten in dieser Frage nicht mein problem lösen.

    Töten außer Kraft gesetzte Prozess ist nicht eine option, müssen Sie finden und töten seine übergeordneten Prozess. Ich landete in der Tötung der außer Kraft gesetzte Prozesse auf folgende Weise:

    ps -ef | grep '<defunct>' | grep -v grep | awk '{print "kill -9 ",$3}' | sh

    In "grep "" können Sie eingrenzen der Suche auf eine bestimmte aufgelösten Prozess sind Sie nach.

    InformationsquelleAutor der Antwort Datageek

  6. -2

    Ich getestet habe das gleiche problem, so viele Male.
    Und endlich habe ich die Lösung.
    Geben Sie einfach die '/bin/bash' vor dem bash-Skript wie unten gezeigt.

    * * * * * /bin/bash /tmp/launcher.sh /tmp/tester.sh

    InformationsquelleAutor der Antwort user377713

Schreibe einen Kommentar