SIGINFO sur GNU Linux (Arch Linux) manquant

12

Je développe une application et j'aimerais qu'elle imprime à la demande des statistiques d'exécution sur la console. killet des signaux me sont venus immédiatement à l’esprit.

La lecture des signaux Unix sur Wiki SIGINFOsemble être la voie à suivre car:

  • Il est destiné à ces fins
  • N'arrête pas le processus si le gestionnaire de signal n'est pas implémenté (contrairement à SIGUSRx- voir ici )

Cependant, en inspectant la sortie de kill -l, il semble que mon serveur ne dispose pas de ce signal.

Mes questions sont:

  1. Pourquoi SIGINFOmanque- t- il sur mon système? Est-il absent sur tous les systèmes GNU Linux?
  2. Existe-t-il un moyen simple (c'est-à-dire pas de recompilation noyau / glibc) d'activer ce signal? Sinon, quelle serait la difficulté?
  3. Quel signal alternatif pourrais-je utiliser à mes fins qui ne provoquerait aucun effet secondaire s'il n'était pas géré par le processus cible? (J'en suppose déjà aucun car je n'ai trouvé aucun autre signal approprié dans le manuel de la glibc )

Métainfo Linux:

Linux whatever 3.18.2-2-ARCH #1 SMP PREEMPT Fri Jan 9 07:37:51 CET 2015 x86_64 GNU/Linux

Mise à jour: je suis toujours à la recherche de plus d'informations sur les raisons pour lesquelles ce signal est conditionnellement exclu d'autres systèmes que BSD (voir les commentaires ci-dessous). Le signal semble être très utile à de nombreuses fins, il est donc difficile pour moi de croire que c'est juste une question de caprice - alors quel est le véritable showstopper pour que ce signal soit disponible sur Linux?

Robert Rossmann
la source
2
Apparaît ^Tdans la sortie de stty -a?
Mark Plotnick
Ah, ce n'est pas le cas - je dois avoir confondu le comportement décrit ddavec celui de mon Mac. ^Tpendant l' ddexécution ne fait rien sur la machine Linux - je mettrai à jour la question en conséquence.
Robert Rossmann
Oui, Ctrl-T et SIGINFO sont des fonctionnalités BSD (et MacOSX).
Mark Plotnick
Mais le signal est défini dans la bibliothèque GNU C que les systèmes Linux utilisent ... Est-il alors désactivé volontairement?
Robert Rossmann
1
@RobertRossmann, les signaux sont délivrés par le noyau. La question est de savoir pourquoi le noyau Linux ne l'implémente pas (car il a probablement copié les signaux SysV).
Ángel

Réponses:

4

Il a été question (de retour sous Linux 0.x-1.x jours) d'ajouter ceci (car c'était utile sur les systèmes BSD) mais si je me souviens bien, il y avait des raisons pour lesquelles il était plus difficile de bien faire sous Linux que BSD à l'époque .

Notez que ce que vous demandez au sujet est seulement une petite partie de la fonction ( à savoir, vous parlez d' une stty infoentrée pour le contrôle-T provoque le noyau de fournir SIGINFOau ttygroupe de processus d ») - cette partie est « facile » - mais le fait que le noyau rapporte des informations sur l'état du processus lorsqu'il ne gère pas le signal (car à l'époque très peu de choses étaient prises en charge pour cela, la fonctionnalité concernait principalement "est-ce que ce processus tourne ou se bloque" et "quel processus est de toute façon ") est plus difficile - ISTR, il y a même des problèmes de sécurité / de confiance concernant l'affichage précis de ces informations, et si elles doivent être associées au chemin d'accès de la clé d'attention sécurisée. Cela dit, il pourrait y avoir une certaine valeur dans la version "facile" qui n'envoie que le signal ...

(De mémoire personnelle; une recherche rapide sur le Web ne semble pas évidente mais je pense qu'il faudrait fouiller dans de très vieilles archives pour trouver la discussion.)

eichin
la source
1

Concernant votre question 1):

Depuis man 7 signalun système Arch Linux:

SIGINFO 29, -, - Un synonyme de SIGPWR

(Le signal 29 est SIGINFO / SIGPWR sur un alpha mais SIGLOST sur un sparc.)

SIGPWR (qui n'est pas spécifié dans POSIX.1-2001) est généralement ignoré par défaut sur les autres systèmes UNIX où il apparaît.

Selon cette définition, SIGINFOseul est disponible sur les architectures alpha ou sparc.

Guido
la source