cómo mantener un script de Python en ejecución cuando cierro masilla


19

Estoy a punto de ejecutar un script de Python en Ubuntu en VPS. Es un proceso de entrenamiento de aprendizaje automático, así que tómate un tiempo enorme para entrenar. ¿Cómo puedo cerrar la masilla sin detener ese proceso?


1
Echa un vistazo nohup.
phk

Respuestas:


36

Tienes dos opciones principales:

  1. Ejecute el comando con nohup. Esto lo desasociará de su sesión y permitirá que continúe ejecutándose después de desconectarlo:

    nohup pythonScript.py

    Tenga en cuenta que la stdout del comando se agregará a un archivo llamado a nohup.outmenos que lo redirija ( nohup pythonScript.py > outfile).

  2. Use un multiplexor de pantalla como tmux. Esto le permitirá desconectarse de la máquina remota, pero luego, la próxima vez que se conecte, si tmux attachvuelve a ejecutar , se encontrará exactamente en la misma sesión. El comando seguirá ejecutándose (continuará ejecutándose cuando cierre la sesión) y podrá ver su stdout y stderr como si nunca hubiera cerrado la sesión:

    tmux 
    pythonScript.py

    Una vez que hayas lanzado eso, solo cierra la ventana PuTTY. Luego, conéctese nuevamente al día siguiente, tmux attachvuelva a ejecutar y estará de regreso donde comenzó.


44
Alternativas a 1 y 2: 1. disown2.screen
heemayl

También vale la pena mencionar byobu, un contenedor alrededor de tmux o screen.
bli

2

La screenherramienta, disponible para todas las distribuciones de Linux, es compatible con esto.

Para instalarlo, ejecuta apt-get install screen para distribuciones Linux basadas en deb, dnf install -y screeno yum install -y screenpara distribuciones basadas en RPM.

Usar:

$ screen

Se inicia un nuevo shell. En este shell, puede iniciar su script Python. Entonces puedes presionar Ctrl+Shift + y Aluego D. Separará su terminal del shell que ejecuta su script. Además, el script todavía se está ejecutando en él.

Para ver cómo se ejecuta su script, puede llamar screen -r . Esto volverá a conectar su terminal al shell con el script Python que dejó ejecutándose en segundo plano.

UPD: como mencionó Fox, la pantalla funciona mal con systemd, pero podemos usar systemd para iniciar el script, como dicen en ejemplo oficial .

Por ejemplo, si su secuencia de comandos es iniciada por /usr/bin/myPythonScript, puede crear un archivo de unidad Systemd, de esta manera.

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

[Unit]
Description=MyPythonScript

[Service]
ExecStart=/usr/bin/myPythonScript

[Install]
WantedBy=multi-user.target

Entonces, puedes comenzar este script # systemctl daemon-reload # systemctl start myPythonScript

Si desea que este script se inicie automáticamente al iniciar el sistema:

# systemctl enable myPythonScript

En cualquier momento puede ver cómo se ejecuta su script

# systemctl status myPythonScript

Anuncio puede revisar los registros de su secuencia de comandos

# journalctl -u myPythonScript -e


Tenga en cuenta que screenno funciona exactamente bien systemden su configuración predeterminada. No sé si Ubuntu usa systemd, pero vale la pena mencionar el comportamiento y la solución en su respuesta
Fox

1

La mayoría de los procesos pueden ser engañados redirigiendo sus stdout, stderr, stdin (no todos los descriptores son siempre necesarios para redirigir) y usando & operador de control.

Mira eso ping example.com 1>/dev/null & hace el trabajo.

Por supuesto, algunos programas son más sofisticados y requieren soluciones como las mencionadas en @terdon, pero es bueno saber y usar lo que mejor se adapte.

EDITAR: como está escrito en esta respuesta, mata los systemdprocesos al cerrar sesión. Algunas versiones de systemdprocesos de cierre al cerrar sesión de forma predeterminada, otras no. Este comportamiento se puede cambiar modificando /etc/systemd/logind.conf configurando la siguiente opción. Tal como está escrito, también puede resolver algunos problemas que pueda tener con las soluciones de @terdon.

de man logind.conf:

KillUserProcesses=

Toma un argumento booleano. Configura si los procesos de un usuario deben eliminarse cuando el usuario cierra la sesión. Si es verdadero, la unidad de alcance correspondiente a la sesión y todos los procesos dentro de ese alcance finalizarán. Si es falso, el alcance está "abandonado", consulte systemd.scope (5), y los procesos no se eliminan. El valor predeterminado es "sí", pero vea las opciones KillOnlyUsers=yKillExcludeUsers= abajo.

Además de los procesos de sesión, el proceso de usuario puede ejecutarse bajo la unidad de administrador de usuarios user @ .service. Dependiendo de la configuración persistente, esto puede permitir a los usuarios ejecutar procesos independientes de sus sesiones de inicio de sesión. Ver la descripción de enable-lingeren loginctl(1).

Tenga en cuenta que la configuración KillUserProcesses=yesinterrumpirá herramientas como screen(1) y tmux(1), a menos que se salgan del alcance de la sesión. Ver ejemplo en systemd-run(1).

Lea la respuesta vinculada para obtener más información.


1
Esto simplemente envía el proceso a un segundo plano. El OP quiere poder desconectarse de una sesión ssh remota y que el proceso continúe. Esto no ayudará en esa situación, salir de la sesión remota detendrá el comando incluso si está en segundo plano.
terdon

@terdon ¿has comprobado si mi ejemplo funciona? Lo he comprobado y funciona para algunos comandos, como he escrito en mi respuesta.
espuma de poliestireno volar

Sí, lo he comprobado y sí, he visto que a veces el comando continúa. Sin embargo, a menudo he visto que el comando se detiene, a menos que pueda explicar exactamente qué comandos continúan o proporcionar una forma de saber de antemano si continuará o no, esto no es muy útil. De hecho, el ejemplo específico que diste falló en una prueba que acabo de ejecutar conectando desde mi Arch a un sistema Ubuntu remoto.
terdon

@terdon divertido, lo he comprobado en ArchLinux local que se conecta a PLD remoto. La única regla que funciona todo el tiempo es "¿el programa usa isatty()y sale si no es así?"
espuma de poliestireno volar

Eso podría merecer su propia pregunta. Sé que siempre necesitaba nohup, y luego, en algún momento, algo cambió y a veces no. Sin embargo, no puedo ver cómo podría ser el isatty, si sales del shell principal, eso también debería matar al niño. Pero sí, a veces no. Supongo que debe ser configurable de alguna manera.
terdon
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.