|
Anzeige
|
Linux: Updateprozess im Hintergrund laufen lassen
Gast
#5048467
Hallo, ich verbinde mich mit Putty per SSH mit einem anderem PC (Linux). Wenn ich dort ein update starte und Putty mitten drin schließe, wird auch das Updateten abgeschossen. Gibt es eine Möglichkeit das Update zu starten und dann ohne Putty weiter laufen zu lassen? nohup apt-get dist-upgrade &
Gast
#5048480
Das Programm screen ist dein Freund... tmux forever ;-) Falls deine Linux distribution Systemd verwendet, und screen und tmux beim logout auch beendet werden sollten ist es möglich, dass die Distribution Systemd's kaputtes Verhalten beim ausloggen nicht repariert hat. Mehr dazu hier: https://unix.stackexchange.com/questions/171503/tmux-session-killed-when-disconnecting-from-ssh Da ich Systemd nicht verwende, und deine Linux distribution nicht kenne, kann ich jedoch nicht ob das Problem immernoch besteht oder ob es dich mit deiner Distribution überhaubt betrifft.
Gast
#5049223
Daniel A. schrieb: > Systemd's kaputtes Verhalten Blah. Einfach dieses Verhalten abschalten, wenn man es nicht möchte.
Gast
#5049227
Daniel F. schrieb: > tmux forever ;-) so schauts aus!
Gast
#5049231
Daniel A. schrieb: > Systemd's kaputtes Verhalten eigentlich macht es Systemd richtig, das Prozesse nach dem ausloggen noch laufen will man nicht haben. Zum Starten von Background Prozessen gibt es andere Lösungen. tmux regelt. Man mag systemd lieben oder hassen, der trägt aber keine Schuld daran, dass Prozesse wegfliegen, wenn ihr Terminal abschaltet. SIGHUP und die entsprechende Reaktion existiert seit der Anfangszeit von UNIX. Eben deshalb gibts schon genau so lange das "nohup" Kommando. Ansonsten kann man den Prozess auch folgendermaßen nachträglich in den Hintergrund legen: Strg-Z drücken Befehl "bg" eingeben.
Gast
#5049274
A. K. schrieb: > Man mag systemd lieben oder hassen, der trägt aber keine Schuld daran, > dass Prozesse wegfliegen, wenn ihre Konsole abschaltet. SIGHUP und die > entsprechende Reaktion existiert seit der Anfangszeit von UNIX. systemd geht aber noch einen schritt weiter, und killt hart alles Prozesse des users wenn sie sie SIGHUP nicht reagieren. (zumindest im Default) Md M. schrieb: > Ansonsten kann man den Prozess auch folgendermaßen nachträglich in den > Hintergrund legen: Aber die fliegen trotzdem weg, wenn das Terminal Schluss macht, weil immer noch damit verbunden. "nohup" trennt den Prozess vom Terminal ab und erst dadurch läuft der Prozess auch ohne Terminal weiter. Nachträglich geht das über die Job Control der Shell, mit "disown". A. K. schrieb: > Md M. schrieb: >> Ansonsten kann man den Prozess auch folgendermaßen nachträglich in den >> Hintergrund legen: > > Aber die fliegen trotzdem weg, wenn das Terminal Schluss macht, weil > immer noch damit verbunden. Hatte ich eigentlich auch vermutet, deshalb hab ich es vorm posten auch ausprobiert. Die Prozesse (hab ping und wget probiert) liefen noch nach dem wiedereinloggen.
Gast
#5049312
A. K. schrieb: > Aber die fliegen trotzdem weg, wenn das Terminal Schluss macht, weil > immer noch damit verbunden. "nohup" trennt den Prozess vom Terminal ab > und erst dadurch läuft der Prozess auch ohne Terminal weiter. auch nicht zwingend bei Systemd - er räumt ordentlich auf. Md M. schrieb: > Hatte ich eigentlich auch vermutet, deshalb hab ich es vorm posten auch > ausprobiert. Die Prozesse (hab ping und wget probiert) liefen noch nach > dem wiedereinloggen. Dazu existiert eine Bash-Einstellung. Je nach Einstellung laufen Prozesse bei regulärer Beendigung der Shell weiter. Peter II schrieb: > auch nicht zwingend bei Systemd - er räumt ordentlich auf. Grad in ziemlich aktuellem CentOS 7 ausprobiert. Programm gestartet, mit ^Z suspendiert, mit "bg" aktiviert und mit "disown" abgehängt. Dann Shell beendet: läuft weiter.
Gast
#5049325
A. K. schrieb: > Grad in ziemlich aktuellem CentOS 7 ausprobiert. Programm gestartet, mit > ^Z suspendiert, mit "bg" aktiviert und mit disown" abgehängt Dann Shell > beendet: läuft weiter. kommt ja darauf an wie systemd konfiguriert ist. https://linux.slashdot.org/story/16/05/29/212204/systemd-starts-killing-your-background-processes-by-default
Gast
#5049328
A. K. schrieb: > Grad in ziemlich aktuellem CentOS 7 ausprobiert. Programm gestartet, mit > ^Z suspendiert, mit "bg" aktiviert und mit "disown" abgehängt. Dann > Shell beendet: läuft weiter. nachtrag: https://www.freedesktop.org/software/systemd/man/logind.conf.html KillUserProcesses= /etc/systemd/logind.conf: #KillUserProcesses=no Die Default-Einstellung ist also offenbar richtig herum, d.h. entspricht dem klassischen Verhalten.
Gast
#5049333
A. K. schrieb: > Die Default-Einstellung ist also offenbar richtig herum Default ist aber YES Defaults to "yes",
Gast
#5049335
steht ja sogar in der doku Note that setting KillUserProcesses=yes will break tools like screen(1) and tmux(1), unless they are moved out of the session scope. See example in systemd-run(1).
Beitrag #5049338 wurde von einem Moderator gelöscht.
Gast
#5049343
A. K. schrieb im Beitrag #5049338: > Und jetzt? Wenn Praxis != Theorie, was stimmt dann? ;-) dürfte auch abhängig vom KillMode sein, damit kann man das alte verhalten wieder herstellen. > Was normaler User, nicht "root" für den es KillExcludeUsers gibt. was meinst du damit?
Peter II schrieb: > was meinst du damit?
Gast
#5049349
A. K. schrieb: > Peter II schrieb: >> was meinst du damit? > KillOnlyUsers=, KillExcludeUsers= das hatte ich noch nicht gelesen, das es für root anders ist. Peter II schrieb: > dürfte auch abhängig vom KillMode sein, damit kann man das alte > verhalten wieder herstellen. Wo wird das konfiguriert? Ich fand dazu zwar Doku, die auch erwähnt wozu es gut ist, nicht aber, wo das stehen würde. Jedenfalls gilt (hier) für KillUserProcesses `Defaults to "no"´, also alles in Butter.
Gast
#5049362
A. K. schrieb: > Wo wird das konfiguriert? da bin ich jetzt auch überfragt. (hatte noch nie eine Grund das zu ändern). Laut doku bei jedem Service, welcher Service aber für session-logout zuständig ist kann ich nicht sagen. Debian 9 "man": Defaults to "yes". Ubuntu 16.04: Defaults to "no". Redhat/CentOS 7: Defaults to "no". So macht man sich Freunde. ;-) Das reale Verhalten von Debian 9: Mit #KillUserProcesses=no (Default) wird der Prozess nicht abgeschossen. Das passiert nur mit explizitem KillUserProcesses=yes. Also alles halb so wild. Mir scheint, das war mal anders, hatte etwas Wirbel verursacht und sie sind wieder retour. Haben aber vergessen, die Doku mitzuziehen. PS: Habe kein Debian gefunden, in dem es anders gewesen wäre. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
