Solución 1:
Si está usando Bash, puede ejecutar disown -h job
repudiar
disown [-ar] [-h] [jobspec ...]
Sin opciones, cada especificación de trabajo se elimina de la tabla de trabajos activos. Si -h
Si se da la opción, el trabajo no se elimina de la tabla, pero se marca para que SIGHUP no se envíe al trabajo si el shell recibe un SIGHUP. Si jobspec no está presente, y tampoco el -a
ni -r
se proporciona la opción, se utiliza el trabajo actual. Si no se proporciona ninguna especificación de trabajo, el -a
opción significa eliminar o marcar todos los trabajos; el -r
La opción sin un argumento de especificación de trabajo restringe la operación a trabajos en ejecución.
Solución 2:
Usar reptyr
Del LÉAME:
reptyr - A tool for "re-ptying" programs.
-----------------------------------------
reptyr is a utility for taking an existing running program and
attaching it to a new terminal. Started a long-running process over
ssh, but have to leave and don't want to interrupt it? Just start a
screen, use reptyr to grab it, and then kill the ssh session and head
on home.
USAGE
-----
reptyr PID
"reptyr PID" will grab the process with id PID and attach it to your
current terminal.
After attaching, the process will take input from and write output to
the new terminal, including ^C and ^Z. (Unfortunately, if you
background it, you will still have to run "bg" or "fg" in the old
terminal. This is likely impossible to fix in a reasonable way without
patching your shell.)
Algunas entradas de blog de su autor:
- reptyr:adjuntar un proceso en ejecución a una nueva terminal
- reptyr:cambiar el terminal de control de un proceso
Solución 3:
Para robar un proceso de un tty a su tty actual, puede probar este truco:
http://www.ucc.asn.au/~dagobah/things/grab.c
Necesita reformatearse para poder compilar a las versiones actuales de Linux/glibc, pero aún funciona.
Solución 4:
Cuando se inicia un proceso, STDIN, STDOUT y STDERR están conectados a algo . En general, no puede cambiar eso una vez que se inicia el comando. En el caso que está describiendo, probablemente sea un tty asociado con la sesión ssh. nohup prácticamente solo hace...
command < /dev/null > nohup.out 2>&1
Es decir, establece STDIN en /dev/null, STDOUT en un archivo y STDERR en STDOUT. Screen hace cosas mucho más sofisticadas que implican configurar ttys que se dirigen a sí mismo.
No conozco ninguna forma de nohup retroactivamente o filtrar un proceso en ejecución. Si hace cd a /proc/$pid/fd y ve a qué apuntan 0, 1 y 2.
Es posible que tenga algo de suerte con el repudio, pero no si el proceso intenta hacer algo con STDIN, STDOUT o STDERR.
Solución 5:
Solo puedo darte un simple "No" sin el por qué de la parte de la pantalla, yo mismo estaría interesado en el motivo.
Sin embargo, ¿has probado disown
? (un bash integrado)
~ $ echo $SHELL
/bin/bash
~ $ type disown
disown is a shell builtin
~ $ help disown
disown: disown [-h] [-ar] [jobspec ...]
By default, removes each JOBSPEC argument from the table of active jobs.
If the -h option is given, the job is not removed from the table, but is
marked so that SIGHUP is not sent to the job if the shell receives a
SIGHUP. The -a option, when JOBSPEC is not supplied, means to remove all
jobs from the job table; the -r option means to remove only running jobs.