Demony, sygnały i unicestwianie procesów

Takie programy nazywane są demonami. Demony to postaci z mitologii greckiej - niewielkie usłużne istoty, ani dobre ani złe, które w rozmaity sposób pomagały ludziom. Podobnie pomagają dzisiejsze serwery pocztowe i serwery HTTP. Dlatego też od długiego czasu maskotką BSD jest wesoły demon z widłami i w tenisówkach.

Przyjęto, iż programy uruchamiane jako demony mają nazwy zakończone literą "d". BIND (Berkeley Internet Name Daemon) jest serwerem nazw (uruchamianym przez program named), serwer HTTP Apache nosi nazwę httpd, demon kolejkowania drukarki (line printer spooling daemon) to lpd i tak dalej. Nie jest to sztywna reguła, lecz przyjęta konwencja; na przykład główny demon pocztowy programu Sendmail nazywa się sendmail, a nie maild, jak można by przypuszczać.

Niekiedy istnieje potrzeba komunikacji z procesem - demonem. Odbywa się ona poprzez sygnały, to znaczy można porozumieć się z demonem (lub jakimkolwiek działającym procesem) wysyłając mu sygnał. Są różne rodzaje sygnałów, które można wysłać - niektóre z nich mają określone znaczenie, inne są odpowiednio interpretowane przez aplikację, co powinno być opisane w dokumentacji aplikacji. Sygnał wysłać można tylko do procesu, którego jest się właścicielem. Wysłanie sygnału do procesu należącego do kogoś innego za pośrednictwem kill(1) lub kill(2) spowoduje odmowę dostępu. Wyjątkiem jest root, który może wysyłać sygnały do dowolnego procesu, niezależnie od jego właściciela.

Zdarza się, że samo FreeBSD również wysyła aplikacjom sygnały. Jeżeli niewłaściwie napisany program próbuje dostać się do niedostępnego dla niego obszaru pamięci, FreeBSD wysyła procesowi sygnał Segmentation Violation (SIGSEGV). Aplikacja może skorzystać z funkcji systemowej alarm(3), wówczas po upłynięciu pewnego czasu zostanie do niej wysłany sygnał Alarm (SIGALRM). I tak dalej.

Do zatrzymania procesu można wykorzystać dwa sygnały: SIGTERM i SIGKILL. Pierwszy z nich jest łagodnym sposobem unicestwienia procesu; proces może przechwycić ten sygnał, następnie zakończyć swoją pracę, np. zamykając pliki, które otworzył. Czasami proces może zignorować sygnał SIGTERM, jeśli akurat zajmuje się czymś, co nie powinno być przerywane.

Sygnał SIGKILL nie może zostać zignorowany. Działa według zasady: "Nie obchodzi mnie, co robisz, w tej chwili przestań". Wysłanie procesowi sygnału SIGKILL powoduje, iż FreeBSD natychmiast go wstrzymuje[1].

Inne użyteczne sygnały to SIGHUP, SIGUSR1 i SIGUSR2. Są to sygnały ogólnego przeznaczenia, różne aplikacje reagują na nie w różny sposób.

Powiedzmy, że użytkownik dokonał zmiany w pliku konfiguracji serwera HTTP, i chciałby nakazać serwerowi, aby konfiguracja została ponownie wczytana. Można by zatrzymać i ponownie uruchomić httpd, ale ubocznym efektem takiego postępowania byłaby chwilowa przerwa w pracy serwera, co jest raczej niepożądane. Większość demonów działa w taki sposób, iż po otrzymaniu sygnału SIGHUP dokonują ponownego przeczytania swojego pliku konfiguracji. Dzięki temu zamiast unicestwiania i ponownego uruchamiania httpd można wysłać mu sygnał SIGHUP. Nie jest jednoznacznie określone, jak procesy reagują na sygnał SIGHUP, dlatego różne demony mogą zachowywać się w różny sposób - w razie niepewności warto zapoznać się z dokumentacją konkretnego demona.

Sygnały wysyłane są przy użyciu polecenia kill(1), jak w poniższym przykładzie.

1. Trzeba ustalić PID procesu, do którego wysyłany będzie sygnał - do tego celu posłużą polecenia ps(1) i grep(1). Polecenie grep(1) używane jest do odnalezienia podanego ciągu znaków. Ponieważ polecenia wydaje zwykły użytkownik, a inetd(8) działa jako as root, polecenie ps(1) musi być wywołane z opcją ax.

   	% ps -ax | grep inetd
   	  198  ??  IWs    0:00.00 inetd -wW
   

   Jak widać, inetd(8) ma PID o wartości 198. Niekiedy w przedstawionym powyżej przykładzie może się także pojawić proces grep inetd, wynika to ze sposobu, w jaki ps(1) odnajduje działające procesy.

2. Proces zostanie unicestwiony przy pomocy polecenia kill(1). Najpierw trzeba jednak skorzystać z polecenia su(1) by stać się rootem, gdyż inetd(8) działa jako root.
   

   	% su
   	Password:
   	# /bin/kill -s HUP 198
   

Podobnie jak wiele uniksowych poleceń, kill(1) nie wyświetla żadnego komunikatu w przypadku powodzenia. Jeżeli natomiast sygnał został wysłany do procesu, którego nie jest się właścicielem, pojawi się informacja: "kill: PID: Operation not permitted". Błędne wpisanie PID-u spowoduje albo wysłanie sygnału do niewłaściwego procesu, co może skończyć się źle, albo też wysłanie sygnału do PID-u który nie jest w danej chwili wykorzystywany - pojawi się wówczas komunikat "kill: PID: No such process".

Dlaczego powinno się korzystać z polecenia /bin/kill?: W wielu powłokach polecenie kill jest wbudowane; oznacza to, że sama powłoka zajmuje się wysyłaniem sygnału, nie wywołując /bin/kill. Może to być użyteczne, jednakże w różnych powłokach stosowana jest różna składnia do określenia nazwy sygnału, który ma być wysłany. Zamiast więc zapamiętywania wszystkich składni, łatwiej jest po prostu korzystać z polecenia /bin/kill ....

Inne sygnały wysyła się tą samą metodą, wystarczy zastąpić TERM lub KILL w odpowiedni sposób.

Uwaga: Unicestwienie losowo wybranego procesu jest raczej złym pomysłem. Szczególne znaczenie ma init(8), proces o PID równym 1. Wydanie polecenia /bin/kill -s KILL 1 jest szybką metodą wyłączenia systemu. Należy zawsze sprawdzać poprawność argumentów polecenia kill(1) przed naciśnięciem klawisza Return.