Re: Recuperar trabajo en background
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hola
On Friday 22 November 2002 03:00, Juan Marcos Delgado Alcantar (ac-bio) wrote:
> On Thu, 21 Nov 2002, =?iso-8859-1?B?Sm9zZW3hcnkgQSBN ?= wrote:
> > Si lo que quieres es que al cerrar el terminal el
> > proceso siga rulando en segundo plano deberías
> > ejecutarlo usando nohup:
> > $> nohup comando &
> > Así el proceso se independiza del terminal y no
> > es obligado a terminar aunque se cierre el terminal.
Esta conversación a mi ya me huele hasta a "deja vu", la afirmación en sí no
es cierta para linux de forma total, le suministras una salida y un error con
lo que si los necesita no se morirá al cerrar la terminal :
apropos nohup
nohup (1) - run a command immune to hangups, with output to a
non-tty
del man de nohup de solaris:
DESCRIPTION
The nohup utility invokes the named command with the argu-
ments supplied. When the command is invoked, nohup
arranges for the SIGHUP signal to be ignored by the process.
The nohup utility can be used when it is known that command
will take a long time to run and the user wants to logout of
the terminal; when a shell exits, the system sends its chil-
dren SIGHUP signals, which by default cause them to be
killed. All stopped, running, and background jobs will
ignore SIGHUP and continue running, if their invocation is
preceded by the nohup command or if the process programmat-
ically has chosen to ignore SIGHUP.
El nohup de los unices es un binario, mira por ejemplo el file en un irix:
file /usr/bin/nohup
/usr/bin/nohup: ELF N32 MSB mips-3 dynamic executable MIPS - version 1
ahora, pruébalo en tu debian, vaya!!!, es un shell script!!!, vaya, y corre el
programa con un simple nice -5 gestionando la redirección de la salida
standard y el error standard por tí.
> >
> > con
> > $> comando &
> > Si cierras el terminal se acaba el proceso lanzado
> > por comando.
>
> ¿Esto es válido en una terminal de consola?, porque yo he
> trabajado con comando & desde una xterm y el proceso continua.
>
del man de bash:
The shell exits by default upon receipt of a SIGHUP. Before exiting, an
interactive shell resends the SIGHUP to all jobs, running or stopped.
Stopped jobs are sent SIGCONT to ensure that they receive the SIGHUP.
To prevent the shell from sending the signal to a particular job, it should
be removed from the jobs tablewith the disown builtin (see SHELL
BUILTIN COMMANDS below) or marked to not receive SIGHUP using disown -h.
Como cuenta aquí otra vez el man de bash
disown [-ar] [-h] [jobspec ...]
Without options, each jobspec is removed from the table of
active jobs. If the -h option is given, each jobspec is not removed from
the table, but is marked so that SIGHUP is not sent to the job if the
shell receives a SIGHUP. If no jobspec is present, and neither the -a nor
the -r option is supplied, the current job is used. If no jobspec is
supplied, the -a option means to remove or mark all jobs; the -r option
without a jobspec argument restricts operation to running jobs. The return
value is 0 unless a jobspec does not specify a valid job.
Yo no tengo claro si la shell al cerrarse manda realmente ese SIGHUP a los
trabajos activos, pero si miras lo que hace nohup verás que no hace nada para
evitar que a los trabajos les pueda llegar un SIGHUP que les cierre, al menos
no he visto nunca ese comportamiento salvo que el trabajo requiera
estrictamente de una terminal, con lo que no se muere de un SIGHUP sino al
desaparecer la terminal que los sustentaba, si quieres seguridad total de que
el trabajo no se cerrara... :
[Peter] What you want is the 'disown' command, a bash builtin. It causes the
shell to detach a background job from the tty and basically forget it ever
existed.
This is really useful in loops. Often I want to start 100 jobs in the
background but don't care about stopping them later. So:
i=0; while [ $i -lt 100 ]; do some_long_job_involving_$i & disown; ((i=i+1));
done
Note that I use '&' to put each job in the background, then immediately disown
it. That way the job numbers don't accumulate and get in the way.
If you are forced to use a non-bash shell that doesn't support disown, you can
get the same effect by running the background job in a subshell:
sh -c 'some_long_job &'
The 'sh' you spawn to run the job exits immediately -- it's not an interactive
shell so it doesn't bother with th job control crap -- and your login shell
is none the wiser about some_long_job still going.
O si el trabajo necesita una terminal siempre puedes usar screen, por
ejemplo...
De todas formas yo personalmente sigo teniendo poco claro el comportamiento de
los trabajos en segundo plano en linux, menos aún después de ver que el man
de bash dice que por defecto se envia el SIGHUP al cerrar la shell, de hecho
la sh tampoco mata un proceso en background al salir del mismo, es más a la
vista de todo esto yo me inclinaría a pensar que la shell al salir no les
manda ninguna señal sino que simplemente se desentiende de ellos como lo
haríamos manualmente con un disown.
> Un saludo.
Un saludo
Victor
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE93gBKEzqHF8R72ekRAvNKAKCXWnZd6jnX/qwM8f1d71IHK1LbFQCePlqH
Sbpk9ezgwrIUvtrgJ+RbDzs=
=AHB/
-----END PGP SIGNATURE-----
Reply to: