Brak SIGINFO w systemie GNU Linux (Arch Linux)

Tworzę aplikację i chciałbym, aby na żądanie drukowała na konsoli niektóre statystyki środowiska wykonawczego. killi sygnały natychmiast przyszły mi do głowy.

Odczytywanie sygnałów uniksowych na Wiki SIGINFOwydaje się właściwą drogą, ponieważ:

Jest przeznaczony do tych celów
Nie przerywa procesu, jeśli procedura obsługi sygnału nie jest zaimplementowana (w przeciwieństwie do SIGUSRx- patrz tutaj )

Jednak po sprawdzeniu wyjścia kill -lwydaje się, że mój serwer nie ma zaimplementowanego tego sygnału.

Moje pytania to:

Dlaczego SIGINFObrakuje w moim systemie? Czy nie ma go we wszystkich systemach GNU Linux?
Czy istnieje prosty (tj. Brak rekompilacji jądra / glibc) sposób na włączenie tego sygnału? Jeśli nie, jaka byłaby trudna droga?
Jakiego alternatywnego sygnału mógłbym użyć do swoich celów, które nie spowodowałyby żadnych skutków ubocznych, gdyby nie zostały przetworzone przez proces docelowy? (Już nie zakładam, ponieważ nie mogłem znaleźć innego odpowiedniego sygnału w instrukcji glibc )

Linux metainfo:

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

Aktualizacja: wciąż szukam więcej informacji na temat tego, dlaczego ten sygnał jest warunkowo wykluczony z systemów innych niż BSD (patrz komentarze poniżej). Sygnał wydaje się bardzo przydatny do wielu celów, więc trudno mi uwierzyć, że to tylko kwestia kaprysu - więc jaki jest prawdziwy showstopper dla tego sygnału w Linuksie?

linux signals glibc

— Robert Rossmann
źródło

Czy ^Tpojawia się na wyjściu stty -a?

— Mark Plotnick

Ach, tak nie jest - musiałem pomylić opisane zachowanie ddz tym na moim Macu. ^Tpodczas ddwykonywania nic nie robi na maszynie z Linuksem - odpowiednio zaktualizuję pytanie.

— Robert Rossmann

Tak, Ctrl-T i SIGINFO są funkcjami BSD (i MacOSX).

— Mark Plotnick,

Ale sygnał jest zdefiniowany w Bibliotece GNU C, której używają systemy Linux ... Czy następnie jest celowo wyłączany?

— Robert Rossmann

@RobertRossmann, sygnały są dostarczane przez jądro. Pytanie brzmi, dlaczego jądro Linuksa go nie implementuje (ponieważ prawdopodobnie skopiowały sygnały SysV).

— Ángel

Odpowiedzi:

Mówiono (w Linuksie od 0.x-1.x dni) o dodaniu tego (ponieważ było to przydatne w systemach BSD), ale jeśli dobrze pamiętam, były powody, dla których w Linuksie trudniej było robić to lepiej niż BSD .

Zauważ, że to, o co pytasz, to tylko niewielka część funkcji (a mianowicie mówisz o stty infowpisie control-T, który powoduje, że jądro dostarcza się SIGINFOdo ttygrupy procesów) - ta część jest „łatwa” - ale mając informacje z raportu jądra o statusie procesu, gdy nie obsługuje on sygnału (ponieważ w tamtym czasie bardzo niewiele rzeczy miało jakieś wsparcie, funkcja dotyczyła głównie „czy ten proces się kręci lub zawiesił” i „jaki jest proces i tak ”) jest trudniejszy - w ISTR występują nawet problemy z bezpieczeństwem / zaufaniem dotyczące dokładnego wyświetlania tych informacji i tego, czy powinny być powiązane ze ścieżką Bezpiecznego Klucza Uwaga. To powiedziawszy, może być pewna wartość w „łatwej” wersji, która wysyła tylko sygnał ...

(Z osobistej pamięci; szybkie wyszukiwanie w Internecie nie ujawnia niczego oczywistego, ale myślę, że trzeba by zajrzeć do naprawdę starych archiwów, aby znaleźć dyskusję.)

— eichin
źródło

Jeśli chodzi o twoje pytanie 1):

Z man 7 signalsystemu Arch Linux:

SIGINFO 29, -, - Synonim SIGPWR

…

(Sygnał 29 to SIGINFO / SIGPWR na alfa, ale SIGLOST na sparc.)

…

SIGPWR (który nie jest określony w POSIX.1-2001) jest zwykle domyślnie ignorowany w tych innych systemach UNIX, w których się pojawia.

Zgodnie z tą definicją SIGINFOjest dostępna tylko dla architektur alfa lub sparc.

— Guido
źródło