Usługi systemowe w Linuksie — systemctl i dziennik zdarzeń na przykładowych wynikach

Serwer WWW, zdalny dostęp przez SSH, drukowanie — to wszystko są usługi (demony), czyli programy działające w tle. W większości dystrybucji, także w Ubuntu, zarządza nimi system systemd i polecenie systemctl. Gdy coś nie działa, pierwszym krokiem jest sprawdzenie stanu usługi, a drugim — przeczytanie dziennika zdarzeń. Na lekcji uczniowie analizują przykładowe wyniki takich poleceń, nie zmieniając ustawień prawdziwego systemu.

Scenariusz jest przeznaczony na 45 minut dla klasy znającej potoki, grep i awk — na przykład po lekcji o użytkownikach i grupach. Wyniki w skrypcie są uproszczonymi przykładami (nazwy usług, daty i adresy są przykładowe, a dokładny wygląd zależy od wersji systemu). Polecenia, które zmieniają stan usług (start, stop, enable), wymagają sudo i wolno je wypróbować wyłącznie w maszynie wirtualnej pod opieką nauczyciela.

Przygotowanie stanowisk

Potrzebny jest terminal z powłoką bash (Ubuntu, WSL lub maszyna wirtualna). Ćwiczenia wykonuj na zwykłym koncie, bez sudo. Skrypt rozwiazanie.sh z pakietu odtwarza całą lekcję w katalogu tymczasowym (mktemp -d) i usuwa tylko ten katalog — nie zmienia Twoich plików; uruchamiasz go poleceniem bash rozwiazanie.sh. Ćwiczenia z karty pracy wykonaj ręcznie w terminalu, w osobnym katalogu ćwiczeniowym.

Cele i plan lekcji

Po zajęciach uczeń potrafi:

odczytać z wyniku systemctl status stan usługi, numer procesu głównego i informację o włączeniu przy starcie;
znaleźć w liście usług te, które nie działają (failed, inactive);
przeszukać dziennik zdarzeń pod kątem błędów i nieudanych logowań;
opisać znaczenie poleceń start, stop, restart, enable, disable i journalctl.

Czas	Praca na lekcji
0–5 min	Problem: usługa nie odpowiada — co sprawdzić najpierw?
5–15 min	`systemd`, `systemctl`, dziennik
15–22 min	Czytanie wyników i filtrowanie `awk`/`grep`
22–37 min	Trzy zadania
37–42 min	Plan reakcji na usługę w stanie `failed`
42–45 min	Pytania kontrolne

Polecenia do zarządzania usługami

Polecenie	Działanie
`systemctl status ssh`	stan usługi i kilka ostatnich wpisów z dziennika
`sudo systemctl start ssh` / `stop` / `restart`	uruchom / zatrzymaj / uruchom ponownie
`sudo systemctl enable ssh` / `disable`	włącz / wyłącz automatyczny start przy uruchomieniu systemu
`systemctl list-units --type=service`	lista usług i ich stanów
`journalctl -u ssh`	dziennik zdarzeń konkretnej usługi
`journalctl -p err`	tylko wpisy o poziomie „błąd” i wyższym

Zmiana stanu usługi wymaga uprawnień administratora (sudo). Uruchomienie (start) działa teraz, włączenie (enable) wpływa na następne uruchomienia systemu — to dwie różne rzeczy.

Czytanie wyniku `status`

Wiersz Loaded: mówi, czy plik usługi został wczytany i czy jest włączona przy starcie (enabled). Wiersz Active: pokazuje stan: active (running) — działa; inactive (dead) — nie działa; failed — próba uruchomienia zakończyła się błędem. Main PID to numer głównego procesu usługi.

Dziennik zdarzeń

Dziennik zawiera wpisy z czasem, nazwą komputera, nazwą programu (z numerem procesu) i komunikatem. Wiele nieudanych logowań w krótkim czasie z jednego adresu może oznaczać próbę odgadnięcia hasła — w przykładzie dwie nieudane próby poprzedzają udane logowanie użytkownika ola, co może być zwykłą pomyłką. Wpis apache2.service: Failed with result 'exit-code' wraz z poprzednim wierszem o błędzie składni w konfiguracji tłumaczy, dlaczego usługa jest w stanie failed.

Zadania

Zadanie 1. Status. Z pliku status.txt odczytaj stan usługi, numer procesu głównego i liczbę wierszy zawierających słowo enabled.

Zadanie 2. Lista usług. Z uslugi.txt wypisz usługi w stanie failed, policz działające (running) i wypisz nieaktywne (inactive).

Zadanie 3. Dziennik. Policz nieudane logowania, policz je dla każdego użytkownika, znajdź godzinę pierwszej awarii, policz udane logowania i wypisz usługę, która zakończyła się błędem.

Dla chętnych: w maszynie wirtualnej sprawdź systemctl status dla dwóch usług i opisz różnice w polach Loaded i Active.

