No hay nohup, ¿hay un comando nousr1?

Varios de mis programas habituales se bloquean (regularmente) con el mensaje "Señal 1 definida por el usuario". Sé que hay un nohupcomando, pero ¿hay un nousr1comando? ¿O algo que haga algo como nohuppero con USR1?

linux

— usuario2624632
fuente

La mejor pregunta podría ser ¿qué le está enviando la señal usr1 en primer lugar? Si nada es así, el mensaje de salida puede ser simplemente engañoso.

— Grant

Parece que podría tener algunos problemas serios en sus "programas regulares" ... simplemente deshabilitar las señales puede no corregir o permitir que las aplicaciones subyacentes funcionen correctamente. Te sugiero que examines tu entorno CUIDADOSAMENTE antes de deshabilitar las cosas.

— mdpc

@Grant: estoy de acuerdo. ¿Hay alguna utilidad que pueda decirme qué está enviando estas señales?

— user2624632

Respuestas:

Una solución hacky simple para tener la utilidad análoga a nohup, pero para SIGUSR1, sería obtener una copia de la fuente coreutils , descomprimirla, hacer

sed -i 's/SIGHUP/SIGUSR1/' /path/to/coreutils/src/nohup.c

, opcionalmente también cambia el nombre del archivo de salida

sed -i 's/nohup\.out/nousr1.out/g' /path/to/coreutils/src/nohup.c

, compile esta fuente e instale el nohupbinario recién compilado para /usr/bin/nousr1:

cp /path/to/coreutils/src/nohup /usr/bin/nousr1

Después de esto, como lo comprobé, sleep 1000sale USR1, mientras que nousr1 sleep 1000es inmune a esta señal.

— Ruslan
fuente

La principal funcionalidad de nohup, por cierto, es desasociar el proceso del terminal para que no se envíe SIGHUPen primer lugar. Que también configure un controlador de señal es una ventaja adicional, pero debería ser innecesaria.

— Simon Richter

@SimonRichter Si elimina la signal(SIGHUP,SIG_IGN);llamada nohup.c, el proceso recibirá el SIGHUP. Además nohupde ignorar la señal, lo único que hace es volver a abrir los descriptores stdin, stdout, stderr como archivos no terminales. Realmente no disocia el proceso del terminal de ninguna manera especial. Es decir, el proceso se enviará SIGHUPcuando el terminal cuelgue. Por otro lado, está bash, que hace algo similar con el disowncomando, pero no estoy seguro de cómo se implementa, tal vez en la forma en que te refieres.

— Ruslan

Esto parece funcionar bien.

— user2624632

¿Qué tal el trapcomando de shell incorporado?

trap 'echo "Thou shalt not USR1 me"' USR1

— Janne Pikkarainen
fuente

Buena idea, pero no funcionó. El proceso salió de todos modos con "Señal definida por el usuario 1".

— user2624632

Los manejadores de señales (que no sean SIG_IGN y SIG_DFL) no son heredados por los procesos secundarios.

— aecolley

Debe usar la forma del trapcomando con un argumento en blanco. Prueba esto:

trap '' SIGUSR1; myprogram

Esto ignorará la señal SIGUSR1, que es lo que está tratando de hacer. Aunque estoy de acuerdo con los comentaristas en que probablemente hay más cosas aquí de lo que parece.

La forma incorrecta:

trap 'echo ...' SIGUSR1; myprogram

aún permitirá myprogramrecibir el SIGUSR1 pero el shell ejecutará echoel trapcomando.

— Adrian Pronk
fuente

Esto parece funcionar bien.

— user2624632

Vaya, hablé demasiado pronto. Estaba corriendo trap '' SIGUSR1; gvimdiff file1 file2y Vim murió con "Vim: Señal mortal capturada USR1".

— user2624632

Hmmm, mirando el código fuente en code.google.com/p/vim/source/browse/src/os_unix.c parece que VIM vuelve a habilitar la señal USR1 y la trata como un error fatal. Su única esperanza parece ser si puede hacer que el sistema operativo se niegue a entregar la señal USR1. No sé si hay algo por ahí que pueda proporcionar esa funcionalidad.

— Adrian Pronk

Más información aquí: stackoverflow.com/q/4515274/41861

— Adrian Pronk

Adrian Pronk: no es solo Vim; También es Firefox, y Aqualung, y Thunderbird, y algunos otros. Pero no otras aplicaciones, como Konsole, que se ejecuta para siempre.

— user2624632