unix - ¿Cómo uso el comando nohup sin obtener nohup.out?
jobs (8)
Tengo un problema con el comando nohup.
Cuando ejecuto mi trabajo, tengo muchos datos. La salida nohup.out se vuelve demasiado grande y mi proceso se ralentiza. ¿Cómo puedo ejecutar este comando sin obtener nohup.out?
¿Has intentado redireccionar las tres secuencias de E / S:
nohup ./yourprogram > foo.out 2> foo.err < /dev/null &
Es posible que desee utilizar el programa de separación . Lo usas como nohup pero no produce un registro de salida a menos que se lo digas. Aquí está la página del manual:
NAME
detach - run a command after detaching from the terminal
SYNOPSIS
detach [options] [--] command [args]
Forks a new process, detaches is from the terminal, and executes com‐
mand with the specified arguments.
OPTIONS
detach recognizes a couple of options, which are discussed below. The
special option -- is used to signal that the rest of the arguments are
the command and args to be passed to it.
-e file
Connect file to the standard error of the command.
-f Run in the foreground (do not fork).
-i file
Connect file to the standard input of the command.
-o file
Connect file to the standard output of the command.
-p file
Write the pid of the detached process to file.
EXAMPLE
detach xterm
Start an xterm that will not be closed when the current shell exits.
AUTHOR
detach was written by Robbert Haarman. See http://inglorion.net/ for
contact information.
Tenga en cuenta que no tengo ninguna afiliación con el autor del programa. Solo soy un usuario satisfecho del programa.
Si tiene un shell BASH en su mac / linux delante de usted, pruebe los siguientes pasos para comprender prácticamente la redirección:
Crear un script de 2 líneas llamado zz.sh
#!/bin/bash
echo "Hello. This is a proper command"
junk_errorcommand
- La salida del comando echo pasa al flujo de archivos STDOUT (descriptor de archivo 1).
- La salida del comando de error entra en STDERR filestream (descriptor de archivo 2)
Actualmente, simplemente ejecutando la secuencia de comandos envía STDOUT y STDERR a la pantalla.
./zz.sh
Ahora comienza con la redirección estándar:
zz.sh > zfile.txt
En lo anterior, "echo" (STDOUT) entra en zfile.txt. Mientras que "error" (STDERR) se muestra en la pantalla.
Lo anterior es lo mismo que:
zz.sh 1> zfile.txt
Ahora puede intentar lo contrario, y redirigir el "error" STDERR al archivo. El comando STDOUT from "echo" va a la pantalla.
zz.sh 2> zfile.txt
Combinando los dos anteriores, obtienes:
zz.sh 1> zfile.txt 2>&1
Explicación:
- PRIMERO, envíe STDOUT 1 a zfile.txt
- ENTONCES, envíe STDERR 2 a STDOUT 1 (usando & 1 puntero).
- Por lo tanto, tanto 1 como 2 entran en el mismo archivo (zfile.txt)
Finalmente, puede empaquetar todo dentro del comando nohup y ejecutarlo en segundo plano:
nohup zz.sh 1> zfile.txt 2>&1&
puede hacerlo debajo de nohup &> 2> & 1 & eg No tengo un comando hup dentro del script ./Runjob.sh> sparkConcuurent.out 2> & 1
nohup solo escribe en nohup.out si la salida es diferente al terminal. Si redirecciona la salida del comando a otro lugar, incluido /dev/null , es a donde va.
nohup command >/dev/null 2>&1 # doesn''t create nohup.out
Si está utilizando nohup , eso probablemente significa que desea ejecutar el comando en segundo plano poniendo otro & al final de todo:
nohup command >/dev/null 2>&1 & # runs in background, still doesn''t create nohup.out
En Linux, la ejecución de un trabajo con nohup cierra automáticamente su entrada. En otros sistemas, especialmente BSD y macOS, ese no es el caso, por lo que cuando se ejecuta en segundo plano, es posible que desee cerrar la entrada manualmente. Mientras que cerrar la entrada no tiene efecto en la creación o no de nohup.out , evita otro problema: si un proceso en segundo plano intenta leer algo de la entrada estándar, se detendrá, esperando a que vuelva al primer plano y escriba algo . Así que la versión más segura se ve así:
nohup command </dev/null >/dev/null 2>&1 & # completely detached from terminal
Sin embargo, tenga en cuenta que esto no impide que el comando acceda directamente al terminal, ni lo elimina del grupo de procesos de su shell. Si desea hacer lo último, y está ejecutando bash, ksh o zsh, puede hacerlo ejecutando disown sin argumentos como el siguiente comando. Eso significará que el proceso en segundo plano ya no está asociado con un "trabajo" de shell y no se le enviará ninguna señal desde el shell. (Tenga en cuenta la distinción: un proceso anulado no recibe señales que se le envíen automáticamente por su shell principal, pero sin nohup , seguirá saliendo al recibir una señal HUP enviada a través de otros medios, como un comando de kill manual. el proceso ignora todas y cada una de las señales HUP , sin importar cómo se envíen.)
Explicación:
En los sistemas Unixy, cada fuente de entrada o destino de salida tiene un número asociado llamado "descriptor de archivo", o "fd" para abreviar. Cada programa en ejecución ("proceso") tiene su propio conjunto de estos, y cuando se inicia un nuevo proceso ya tiene tres de ellos abiertos: "entrada estándar", que es fd 0, está abierto para que el proceso lea, mientras que La "salida estándar" (fd 1) y el "error estándar" (fd 2) están abiertos para que escriba. Si acaba de ejecutar un comando en una ventana de terminal, entonces, de forma predeterminada, todo lo que escriba irá a su entrada estándar, mientras que su salida estándar y su error estándar se enviarán a esa ventana.
Pero puede pedirle al shell que cambie dónde apuntan cualquiera o todos esos descriptores de archivo antes de ejecutar el comando; eso es lo que hacen los operadores de redirección ( < , << , > , >> ) y pipe ( | ).
El tubo es el más simple de estos ... command1 | command2 command1 | command2 organiza la salida estándar de command1 para ingresar directamente a la entrada estándar de command2 . Esta es una disposición muy útil que ha dado lugar a un patrón de diseño particular en las herramientas UNIX (y explica la existencia de un error estándar, que permite que un programa envíe mensajes al usuario a pesar de que su salida va al próximo programa en la tubería) . Pero solo se puede canalizar la salida estándar a la entrada estándar; no se pueden enviar otros descriptores de archivo a una tubería sin hacer malabarismos.
Los operadores de redireccionamiento son más amigables porque le permiten especificar qué descriptor de archivo redirigir. Entonces, 0<infile lee la entrada estándar del archivo denominado infile , mientras que 2>>logfile agrega el error estándar al final del archivo llamado logfile . Si no especifica un número, la redirección de entrada por defecto es fd 0 ( < es igual a 0< ), mientras que la redirección de salida por defecto es fd 1 ( > es igual a 1> ).
Además, puede combinar descriptores de archivos juntos: 2>&1 significa "enviar error estándar a donde quiera que vaya la salida estándar". Eso significa que obtienes una única secuencia de salida que incluye tanto la salida estándar como la del error estándar entremezcladas sin ninguna forma de separarlas más, pero también significa que puedes incluir un error estándar en una tubería.
Por lo tanto, la secuencia >/dev/null 2>&1 significa "enviar salida estándar a /dev/null " (que es un dispositivo especial que simplemente elimina lo que se escribe) y luego envía un error estándar a donde sea que vaya la salida estándar "(que solo nos aseguramos era /dev/null ). Básicamente, "elimine lo que este comando escriba en cualquiera de los descriptores de archivos".
Cuando nohup detecta que ni su error estándar ni su salida se adjuntan a un terminal, no se molesta en crear nohup.out , sino que asume que la salida ya está redirigida a donde el usuario quiere ir.
El dispositivo /dev/null funciona como entrada; si ejecuta un comando con </dev/null , entonces cualquier intento de ese comando de leer desde la entrada estándar se encontrará instantáneamente con el final del archivo. Tenga en cuenta que la sintaxis de fusión no tendrá el mismo efecto aquí; solo funciona para apuntar un descriptor de archivo a otro que esté abierto en la misma dirección (entrada o salida). El shell le permitirá hacer >/dev/null <&1 , pero eso termina creando un proceso con un descriptor de archivo de entrada abierto en una secuencia de salida, por lo que en lugar de solo llegar al final del archivo, cualquier intento de lectura provocará un error fatal. error "descriptor de archivo inválido"
nohup some_command > /dev/null 2>&1&
¡Eso es todo lo que necesitas hacer!
sudo bash -c "nohup /opt/viptel/viptel_bin/log.sh $* &> /dev/null" &
La redirección de la salida de sudo hace que sudo vuelva a solicitar la contraseña, por lo que se necesita un mecanismo incómodo para hacer esta variante.