Non c'è nohup, c'è un comando nousr1?

Molti dei miei programmi regolari si bloccano (su base regolare) con il messaggio "Segnale 1 definito dall'utente". So che c'è un nohupcomando, ma c'è un nousr1comando? O qualcosa che farà qualcosa di simile nohupma con USR1?

linux

— user2624632
fonte

La domanda migliore potrebbe essere che cosa lo sta inviando il segnale usr1 in primo luogo? Se non lo è, il messaggio di uscita potrebbe essere semplicemente fuorviante.

— Concedi il

Sembra che potresti avere alcuni seri problemi nei tuoi "programmi regolari" ... semplicemente disabilitando i segnali potresti non correggere o abilitare il corretto funzionamento delle applicazioni sottostanti. Consiglio vivamente di esaminare il tuo ambiente CON ATTENZIONE prima di disabilitare le cose.

— mdpc,

@Grant: sono d'accordo. Esiste un'utilità che può dirmi cosa sta inviando questi segnali?

— user2624632

Risposte:

Una soluzione hacky semplice per avere l'utilità analoga a nohup, ma per SIGUSR1, sarebbe quella di ottenere una copia del coreutils sorgente, decomprimerlo, fare

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

, facoltativamente modificare anche il nome del file di output

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

, compila questo sorgente e installa il nohupbinario appena compilato su /usr/bin/nousr1:

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

Dopo questo, come ho verificato, sleep 1000esce USR1, mentre nousr1 sleep 1000è immune da questo segnale.

— Ruslan
fonte

La principale funzionalità di nohup, tra l'altro, è di dissociare il processo dal terminale in modo che non venga inviato SIGHUPin primo luogo. Che istituisca anche un gestore di segnale è un vantaggio aggiuntivo, ma non dovrebbe essere necessario.

— Simon Richter,

@SimonRichter Se si rimuove la signal(SIGHUP,SIG_IGN);chiamata nohup.c, il processo riceverà il SIGHUP. Ciò nohupche oltre a ignorare il segnale è semplicemente riaprire i descrittori stdin, stdout, stderr come file non terminali. In realtà non dissocia il processo dal terminale in alcun modo speciale. Cioè, il processo verrà inviato SIGHUPquando il terminale si blocca. Dall'altra parte c'è bash, che fa cosa simile con disownil comando, ma non sono sicuro di come si sia realizzata - forse nel modo che vuoi dire.

— Ruslan,

Questo sembra funzionare bene.

— user2624632

Che ne dici del trapcomando integrato della shell ?

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

— Janne Pikkarainen
fonte

Buona idea, ma non ha funzionato. Il processo è terminato comunque con "Segnale 1 definito dall'utente".

— user2624632

I gestori di segnali (diversi da SIG_IGN e SIG_DFL) non sono ereditati dai processi figlio.

— carrello

È necessario utilizzare il modulo del trapcomando con un argomento vuoto. Prova questo:

trap '' SIGUSR1; myprogram

Questo ignorerà il segnale SIGUSR1 che è quello che stai cercando di fare. Anche se concordo con i commentatori sul fatto che probabilmente qui sta succedendo più di quanto non sembri.

Il modulo errato:

trap 'echo ...' SIGUSR1; myprogram

consentirà comunque myprogramdi ricevere SIGUSR1 ma la shell eseguirà quindi echoil trapcomando.

— Adrian Pronk
fonte

Questo sembra funzionare bene.

— user2624632

Ops, ho parlato troppo presto. Stavo correndo trap '' SIGUSR1; gvimdiff file1 file2e Vim è morto con "Vim: Caught deadly signal USR1".

— user2624632

Hmmm, guardando il codice sorgente su code.google.com/p/vim/source/browse/src/os_unix.c sembra che VIM riattivi il segnale USR1 e lo tratta come un errore fatale. La tua unica speranza sembrerebbe essere se puoi far rifiutare al sistema operativo di inviare il segnale USR1. Non so se c'è qualcosa là fuori che può fornire quella funzionalità.

— Adrian Pronk,

Maggiori informazioni qui: stackoverflow.com/q/4515274/41861

— Adrian Pronk

Adrian Pronk: non è solo Vim; è anche Firefox, Aqualung, Thunderbird e alcuni altri. Ma non altre app, come Konsole, che funziona per sempre.

— user2624632