Nachträgliche Fernwartung mit tcsh

7335
wfaulk

Ich habe eine Tcsh-Instanz in einem Xterm, die einen Langzeitprozess (Wochen?) Ausführt. Der Xvnc-Server, unter dem er läuft, ging im Unkraut aus. Es verbraucht 100% CPU und reagiert nicht. (Dies ist ein bekannter Fehler und ich weiß, dass es nicht wiederherstellbar ist.)

Der langfristige Prozess blockiert derzeit für stdout.

Gibt es eine Möglichkeit, einen zugrunde liegenden Prozess - den tcsh, den xterm oder was auch immer - zu beenden und diesen langfristigen Prozess aufrechtzuerhalten?

(Bitte keine Antworten screen. Ich weiß. Es ist nicht mein Prozess; es ist ein Benutzer. Sie lernen es nicht.)

10

2 Antworten auf die Frage

16
quack quixote

Dieser Beitrag kann helfen. Die Empfehlung lautet:

  1. Hintergrund der Prozess (mit Strg-Z, dann bg )
  2. run disown -h% [jobid] (wahrscheinlich ein bash-ism, also musst du für tcsh übersetzen)

Die schlechte Nachricht ist natürlich, dass das bg in der gleichen Shell ausgeführt werden muss, in der der Prozess ausgeführt wird ... aber es könnte bereits ein Hintergrund sein.

Die wirklich schlechte Nachricht ist, dass der Disown- Aufruf möglicherweise in derselben Shell ausgeführt werden muss. In diesem Fall sind Sie ja vermasselt. Aber ich bin mir nicht sicher, vielleicht kann root es zwingen, es zu trennen.

Hmm. Mögliche gute Nachricht - Tcsh das tut disown automatisch:

Wenn tcsh nicht normal beendet wird, werden Aufträge, die im Hintergrund ausgeführt werden, beim Beenden automatisch deaktiviert.

Wenn Ihr langfristiger Prozess also bereits im Hintergrund ist, sollte das Töten seines tcsh-übergeordneten Elements möglicherweise fortgesetzt werden. Der Prozess ist jetzt vom Startterminal getrennt. (Wenn nicht, siehe oben "schlechte Nachrichten".)

Leider ist dies kein Bildschirm, daher gibt es keine echte Neuverbindung. Sie können es vielleicht mit gdb fälschen (wieder ab dem ersten Link):

[...] Mit einigen schmutzigen Hacks ist es nicht unmöglich, einen Prozess 'stdout / stderr / stdin' wieder zu öffnen.

Sie können also immer noch ein leeres Bildschirmfenster erstellen (zum Beispiel, das den Ruhezustand ausführt).

Und dann verwenden Sie gdb zum Beispiel zum Anhängen an den Prozess. Führen Sie einen Anruf aus. Close (0)
call close (1)
call close (2)
call open ("/ dev / pts / xx", ...)
call dup (0)
call dup (0)
trennen ab

Die Ausgabe des Prozesses würde auf dem Bildschirm erscheinen. Es würde nicht an dieses Bildschirm-Terminal angeschlossen werden, so würde [sic] zum Beispiel den Befehl "sleep" beenden, nicht den Prozess, aber das könnte für das OP ausreichen.

Ich frage mich, ob es nicht auch "call dup (1)" und "call dup (2)" in diesem Prozess geben sollte ...

Ja, es ist ein Prozess im Vordergrund, also bin ich vermasselt. wfaulk vor 15 Jahren 0
Ja. Aber wie du gesagt hast, es ist nicht dein Prozess, nicht deine Schuld. Entschuldigung, du bleibst in der Sauerei stecken. quack quixote vor 15 Jahren 0
Das hat mir gerade den Arsch gerettet. Ich stieß auf das gleiche Problem, über das ich anfangs berichtet hatte, nämlich, dass der Prozess auf STDOUT blockiert wurde, als der X-Server (und, denke ich, der X-Term dazwischen) klemmte. Es stellte sich heraus, dass ich nicht wirklich etwas anderes tun musste, außer STDOUT zu schließen. Diese Ausgabe war irrelevant; Die tatsächlichen Daten befinden sich irgendwo in einer Protokolldatei. Ich konnte also mit gdb verbinden, "call close (1)" und dann "cont" ausführen und schon geht es weiter. Vielen Dank! wfaulk vor 15 Jahren 2
huh! interessant. das alles auftauen? Verrücktheit Ich bin froh, dass es geholfen hat. quack quixote vor 15 Jahren 0
Nein, es sollte dup (0) sein. Die dup (0) -Aufrufe nehmen fd 0 und kopieren sie über die nächsten freien Deskriptoren, die zufällig 1 und 2 sind, wenn Sie sie zuvor geschlossen haben. dup2 (fd1, fd2) könnte eine klarere Schreibweise sein, vorausgesetzt, Sie können sich daran erinnern, welche Quelle und welches Ziel das Ziel ist (ich kann mich nie daran erinnern). Marius Gedminas vor 14 Jahren 0
Es lohnt sich, darauf hinzuweisen, dass das Senden von "Ctrl-Z" an einen Vordergrundprozess und das Senden von SIGSTOP an die PID dasselbe sind. (SIGCONT startet den Vorgang erneut.) Ich weiß nicht, ob dies für andere in derselben Situation hilfreich wäre oder nicht, aber in meinem schnellen Test versende ich SIGSTOP gefolgt von SIGCONT-Duplikaten "Ctrl-Z" gefolgt von `bg `. wfaulk vor 10 Jahren 2
Sie können vielleicht über reptyr erneut verbinden. Siehe: http://serverfault.com/questions/466129/restore-ssh-session/466183#466183 Olivier Dulac vor 8 Jahren 0
3
Dennis Williamson

Diese Fragen beziehen sich auf ein Programm namens Cryopid, das Ihnen helfen kann. Ich habe jedoch keine Erfahrung damit.

Einen Prozess zwischen Hosts verschieben

Xterms zwischen X-Sitzungen verschieben

Nohup und Screen einen Prozess

CryoPID klingt wirklich ordentlich, aber ich hatte eine Familie von Prozessen und unterstützt nicht das Einfrieren und Wiederaufnehmen mehrerer Prozesse, zumindest noch nicht. wfaulk vor 15 Jahren 0

Verwandte Probleme