Kolejność uruchamiania usług

Kolejność uruchamiania usług to sekwencja startu komponentów serwera, wynikająca z zależności między nimi.

Zależności wyznaczające kolejność startu

Kolejność uruchamiania usług na serwerze jest ustalana na podstawie zależności między procesami, a nie wyłącznie według kolejności wpisów na liście. Usługa może wymagać działającej sieci, zamontowanego systemu plików, dostępnego urządzenia blokowego, uruchomionej bazy danych albo poprawnie rozwiązanej nazwy DNS. Jeżeli komponent nadrzędny nie jest gotowy, usługa zależna może zakończyć start błędem, przejść w stan oczekiwania albo zostać uruchomiona ponownie przez menedżera usług.

W systemach Linux korzystających z systemd zależności są opisywane między innymi dyrektywami Requires=, Wants=, After= i Before=. Requires= określa zależność wymaganą, natomiast Wants= wskazuje zależność słabszą, której niepowodzenie nie zawsze zatrzymuje usługę główną. Dyrektywy After= i Before= określają relację czasową, ale same nie powodują uruchomienia wskazanego komponentu. Do utworzenia pełnej zależności potrzebne jest więc połączenie relacji uruchamiania z relacją kolejności.

Graf zależności zamiast sztywnej listy procesów

Menedżer usług buduje z zależności graf, w którym węzłami są jednostki systemowe, a krawędzie opisują wymagania i kolejność. Dzięki temu niezależne usługi mogą startować równolegle, co skraca czas uruchamiania serwera. Przykładowo proces obsługujący lokalny monitoring nie musi czekać na usługę aplikacyjną, jeżeli nie korzysta z jej gniazda, plików ani interfejsu administracyjnego. Równoległość jest bezpieczna tylko wtedy, gdy deklaracje zależności odpowiadają rzeczywistemu przepływowi danych.

Ważna jest różnica między rozpoczęciem procesu a gotowością usługi do pracy. Proces może otrzymać identyfikator i nie zakończyć się błędem, ale nadal wykonywać inicjalizację tabel, otwieranie portu, ładowanie konfiguracji lub odtwarzanie dziennika transakcji. Dlatego sama zależność typu „uruchom po” nie zawsze wystarcza. Systemd rozróżnia między innymi typy simple, exec, forking, notify i oneshot; wybór typu wpływa na sposób rozpoznawania momentu rozpoczęcia oraz zakończenia fazy startowej. Przy usługach korzystających z protokołu powiadomień gotowość może być zgłaszana dopiero po zakończeniu inicjalizacji.

Opóźnienia, ponowienia i stany awaryjne

Błąd kolejności często ujawnia się jako chwilowa niedostępność, a nie jako trwała awaria. Usługa aplikacyjna może wystartować przed bazą danych, wykonać kilka nieudanych prób połączenia, a następnie zakończyć pracę. Jeżeli skonfigurowano Restart=on-failure lub Restart=always, menedżer usług podejmie kolejne próby zgodnie z ustawieniem RestartSec=. Taki mechanizm pomaga przy krótkotrwałych opóźnieniach, ale nie naprawia błędnej zależności. Przy każdym restarcie mogą powstawać dodatkowe wpisy w logach, blokady plików lub częściowo utworzone pliki tymczasowe.

Do analizy kolejności w systemd służą między innymi polecenia systemctl list-dependencies nazwa-usługi.service, systemctl status nazwa-usługi.service oraz journalctl -b -u nazwa-usługi.service. Pierwsze pokazuje zależności jednostki, drugie jej bieżący stan i ostatnie komunikaty, a trzecie pozwala prześledzić zdarzenia z konkretnego uruchomienia systemu. Polecenie systemd-analyze critical-chain wskazuje łańcuch jednostek wpływających na czas osiągnięcia stanu docelowego. Podczas diagnostyki trzeba sprawdzić znaczniki czasu, kod zakończenia procesu, moment otwarcia portu oraz faktyczną dostępność zasobu, od którego zależy kolejna usługa.

Praktyczne sprawdzenie sekwencji po restarcie serwera

Weryfikację należy rozpocząć od ustalenia, które usługi są wymagane przez aplikację i jakie zasoby udostępniają. Następnie warto porównać konfigurację jednostek z rzeczywistymi komunikatami w dzienniku systemowym. Jeżeli aplikacja używa gniazda TCP, trzeba sprawdzić nie tylko, czy proces zależny został uruchomiony, lecz także czy nasłuchuje na właściwym adresie i porcie. Jeżeli wymaga montowanego systemu plików, należy potwierdzić dostęp do konkretnej ścieżki po zakończeniu montowania, ponieważ samo rozpoczęcie operacji montowania nie oznacza jeszcze gotowości danych.

W przypadku nieprawidłowej kolejności poprawa powinna obejmować deklaracje zależności, warunek gotowości oraz sposób obsługi błędów. Pomocniczy skrypt opóźniający start nie zastępuje prawidłowej synchronizacji, ponieważ stały czas oczekiwania może być zbyt krótki podczas obciążenia albo niepotrzebnie wydłużać start w sprawnych warunkach. Po zmianie jednostki należy wykonać przeładowanie konfiguracji poleceniem systemctl daemon-reload, uruchomić usługę testowo, a następnie sprawdzić zachowanie po pełnym restarcie systemu. Diagnostyka serwera powinna obejmować również zależności cykliczne, brakujące jednostki, nieudane montaże, niedostępne interfejsy sieciowe i przekroczony limit prób ponownego uruchamiania.