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

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

Systemd?

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.

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.

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.