Rozwiązanie i wyniki

set -e
TMP=$(mktemp -d)
cd "$TMP"
cat > status.txt <<'DANE'
ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; preset: enabled)
     Active: active (running) since Mon 2028-03-27 08:15:02 CET; 2h 10min ago
   Main PID: 812 (sshd)
DANE
cat > uslugi.txt <<'DANE'
ssh.service     loaded active   running OpenBSD Secure Shell server
cron.service    loaded active   running Regular background program processing daemon
apache2.service loaded failed   failed  The Apache HTTP Server
cups.service    loaded inactive dead    CUPS Scheduler
DANE
cat > dziennik.txt <<'DANE'
mar 27 08:15:02 ubuntu systemd[1]: Started ssh.service.
mar 27 08:20:11 ubuntu sshd[812]: Failed password for ola from 192.168.56.5
mar 27 08:20:15 ubuntu sshd[812]: Failed password for ola from 192.168.56.5
mar 27 08:21:03 ubuntu sshd[812]: Accepted password for ola from 192.168.56.5
mar 27 09:02:44 ubuntu apache2[1210]: AH00526: Syntax error on line 12
mar 27 09:02:45 ubuntu systemd[1]: apache2.service: Failed with result 'exit-code'.
DANE

echo "--- Zadanie 1: status uslugi"
awk '/Active:/ {print $2}' status.txt
awk '/Main PID:/ {print $3}' status.txt
grep -c "enabled" status.txt

echo "--- Zadanie 2: lista uslug"
awk '$3 == "failed" {print $1}' uslugi.txt
awk '$4 == "running"' uslugi.txt | wc -l
awk '$3 == "inactive" {print $1}' uslugi.txt

echo "--- Zadanie 3: dziennik"
grep -c "Failed password" dziennik.txt
awk '/Failed password/ {n[$9]++} END {for (u in n) print u, n[u]}' dziennik.txt
grep -m1 "Failed" dziennik.txt | awk '{print $3}'
grep -c "Accepted password" dziennik.txt
awk '/Failed with result/ {print $6}' dziennik.txt

cd /
rm -r "$TMP"

Skrypt rozwiazanie.sh z pakietu wykonuje te polecenia w katalogu tymczasowym i wypisuje:

--- Zadanie 1: status uslugi
active
812
1
--- Zadanie 2: lista uslug
apache2.service
2
cups.service
--- Zadanie 3: dziennik
2
ola 2
08:20:11
1
apache2.service:

Typowe błędy

Objaw	Co sprawdzić
`Failed to connect to bus` lub brak uprawnień	Zmiana stanu usługi wymaga `sudo`.
Usługa działa, ale nie startuje po restarcie komputera	Uruchomiono ją (`start`), ale nie włączono (`enable`).
Pomylenie `inactive` z `failed`	`inactive` to usługa zatrzymana, `failed` — zakończona błędem.
Wynik dziennika bez filtra jest za długi	Użyj `journalctl -u nazwa` lub `-p err`.
Ignorowanie wpisu przed błędem	Przyczyna jest często w poprzednim wierszu dziennika.
Zatrzymanie usługi na komputerze szkolnym	Ćwiczenia ze zmianą stanu tylko w maszynie wirtualnej.

Pytania kontrolne i punktacja

Czym różni się start od enable?
Co oznacza stan failed?
Gdzie szukasz przyczyny awarii usługi?

Odpowiedzi: start uruchamia usługę teraz, enable sprawia, że będzie uruchamiana przy każdym starcie systemu. Że próba uruchomienia usługi zakończyła się błędem. W dzienniku zdarzeń (journalctl -u nazwa), zwłaszcza we wpisach tuż przed błędem.

Proponowana punktacja (razem 10 punktów): zadanie 1 — stan, PID i enabled po 1 pkt; zadanie 2 — trzy zapytania po 1 pkt; zadanie 3 — trzy pierwsze zapytania 2 pkt, dwa ostatnie 1 pkt; start a enable w pytaniach 1 pkt. Zadanie dla chętnych nie jest wymagane do pełnej oceny.

Materiały do pobrania

Rozpakuj ZIP przed otwarciem plików. Materiały są dostępne bez logowania; publiczne rozwiązanie służy nauce i samodzielnemu sprawdzeniu, a nie poufnemu sprawdzianowi.

Co dalej?

Następny krok to harmonogram zadań (cron), zdalny dostęp przez SSH i zapora sieciowa. Ten materiał rozwija dział o administrowaniu systemem w kursie Linux w TablicaPro, gdzie znajdziesz prezentacje, ćwiczenia i testy do prowadzenia lekcji.

Źródła techniczne: dokumentacja systemctl oraz journalctl. Zobacz też lekcję o użytkownikach i grupach.

Poprowadź kolejne lekcje Linux

Pełny kurs: prezentacje, ćwiczenia i testy do pracy z klasą.

Kup dostęp do kursu Linux →

Zobacz program kursu