python script auf raspberry pi über putty starten und dann putty beenden

[Marcel (Gast)]

Hey,
auf einem Raspberry pi starte ich über putty ein python script.

Wie kann ich putty jetzt aber verlassen, sodass das python script noch 
weiter läuft?
Bisher schließe ich putty mit Alt+F4. Damit hört aber auch das Script 
auf.

[Thomas W. (Gast)]

Moin, -

z.B. so:

pi@raspberry:~ $ ps ax &

also einfach ein & anhaengen.

Gruesse

Th.

[S.P. (Gast)]

https://linuxize.com/post/how-to-use-linux-screen

[Tom (Gast)]

Oder nohup.

[Marcel (Gast)]

Thomas W. schrieb:
> also einfach ein & anhaengen.

mhh,
in htop sehe ich zwar, dass es noch am laufen ist, wenn ich es mit 
strg+c abbreche, wenn ich aber putty beende, wird hier auch wieder das 
script beendet. Beim nächsten aufstart sehe ich das programm auch nicht 
mehr in htop.

[Marcel (Gast)]

Tom schrieb:
> Oder nohup.

das läuft

[Dirk B. (dirkb2)]

& läßt das Programm nur im Hintergrund laufen.
nohup steht für NO Hang UP

[Thomas W. (Gast)]

Moin, -

da hast Du recht. Da hast Du so recht.

Th.

[Voodii (Gast)]

Oder Tmux  nutzen.

[quotendepp (Gast)]

Voodii schrieb:
> Oder Tmux  nutzen.

tmux forever! ;-)

[100Ω W. (tr0ll)]

Systemd?

[Sheeva P. (sheevaplug)]

Voodii schrieb:
> Oder Tmux  nutzen.

Ja, oder screen(1). Aber der Weisheit letzter Schluß ist das auch nicht, 
denn die haben ja alle einen Ausgabepuffer für STDOUT und STDERR und 
laufen deswegen nur so lange, bis der Ausgabepuffer den gesamten freien 
Arbeitsspeicher befüllt hat und der nächste Aufruf von malloc(3) unserem 
hochgeschätzten Kollegen OOM-Killer über den Weg läuft, der den Prozeß 
dann erschießt. Huch!

Besser: ein systemd-Unitfile schreiben, den kleinen Scheißer per 
cron(8), at(1) oder einem ordentlichen Prozeßmanager wie supervisord, 
monit, daemontools oder Kollegen laufen lassen. Der Königsweg auf 
modernen Linuxsystemen ist systemd.

[Bastler (Gast)]

screen tmux nohup oder & Möglichkeiten gibt es viele.

ich nehme gerne at

echo /pfad_zum_skript/skript |at now

at muss dafür installiert sein.

[Klaus H. (klummel69)]

Sheeva P. schrieb:
> Voodii schrieb:
>> Oder Tmux  nutzen.
> Ja, oder screen(1). Aber der Weisheit letzter Schluß ist das auch nicht,
> denn die haben ja alle einen Ausgabepuffer für STDOUT und STDERR und
> laufen deswegen nur so lange, bis der Ausgabepuffer den gesamten freien
> Arbeitsspeicher befüllt hat und der nächste Aufruf von malloc(3) unserem
> hochgeschätzten Kollegen OOM-Killer über den Weg läuft, der den Prozeß
> dann erschießt. Huch!

Sicher? Ich habe ein RaspberryPi am Laufen der seid ca 3 Jahren am Stück 
läuft. Dabei sind 3 Prozesse über tmux gestartet und pusten munter 
Ausgaben auf StdIO.

Bisher hatte ich eher das Problem, dass ein Skript wegen 
unvorhergesehener Ereignisse gestoppt hat. Aber auch das sieht man 
wunderbar beim nächsten attach auf tmux.

tmux hat ein Setting für die Anzahl Zeilen im Scrollback Buffer. 
(maxhistory-limit). Er stürzt IMHO nicht ab sondern verwirft ältere 
Zeilen.

[Rolf M. (rmagnus)]

Sheeva P. schrieb:
> Voodii schrieb:
>> Oder Tmux  nutzen.
>
> Ja, oder screen(1). Aber der Weisheit letzter Schluß ist das auch nicht,
> denn die haben ja alle einen Ausgabepuffer für STDOUT und STDERR und
> laufen deswegen nur so lange, bis der Ausgabepuffer den gesamten freien
> Arbeitsspeicher befüllt hat und der nächste Aufruf von malloc(3) unserem
> hochgeschätzten Kollegen OOM-Killer über den Weg läuft, der den Prozeß
> dann erschießt. Huch!

Die puffern alles was ausgegeben wird und behalten es für immer? Kann 
ich mir nicht so recht vorstellen. Das wäre ja ziemlich dämlich.

[seere (Gast)]

screen und tmux haben eine einstellbare Größe des History/Scollback 
Buffers. Die steht IIRC per default bei irgendwas um die 100 (screen) 
und 2000 (tmux) Zeilen jeweils pro Pane.