Start Remote-Skript via ssh enthält nohup

Question

ich ein Skript remote über ssh wie folgt starten wollen:

ssh user@remote.org -t 'cd my/dir && ./myscript data my@email.com' 

Das Skript verschiedene Dinge tut, die gut funktionieren, bis es zu einer Linie mit nohup kommt:

nohup time ./myprog $1 >my.log && mutt -a ${1%.*}/`basename $1` -a ${1%.*}/`basename ${1%.*}`.plt $2 < my.log 2>&1 & 

es soll das Programm myprog starten, pipe seine Ausgabe zu mylog und senden Sie eine E-Mail mit einigen Datendateien von Myprog als Anhang und das Protokoll als Körper erstellt. Obwohl das Skript diese Zeile erreicht, gibt ssh aus:

Verbindung zu remote.org geschlossen.

Was ist das Problem hier?

Vielen Dank für jede Hilfe

Answer 1

Ihr Befehl führt eine Pipeline von Prozessen im Hintergrund, so dass das aufrufende Skript sofort beenden (oder sehr kurz danach). Dies führt dazu, dass ssh die Verbindung schließt. Das wiederum wird dazu führen, dass ein SIGHUP an jeden Prozess gesendet wird, der an das Terminal angeschlossen ist, für den die -t-Option erstellt wurde.

Ihr time ./myprog Prozess ist durch eine nohup geschützt, so sollte es weiter laufen. Aber deine mutt ist nicht, und das ist wahrscheinlich das Problem hier. Ich schlage vor, Sie ändern Ihre Befehlszeile zu:

nohup sh -c "time ./myprog $1 >my.log && mutt -a ${1%.*}/`basename $1` -a ${1%.*}/`basename ${1%.*}`.plt $2 < my.log 2>&1 " & 

so wird die gesamte Pipeline geschützt. (Wenn das nicht behoben wird, kann es notwendig sein, etwas mit Dateideskriptoren zu tun - zum Beispiel hat mutt vielleicht andere Probleme mit dem Terminal - oder das Zitat muss abhängig von den Parametern angepasst werden - aber versuchen Sie das mal jetzt ...)

Answer 2

This answer kann hilfreich sein. Zusammenfassend die gewünschte Wirkung zu erzielen, müssen Sie folgende Dinge tun:

1. Redirect alle I/O auf der Fernbedienung nohup'ed Befehl
2. Ihrem lokalen SSH-Befehl per eMail so schnell zu verlassen, wie es gemacht wird Starten des Remote-Prozesses (der Remote-Prozesse).

Zitiert the answer I already mentioned, wiederum unter Angabe wikipedia:

Nohuping backgrounded Jobs ist zum Beispiel nützlich, wenn via SSH angemeldet, da backgrounded Jobs des Shell beim Abmelden aufgrund einer Race-Bedingung [hängen verursachen können 2].

nohup myprogram > foo.out 2> foo.err < /dev/null & 

UPDATE

Ich habe gerade mit diesem Muster Erfolg: Dieses Problem kann auch durch Umleiten alle drei I/O-Streams überwunden werden

ssh -f user@host 'sh -c "((nohup command-to-nohup 2>&1 >output.file </dev/null) &)"'