Warum unix-Prozesse im hintergrund manchmal sterben, wenn ich beenden meine shell?

Ich wollte wissen, warum ich da ein anderes Verhalten in den hintergrund-Prozess in der Bash-shell

Fall 1: Angemeldet an Unix-server mit Putty(SSH)

  • Standardmäßig verwendet die csh-shell
  • Wechselte ich in die bash-shell
  • eingegeben sleep 2000 &
  • drücken Sie die EINGABETASTE

Er gab mir die Nummer des Druckauftrags. Nun tötete ich meine Sitzung, indem Sie auf das " x " in das putty-Fenster
Öffnen Sie nun eine weitere Sitzung und versucht, die lookup-Prozess..der Prozess starb.

Fall 2:Fall 1: Angemeldet an Unix-server mit Putty(SSH)
Standardmäßig verwendet die csh-shell

  • Wechselte ich in die bash-shell
  • vi mysleep.sh
  • Schlaf-2000 & Gespeichert mysleep.sh
  • ./mysleep.sh

Diff hier ist..statt der Ausführung der sleep-Befehl direkt ich bin die Speicherung der sleep-Befehl in eine Datei und ausführen der Datei.

Nun tötete ich meine Sitzung, indem Sie auf das " x " in das putty-Fenster
Öffnen Sie nun eine weitere Sitzung und versucht, die lookup-Prozess..der Prozess ist noch da

Nicht sicher, warum dies geschieht. Ich dachte, ich tun müssen, verleugnen in der bash ausführen des Prozesses auch nach der Abmeldung.

Einem diff sehe ich in der parent-Prozess-id. Im zweiten Fall..die parent-Prozess-id für den Schlaf-2000 wird 1. Sieht aus wie so bald als Prozess für mysleep.sh starb der kernel zugewiesen, der Elternprozess 1.

InformationsquelleAutor | 2009-09-23

  1. 20

    Der Unterschied hier ist in der Tat die dazwischen liegenden Prozess.
    Wenn Sie schließen Sie das terminal-Fenster, ein HUP-signal (im Zusammenhang mit "nohup" als an0nymo0usc0ward erwähnt) wird an die Prozesse ausgeführt werden. Die Standardaktion bei Empfang HUP ist zu sterben - und aus dem signal(3) - Handbuchseite,

     No    Name         Default Action       Description
 1     SIGHUP       terminate process    terminal line hangup

    In deinem ersten Beispiel, die Schlaf-Prozess direkt empfängt dieses signal HUP und stirbt, weil es nicht festgelegt ist, irgendetwas anderes zu tun. (Einige Prozesse fangen HUP und es verwenden, um eine bestimmte Aktion ausführen, z.B. Lesen einige Konfigurationsdateien)

    Im zweiten Beispiel ist der shell-Prozess läuft dein shell-Skript ist bereits gestorben, so dass die Schlaf-Prozess wird nie das signal. In UNIX jeder Prozess muss einen parent-Prozess aufgrund von Interna, wie der wait(2) - Familie fordert Werke und in der Tat Prozesse im Allgemeinen. Also, wenn der Vaterprozess stirbt, den kernel gibt es auf init (pid 1, als Sie Hinweis) als Pflegekind.
    Orphan-Prozess (auf wikipedia) hat einige weitere Informationen zur Verfügung, siehe auch Zombie-Prozess für einige weitere technische details.

    InformationsquelleAutor Steven Schlansker

  2. 8

    Bereits Laufenden Prozess?

    ^z

    bg

    enteignen %<jobid>

    Neuen Prozess/Skript (auf der lokalen Maschine in der Konsole)?

    nohup script.sh &

    Neuen Prozess/Skript (auf der remote-Maschine in der Konsole)?

    Abhängig von Ihrem Bedarf

    es gibt zwei Möglichkeiten, [ es werden noch mehr 😉 ]

    ssh remotehost 'nohup /path/to/script.sh </dev/null > nohup.2>&1 &'

    ODER

    Verwendung 'screen'

    Diese gibt keine Antwort auf die OP ' s Frage.

    InformationsquelleAutor Jayan

  3. 3

    Versuchen "nohup cmd args..."

    InformationsquelleAutor an0nym0usc0ward

  4. 0

    Steven s Antwort ist richtig, aber ich möchte hervorheben der schwierige Teil hier wieder:

    => Mit einem bash-Skript, das gerade ausgeführt, schlafen in den hintergrund

    Der Effekt davon ist, dass das "script" wird fast sofort (da es erledigt alle seine Befehle). Allerdings hat Sie einen untergeordneten Prozess (Schlaf) während seiner Lebensdauer. Der Effekt davon ist, dass:

    • Das "script" können die Eltern nicht mehr, und schlafen ist verwaist, die zur Initialisierung (das zeigt sich schön in einem pstree)
    • Die bash-shell, wo Sie begann, das Skript hat keine zugrunde liegende Arbeitsplätze mehr

    Beachten Sie, dass diese Sachen alle passiert, wenn Sie ausgeführt, das Skript und hat nichts zu tun mit irgendwelchen ssh logout/putty schließen.

    Wenn Sie dann endlich in der Nähe Ihres putty Sitzung, bash erhält ein "SIGHUP", aber nicht die Weiterleitung an alle anderen Prozesse (da gibt es keine jobs, Links)
    In dem anderen Fall, bash hat noch einen job haben Links, die es dann an die SIGHUP an, wodurch es zu Ende ist (wie Sie bemerkte)

    Hoffe, das hilft

    InformationsquelleAutor Arnout

Schreibe einen Kommentar