Verifique el comando renegado

Publiqué la ^z; bg; disownsecuencia para permitirme cerrar una sesión ssh en la que estoy ejecutando un proceso super importante de larga duración. Este proceso escribe la salida de estado en stderr, y ha continuado haciéndolo incluso después de ser desconectado (verificado con lsof, el stderr fd está abierto para r / w).

¿Hay alguna manera de determinar que el proceso ha sido desautorizado (no recibirá SIGHUP si el shell recibe uno)?

bash process

— mikewaters
fuente

Me pregunto si esto debe ir a unix.stackexchange.com

— Rilindo

Por curiosidad, por qué no: $ PROCESS 1 >> / root / std.out 2 >> / root / err.out &

— Avery Payne

En Bash, el disowncomando emitido por sí mismo eliminará los procesos en segundo plano (a través de bgo &) de la tabla de trabajo activa y los marcará para no recibir un SIGHUP al cerrar sesión.

También puede pasar uno o más trabajos a rechazar, como disown 1 3. El disown -hindicador es útil si desea mantener los trabajos en la tabla, pero aún no SIGHUP al cerrar sesión.

Puede ver la tabla de trabajos emitiendo el jobscomando. Después de un fondo exitoso, se mostrará [1]+ command &. Después de rechazar un trabajo, ya no debería mostrarse en la tabla de trabajos, y ya no debería desaparecer al cerrar sesión. Todavía se puede ver el proceso a través ps ux, topy otros servicios de proceso de visualización.

Después de que un trabajo ha sido rechazado, puede esperar a que termine naturalmente o enviar una señal killal PID para detenerlo.

Debido a que Bash solo está eliminando el trabajo de la lista de trabajos en ejecución para finalizar y los identificadores de archivo para stdout y stderr de su terminal aún están abiertos, continuará recibiendo la salida del trabajo hasta que su dispositivo terminal se cierre (cuando cierre la sesión) .

Ejemplos:

# we start a command in the background
$ cat /dev/urandom > test &
[1] 18533

# we see our command is still running
$ jobs
[1]+  Running                 cat /dev/urandom > test &

# we disown the backgrounded job
$ disown 1

# notice it is no longer in the job table
$ jobs

Por lo general, solo lo uso disownsi ejecuto un comando potencialmente de ejecución prolongada como un rsyncoy cpluego decido que necesito cerrar sesión sin terminarlo. Si sabe que va a ejecutar un comando y cerrar la sesión, puede capturar la salida canalizándola teea un archivo, ejecutándola nohupo ejecutándola screen(lo que le permite retomar la propiedad del comando / finalizar después) )

Ejemplos:

# capture stdout and stderr to separate logs
cat /dev/urandom >stdout.log 2>stderr.log

# capture stdout and stderr to the same log, and display to stdout as well
cat /dev/urandom 2>&1 | tee output.log

# run a command under nohup (doesn't require a disown or job control support)
nohup cat /dev/urandom </dev/null

— lunixbochs
fuente

+1 Informativo y con ejemplos. ¡Agradable!

— Andy Smith

Comentario muy informativo; ¿Está diciendo que no es posible verificar la separación de un proceso (además de señalar que ya no existe en la tabla de trabajos)?

— mikewaters

cuando se ejecuta detachen un trabajo en segundo plano, se separará :) no hay realmente un término medio allí donde ejecutarlo en un proceso en segundo plano no hará nada. la verificación jobssolo verifica que no intentaste separar un proceso detenido o algo así.

— lunixbochs