jak utrzymać skrypt Pythona działający, kiedy zamykam kit

Zaraz uruchomię skrypt Pythona na Ubuntu na VPS. Jest to proces szkolenia w zakresie uczenia maszynowego, więc poświęć dużo czasu na szkolenie. Jak mogę zamknąć kit bez zatrzymywania tego procesu.

python putty

— Rosół
źródło

Sprawdź nohup.

— phk

Odpowiedzi:

Masz dwie główne opcje:

Uruchom polecenie za pomocą nohup. Spowoduje to odłączenie go od sesji i umożliwi kontynuowanie działania po rozłączeniu:
```
nohup pythonScript.py
```
Zauważ, że standardowe wyjście polecenia zostanie dołączone do pliku o nazwie, nohup.outchyba że go przekierujesz ( nohup pythonScript.py > outfile).
Użyj multipleksera ekranowego, takiego jak tmux. Umożliwi to rozłączenie się ze zdalną maszyną, ale następnie przy następnym połączeniu, jeśli uruchomisz tmux attachponownie, znajdziesz się w dokładnie tej samej sesji. Polecenie będzie nadal działać (będzie kontynuowane po wylogowaniu) i będziesz mógł zobaczyć jego stdout i stderr tak, jakbyś nigdy się nie wylogował:
```
tmux 
pythonScript.py
```
Po uruchomieniu zamknij okno PuTTY. Następnie połącz ponownie następnego dnia, uruchom tmux attachponownie i wróć do miejsca, w którym zacząłeś.

— terdon
źródło

Alternatywy dla 1 i 2: 1. disown2.screen

— heemayl

Warto również wspomnieć byobuo owijarce wokół Tmuxa lub ekranu.

— bli

screenNarzędzie, dostępne dla wszystkich dystrybucjach Linuksa, to dopuszcza.

Aby go zainstalować, uruchom apt-get install screendla dystrybucji Linuksa opartych na debie dnf install -y screenlub yum install -y screendla dystrybucji opartych na RPM.

Używać:

$ screen

Uruchomiono nową powłokę. W tej powłoce możesz uruchomić skrypt w języku Python. Następnie można nacisnąć Ctrl+ Shift+ Apotem D. Odłączy twój terminal od powłoki, która uruchamia twój skrypt. Ponadto skrypt nadal działa w nim.

Aby zobaczyć, jak działa skrypt, możesz zadzwonić screen -r. Spowoduje to ponowne podłączenie terminala do powłoki za pomocą skryptu Python, który pozostawiłeś uruchomiony w tle.

UPD: jak wspomniał Fox, screen działa źle z systemd, ale możemy użyć systemd do uruchomienia skryptu, jak mówią w oficjalnym przykładzie .

Na przykład, jeśli skrypt jest uruchamiany przez /usr/bin/myPythonScript, możesz utworzyć plik jednostki Systemd, taki jak ten.

$ cat /etc/systemd/system/myPythonScript.service

[Unit]
Description=MyPythonScript

[Service]
ExecStart=/usr/bin/myPythonScript

[Install]
WantedBy=multi-user.target

Następnie możesz uruchomić ten skrypt # systemctl daemon-reload # systemctl start myPythonScript

Jeśli chcesz, aby ten skrypt był uruchamiany automatycznie podczas uruchamiania systemu -

# systemctl enable myPythonScript

W dowolnym momencie możesz zobaczyć, jak działa twój skrypt

# systemctl status myPythonScript

Reklama umożliwia przeglądanie dzienników skryptu

# journalctl -u myPythonScript -e

— vodolaz095
źródło

Pamiętaj, że screennie jest ładnie gra systemdw domyślnej konfiguracji. Nie wiem, czy Ubuntu używa systemd, ale warto wspomnieć o jego zachowaniu i obejściu

— Fox

Większość procesów można oszukać, przekierowując jego stdout, stderr, stdin (nie wszystkie deskryptory są zawsze konieczne do przekierowania) i używając &operatora control.

Zobacz, ping example.com 1>/dev/null &czy to działa.

Oczywiście niektóre programy są bardziej wyrafinowane i wymagają takich rozwiązań, jak wspomniany @terdon, ale dobrze jest wiedzieć i używać tego, co najlepiej pasuje.

EDYCJA: jak napisano w tej odpowiedzi, zabija systemdprocesy podczas wylogowywania. Niektóre wersje systemdprocesów zabicia domyślnie podczas wylogowywania, inne nie. To zachowanie można zmienić, modyfikując /etc/systemd/logind.conf, ustawiając następującą opcję. Jak napisano, może również rozwiązać niektóre problemy, które możesz mieć z rozwiązaniami @ terdon.

z man logind.conf:

KillUserProcesses=

Przyjmuje argument boolowski. Konfiguruje, czy procesy użytkownika powinny zostać zabite po wylogowaniu. Jeśli to prawda, jednostka zakresu odpowiadająca sesji i wszystkie procesy w tym zakresie zostaną zakończone. Jeśli false, zakres jest „porzucany”, patrz systemd.scope (5), a procesy nie są zabijane. Domyślnie „tak”, ale zobacz opcje KillOnlyUsers=i KillExcludeUsers=poniżej.

Oprócz procesów sesji proces użytkownika może być uruchamiany pod jednostką menedżera użytkowników użytkownik @. Usługa. W zależności od ustawień przeciągania może to umożliwić użytkownikom uruchamianie procesów niezależnie od sesji logowania. Zobacz opis enable-lingerw loginctl(1).

Zauważ, że ustawienie KillUserProcesses=yesspowoduje uszkodzenie narzędzi takich jak screen(1) i tmux(1), chyba że zostaną one przeniesione poza zakres sesji. Zobacz przykład w systemd-run(1).

Przeczytaj połączoną odpowiedź, aby dowiedzieć się więcej.

— mucha styropianowa
źródło

To po prostu wysyła proces do tła. OP chce mieć możliwość odłączenia się od zdalnej sesji ssh i kontynuowania procesu. To nie pomoże w tej sytuacji, wyjście ze zdalnej sesji zatrzyma polecenie, nawet jeśli jest ono w tle.

— terdon

@terdon sprawdziłeś, czy mój przykład działa? Sprawdziłem i działa w przypadku niektórych poleceń, jak napisałem w odpowiedzi.

— mucha styropianowa

Tak, sprawdziłem i tak, widziałem, że czasami polecenie jest kontynuowane. Jednak bardzo często widziałem, że polecenie zatrzymuje się, więc jeśli nie możesz dokładnie wyjaśnić, które polecenia są kontynuowane lub zapewnić sposób wcześniejszego wiedzieć, czy będzie kontynuowane, czy nie, nie jest to bardzo przydatne. W rzeczywistości konkretny przykład, który podałeś, nie powiódł się w teście, który właśnie uruchomiłem, łącząc moje Arch z odległym systemem Ubuntu.

— terdon

@terdon śmieszne, sprawdziłem to na lokalnym ArchLinux łączącym się ze zdalnym PLD. Jedyną regułą, która działa przez cały czas, jest „czy program używa isatty()i wychodzi, jeśli nie jest?”

— mucha styropianowa

To zasługuje na własne pytanie. Wiem, że zawsze potrzebowałem nohup, a potem w pewnym momencie coś się zmieniło, a czasami nie. Nie widzę jednak, jak może to być isatty, jeśli wyjdziesz z powłoki nadrzędnej, to powinno zabić dziecko. Ale tak, czasami tak nie jest. Domyślam się, że to musi być jakoś konfigurowalne.

— terdon