SIGINFO unter GNU Linux (Arch Linux) fehlt

Ich entwickle eine Anwendung und möchte, dass sie bei Bedarf einige Laufzeitstatistiken auf die Konsole druckt. killund Signale kamen mir sofort in den Sinn.

Das Lesen von Unix-Signalen im Wiki SIGINFOscheint der richtige Weg zu sein, weil:

Es ist beabsichtigt , für diese Zwecke
Beendet den Prozess nicht, wenn der Signalhandler nicht implementiert ist (im Gegensatz zu SIGUSRx- siehe hier )

Bei der Überprüfung der Ausgabe von kill -lscheint es jedoch, dass auf meinem Server dieses Signal nicht implementiert ist.

Meine Fragen sind:

Warum SIGINFOfehlt auf meinem System? Fehlt es auf allen GNU Linux-Systemen?
Gibt es eine einfache Möglichkeit (dh keine Kernel / Glibc-Neukompilierung), um dieses Signal zu aktivieren? Wenn keine, was wäre der harte Weg?
Welches alternative Signal könnte ich für meine Zwecke verwenden, das keine Nebenwirkungen verursachen würde, wenn es nicht vom Zielprozess behandelt würde? (Ich gehe bereits von keinem aus, da ich im Handbuch des glibc kein anderes geeignetes Signal finden konnte. )

Linux metainfo:

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

Update: Ich suche noch nach weiteren Informationen darüber, warum dieses Signal von anderen Systemen als BSD bedingt ausgeschlossen wird (siehe Kommentare unten). Das Signal scheint für viele Zwecke sehr nützlich zu sein, daher fällt es mir schwer zu glauben, dass es nur eine Frage der Laune ist. Was ist also der wahre Showstopper für die Verfügbarkeit dieses Signals unter Linux?

linux signals glibc

— Robert Rossmann
quelle

Ist ^Tin der Ausgabe von stty -a?

— Mark Plotnick

Ah, das tut es nicht - ich muss das beschriebene Verhalten ddmit dem auf meinem Mac verwechselt haben . ^TWährend der ddAusführung tut nichts auf dem Linux-Rechner - ich werde die Frage entsprechend aktualisieren.

— Robert Rossmann

Ja, Strg-T und SIGINFO sind BSD- (und MacOSX-) Funktionen.

— Mark Plotnick

Das Signal ist jedoch in der GNU C-Bibliothek definiert, die von Linux-Systemen verwendet wird. Wird es dann absichtlich deaktiviert?

— Robert Rossmann

@RobertRossmann, die Signale werden vom Kernel geliefert. Die Frage ist, warum der Linux-Kernel es nicht implementiert (weil sie wahrscheinlich SysV-Signale kopiert haben).

— Ángel

Antworten:

Es war die Rede (in den Tagen von Linux 0.x-1.x) darüber, dies hinzuzufügen (weil es auf BSD-Systemen nützlich war), aber wenn ich mich richtig erinnere, gab es Gründe, warum es unter Linux schwieriger war, es richtig zu machen als BSD zu dieser Zeit .

Beachten Sie, dass das, worüber Sie fragen, nur ein kleiner Teil der Funktion ist (Sie sprechen nämlich von einem stty infoEintrag für control-T, der bewirkt, dass der Kernel SIGINFOan die ttyProzessgruppe der Funktion übermittelt ) - dieser Teil ist "einfach" - Wenn der Kernel jedoch Informationen über den Prozessstatus meldet, wenn er das Signal nicht verarbeitet (da zu diesem Zeitpunkt nur sehr wenige Dinge dies unterstützten, ging es in der Funktion hauptsächlich um "Ist dieser Prozess dreht sich oder hängt" und "Was ist der Prozess?" es ist sowieso ") schwieriger - ISTR Es gibt sogar Sicherheits- / Vertrauensprobleme bei der genauen Anzeige dieser Informationen und ob sie mit dem Pfad des sicheren Aufmerksamkeitsschlüssels verknüpft werden sollten. Das heißt, es könnte einen Wert in der "einfachen" Version geben, der nur das Signal sendet ...

(Aus dem persönlichen Gedächtnis; eine schnelle Websuche zeigt nichts Offensichtliches, aber ich denke, man müsste in wirklich alten Archiven stöbern, um die Diskussion zu finden.)

— Eichin
quelle

Zu Ihrer Frage 1):

Von man 7 signalauf einem Arch Linux-System:

SIGINFO 29, -, - Ein Synonym für SIGPWR

…

(Signal 29 ist SIGINFO / SIGPWR auf einem Alpha, aber SIGLOST auf einem Sparc.)

…

SIGPWR (das in POSIX.1-2001 nicht angegeben ist) wird auf den anderen UNIX-Systemen, auf denen es angezeigt wird, normalerweise standardmäßig ignoriert.

Nach dieser Definition ist SIGINFOnur auf Alpha- oder Sparc-Architekturen verfügbar.

— Guido
quelle