Il n'y a rien, y a-t-il une commande nousr1?


12

Plusieurs de mes programmes réguliers se bloquent (régulièrement) avec le message "Signal défini par l'utilisateur 1". Je sais qu'il y a une nohupcommande, mais y a-t-il une nousr1commande? Ou quelque chose qui fera quelque chose comme nohupmais avec USR1?


3
La meilleure question pourrait être de savoir ce qui lui envoie le signal usr1 en premier lieu? Si rien ne l'est, le message de sortie peut simplement être trompeur.
Grant

2
On dirait que vous pourriez avoir de sérieux problèmes dans vos "programmes réguliers" ... simplement, la désactivation des signaux peut ne pas corriger ou permettre aux applications sous-jacentes de fonctionner correctement. Je vous suggère fortement d'examiner attentivement votre environnement avant de désactiver les choses.
mdpc

@Grant: je suis d'accord. Existe-t-il un utilitaire qui peut me dire ce qui envoie ces signaux?
user2624632

Réponses:


3

Une simple solution hacky pour avoir l'utilitaire analogue nohup, mais pour SIGUSR1, serait d'obtenir une copie de la source coreutils , de la déballer, de faire

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

, modifiez également éventuellement le nom du fichier de sortie

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

, compilez cette source et installez le nohupbinaire nouvellement compilé pour /usr/bin/nousr1:

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

Après cela, comme je l'ai vérifié, la sleep 1000sortie continue USR1, tout en nousr1 sleep 1000étant à l'abri de ce signal.


Soit dit nohupen passant, la fonctionnalité principale consiste à dissocier le processus du terminal afin qu'il ne soit pas envoyé SIGHUPen premier lieu. Le fait qu'il configure également un gestionnaire de signaux est un bonus supplémentaire, mais ne devrait pas être nécessaire.
Simon Richter

@SimonRichter Si vous supprimez l' signal(SIGHUP,SIG_IGN);appel nohup.c, le processus recevra le SIGHUP. Que nohupfait part d'ignorer le signal est juste réouverture stdin, stdout, descripteurs stderr sous forme de fichiers non-terminaux. Il ne dissocie pas vraiment le processus du terminal d'une manière spéciale. C'est-à-dire que le processus sera envoyé SIGHUPlorsque le terminal raccroche. De l'autre côté, il y a bash, qui fait la même chose avec la disowncommande, mais je ne sais pas comment il est implémenté - peut-être dans le sens que vous entendez.
Ruslan

Cela semble bien fonctionner.
user2624632

8

Qu'en est trap-il de la commande intégrée au shell ?

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

Bonne idée, mais ça n'a pas marché. Le processus s'est quand même terminé avec "Signal défini par l'utilisateur 1".
user2624632

Les gestionnaires de signaux (autres que SIG_IGN et SIG_DFL) ne sont pas hérités par les processus enfants.
aecolley

2

Vous devez utiliser le formulaire de la trapcommande avec un argument vide. Essaye ça:

trap '' SIGUSR1; myprogram

Cela ignorera le signal SIGUSR1, ce que vous essayez de faire. Bien que je convienne avec les commentateurs qu'il se passe probablement plus de choses ici qu'il n'y paraît.

Le formulaire incorrect:

trap 'echo ...' SIGUSR1; myprogram

permettra toujours myprogramde recevoir le SIGUSR1 mais le shell exécutera ensuite le à echopartir de la trapcommande.


Cela semble bien fonctionner.
user2624632

Oups, j'ai parlé trop tôt. Je courais trap '' SIGUSR1; gvimdiff file1 file2et Vim est mort avec "Vim: Pris le signal mortel USR1".
user2624632

Hmmm, en regardant le code source à code.google.com/p/vim/source/browse/src/os_unix.c, il semble que VIM réactive le signal USR1 et le traite comme une erreur fatale. Votre seul espoir semble être que vous puissiez faire en sorte que le système d'exploitation refuse de délivrer le signal USR1. Je ne sais pas s'il y a quelque chose qui peut fournir cette fonctionnalité.
Adrian Pronk


Adrian Pronk: ce n'est pas seulement Vim; c'est aussi Firefox, et Aqualung, et Thunderbird, et quelques autres. Mais pas d'autres applications, comme Konsole, qui fonctionne pour toujours.
user2624632
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.