1. [1p.] Napisz skrypt, który w pętli będzie coś robił (np. co sekundę wypisywał bieżącą godzinę). Uruchom go i sprawdź wysyłanie do tego procesu różnych sygnałów (SIGINT, SIGQUIT, ale także SIGFPE, SIGILL), a następnie rozbuduj skrypt o przechwytywanie tych sygnałów (trap) i sprawdź, że to działa, to znaczy, że tak napisanego procesu nie da się zabić tymi sygnałami. Sprawdź możliwość uśmiercenia sygnałem SIGKILL procesu, który przechwytuje wszystkie 15 sygnałów. W raporcie potwierdź tylko wykonanie tego punktu.

    Wskazówka: obsługę sygnałów przez proces interpretera poleceń deklaruje się wbudowanym poleceniem trap. Gdzie szukać opisu poleceń wbudowanych interpretera ..... man bash !

    Uwaga: bash wywołany jako sh wymaga zastosowania restrykcyjnej formy polecenia trap.

  2. [1p.] Sprawdź możliwość zawieszania procesu sygnałem SIGSTOP i wznawiania sygnałem SIGCONT. Sprawdź, że sygnał SIGSTOP daje taki sam efekt jak naciśnięcie klawisza Ctrl+Z na terminalu. Sprawdź, że sygnał SIGCONT daje taki sam efekt jak wykonanie polecenia fg lub bg (którego bardziej?).

  3. [1p.] Uruchom kilka podprocesów shella i wysyłaj po kolei sygnały (1-15) do grupy procesów tego shella. Sprawdź reakcję na te sygnały zarówno podprocesów, jak i samego shella. Które sygnały shell ignoruje, a które powodują reakcję domyślną?

  4. [1p.] Nie korzystając z dobrodziejstw oferowanych przez ulimit, napisz skrypt A, który przyjmie 3 parametry: nazwę programu (lub skryptu) B do uruchomienia i dwie liczby naturalne x i y, a następnie uruchomi zadany program. Jeśli program B będzie jeszcze działać po x sekundach (można to sprawdzać np. co sekundę poleceniem ps z odpowiednimi parametrami), to należy spróbować go zabić, wysyłając mu sygnał SIGTERM. Jeśli program będzie działać nadal po y sekundach, to należy go zabić sygnałem SIGKILL.

    Następnie wypróbuj działanie powyższego skryptu, pisząc dwa skrypty do uruchomienia - jeden, który daje się zabić przez SIGTERM i drugi, który na to nie pozwala.

    Wklej opracowany skrypt do raportu z wykonania zadania.

  5. [1p.] Napisz wywołania programu ps wyświetlające następujące informacje:
    - numer procesu rodzica bieżącego procesu (tego który wywołał ps)
    - numery procesów grupy procesów bieżącego procesu

    Wpisz je do raportu.

  6. [1p.] Napisz skrypt, który wyświetli na wyjściu numery wszystkich procesów posiadających tego samego rodzica, co proces o zadanym numerze (argument skryptu). Wywołanie bez argumentów oznacza wzięcie procesu samego skryptu (czyli skrypt powinien wyświetlić swoje rodzeństwo).

    Wklej opracowane wyrażenie lub skrypt do raportu z wykonania zadania.

  7. [1p.] Napisz skrypt A, który uruchomi skrypt potomny B, który zabije proces swojego rodzica (A). Sprawdź (np. poleceniem pstree), czy osierocony proces zostanie poprawnie adoptowany przez proces init.

    Wynik podaj w raporcie.

  8. [1p.] Obmyśl jak wyprodukować proces zombie, wykonaj to, i sprawdź jak pojawia się on na liście procesów ps (Linux, Solaris). Wyjaśnij jak działa Twój przepis na zombie. Następnie spróbuj go zabić, i opisz wynik.

    Wklej opracowany skrypt do raportu z wykonania zadania, lub napisz co się nie udało.

    Uwaga: interpreter poleceń bash uniemożliwia powstawanie procesów zombie. Taki proces może powstać tylko wtedy, gdy jego rodzicem nie będzie bash. Ale jak bash może nie być rodzicem procesu, skoro był potrzebny do jego stworzenia ...

    Uwaga2: jak znaleźć proces zombie? Na systemie Linux proces zombie ma nadal ten sam terminal, na którym proces był oryginalnie uruchomiony. Na systemie Solaris proces zombie jest odłączony od wszystkich terminali.

  9. [1p.] Zapoznaj się z poleceniem ulimit. Ustaw limit liczby procesów użytkownika w taki sposób, żeby możliwe było uruchomienie jeszcze tylko dodatkowo 10-15 procesów. Następnie spróbuj po kolei ustawiać limity innych zasobów tak, aby były minimalne, ale żeby dało się dalej pracować w edytorze, i uruchamiać pojedyncze małe skrypty.

    Podaj w raporcie wszystkie ustawione limity zasobów.

  10. [1p.] Uruchom jakieś zadanie zajmujące maksimum procesora. Sprawdź wartość jego priorytetu i liczby nice, a następnie przećwicz obniżanie priorytetu pracującego w tle procesu (renice). Sprawdź, że liczba nice została skutecznie zmodyfikowana.

    W raporcie podaj uzyskany wynik, jak również zastosowane polecenie renice.

  11. [zadanie dodatkowe - opcjonalne]
    UWAGA: nie wykonuj tego punktu na żadnym z komputerów wielodostępnych w Instytucie Informatyki. Wykonaj go na lokalnej stacji roboczej, wcześniej upewniwszy się, że w razie potrzeby będzie można ją bez szkody resetować. A najlepiej wykonaj ten punkt na własnym komputerze domowym :-).

    Napisz skrypt, który w nieskończonej pętli uruchamia kolejne kopie samego siebie w tle (zwany czasami forkbombą). Uruchom skrypt. Następnie spróbuj opanować sytuację, czyli pozabijać wszystkie utworzone procesy i powrócić do normalnej pracy. Jeśli Ci się to udało, to jeszcze raz uruchom skrypt, a następnie wyloguj się kompletnie z komputera. Spróbuj zalogować się ponownie. Jeśli i to Ci się uda, to nie napisałeś/aś poprawnie skryptu. Przeanalizuj skrypt i postaraj się go poprawić.

    W trakcie wykonywania kolejnych ćwiczeń zwracaj uwagę na takie pisanie skryptów, aby nie doprowadzić do zatkania systemu ani zapełnienia dysku. W szczególności naucz się stosować takie elementy jak: weywołania sleep dla wprowadzania opóźnień, respektowanie sygnałów, ograniczenia zasobów, i priorytety, aby uruchamiać swoje zadania w sposób ułatwiający łatwe ich kontrolowanie i zmniejszający obciążenie systemu.

    Wklej opracowany skrypt do raportu z wykonania zadania.
    Opisz również wynik walki z jego uruchomioną instancją.