Laboratorium 4 - Procesy, demony i sygnały

Demony, inaczej usługi, są pewnym rodzajem programów, które są uruchamiane zazwyczaj przy starcie systemu działając najczęściej cały czas w tle. Procesy tych usług posiadają w Linux specjalne określenie: demon (ang. daemon). W praktyce wiele programów umożliwia uruchomienie ich w trybie demona, a typowymi usługami działającymi w ten sposób są: serwery WWW (np. Apache, nginx), DNS (np. bind), mail (pocztowe), X server, baza danych (np. MySQL, PostgreSQL), demon usług sieciowych i DHCP, itp… Procesy demonów będące usługami w każdej chwili mogą przyjąć od innego programu polecenie (żądanie) w celu ich obsłużenia. Demonem jest np. serwer HTTP, który cały czas jest uruchomiony w tle, a w momencie gdy przychodzi żądanie od przeglądarki wysyła odpowiedni plik lub wykonuje jakąś akcję. Demon może również obsługiwać programy działające na tym samym komputerze.

Kolejną cechą charakterystyczną demonów, jest to że nowoczesne dystrybucje Linux najczęściej posiadają wbudowane podsystemy do zarządzania uruchamianiem tych procesów. Np. dbają one o to aby przy każdym starcie systemu procesy demonów były automatycznie uruchomione. Często również do obsługi procesów demonów używa się różnego rodzaju aplikacji monitorujących stan ich procesów po to aby np. gdy demon zakończy się z błędem, był on znowu uruchomiony i dzięki temu było dalej możliwe łączenie się z daną usługą. Do zatrzymania działania demona służą specjalne skrypty, które w popularnych dystrybucjach (Debian, Ubuntu) znajdują się zazwyczaj w katalogu /etc/init.d/. W Ubuntu powinno się używać polecenia service, które je wywołuje.

Skrypty te mogą być uruchamiane z następującymi opcjami:

Niektóre mogą przyjmować również inne opcje, jednak te trzy są standardowe.

Zawiera informacje na temat procesora.

Zawiera informacje na temat pamięci RAM w systemie.

Wypisuje listę procesów w systemie.

Wyświetla procesy w trybie interaktywnym.

Sortowanie odbywa się domyślnie po kolumnie %CPU. Zmiana sortowania odbywa się przez naciśnięcie > i <.

(na podstawie/źródło: http://students.mimuw.edu.pl/SO/LabLinux/PROCESY/PODTEMAT_3/sygnaly.html )

Procesy komunikują się z jądrem systemu, a także między sobą aby koordynować swoją działalność. Linux wspiera kilka mechanizmów komunikacji zwanych IPC (Inter-Process Communication mechanisms). Jednym z nich są sygnały, zwane inaczej przerwaniami programowymi.

Sygnały mogą być generowane bezpośrednio przez użytkownika (funkcja kill()), może wysyłać je jądro oraz procesy między sobą (funkcja systemowa kill()) . Dodatkowo pewne znaki z terminala powodują wygenerowanie sygnałów. Na przykład na każdym terminalu istnieje tak zwany znak przerwania (ang. interrupt character) i znak zakończenia (ang. quit character). Znak przerwania (zazwyczaj Ctrl+C lub Delete) służy do zakończenia bieżącego procesu (wygenerowanie SIGINT). Wygenerowanie znaku zakończenia (zazwyczaj Ctrl-\) powoduje wysłanie sygnału SIGQUIT powodującego zakończenie wykonywania bieżącego procesu z zapisaniem obrazu pamięci.

Istnieją oczywiście pewne ograniczenia - proces może wysyłać je tylko do procesów mających tego samego właściciela oraz z tej samej grupy (te same UID i GID). Bez ograniczeń może to czynić jedynie jądro i administrator. Jedynym procesem, który nie odbiera sygnałów jest init (PID równy 1).

Sygnały są mechanizmem asynchronicznym - proces nie wie z góry kiedy sygnał może nadejść i głównym ich zadaniem jest informowanie procesu o zaistnieniu w systemie wyjątkowej sytuacji (np. spadek napięcia w sieci). Ponadto są wykorzystywane przez shelle do kontroli pracy swoich procesów potomnych.

Każdy z sygnałów posiada swoje znaczenie (określające w jakiej sytuacji powinien być wysłany) jak również związana jest z nim pewna domyślna akcja jaką system wykonuje przy jego obsłudze. Oto opis znaczenia poszczególnych sygnałów według numeracji w systemie Linux.

Polecenie służy do wysyłania sygnałów do procesów.

Użycie: kill -SYGNAL PID, gdzie SYGNAL to numer albo nazwa sygnału.

Polecenie służy do wysyłania sygnałów do wielu procesów o tej samej nazwie.

Sprawdź jaki procesor znajduje się w komputerze w laboratorium oraz na serwerze wierzba. Zauważ, że dodatkowe rdzenie procesorów są reprezentowane jako kolejne procesory na liście.

Sprawdź ile pamięci RAM dysponuje komputer w laboratorium i serwer wierzba. Wartości podaj w MB oraz w GB dokonując odpowiednich przeliczeń.

Sprawdź jakie procesy zostały uruchomione w bieżącej sesji shella.

Sprawdź jakie procesy zostały uruchomione w całym systemie.

Sprawdź jakie procesy zostały uruchomione przez twojego użytkownika.

Uruchom polecenie top i posortuj listę procesów po ilości czasu procesora (TIME), po obciążeniu procesora (%CPU), po zajętej pamięci (%MEM). Znajdź proces, który najbardziej obciąża procesor oraz proces który najbardziej obciąża pamięć. W tym celu możesz uruchomić dowolne programy na komputerze w laboratorium.

Utwórz prosty skrypt, którym będziesz testować działanie programów zarządzających procesami. W tym celu otwórz ulubiony edytor tekstu i przepisz poniższy kod:

Skrypt zapisz pod nazwą spioch.sh. Nadaj uprawnienia temu plikowi w taki sposób aby można było go uruchomić jako zalogowany użytkownik w systemie (dodaj uprawnienia executable).

Będąc w tym samym katalogu co plik spioch.sh spróbuj uruchomić skrypt w następujący sposób: ./spioch.sh 3

Skrypt powinien zasnąć na 3 sekundy, a następnie powinien pojawić się napis Pobudka. Koniec.

Uruchom skrypt na wiele sekund (np. 300). Postaraj się zakończyć go przed czasem wciskając kombinację Ctrl+C. Jaki sygnał został wysłany do procesu? Czy napis Pobudka. Koniec. wyświetlił się na ekranie?

Uruchom ponownie skrypt na wiele sekund. Otwórz nową kartę terminala. Postaraj się odnaleźć go za pomocą komendy ps oraz top. Odnajdź PID tego procesu.

Znając numer PID procesu z uruchomionym skryptem śpiocha, spróbuj w osobnej karcie terminala wysłać do niego sygnały: SIGINT, SIGTERM, SIGQUIT, SIGKILL. Za każdym razem sprawdź co się stało z procesem śpiocha. Jeśli trzeba uruchom go ponownie.

Przy użyciu maszyny wirtualnej (VirtualBox) spróbuj uruchomić proces jako jeden użytkownik, a następnie zabić go jako inny użytkownik. Czy to możliwe? Próbę ponów jako użytkownik root.