systemd nie działa mimo aktywacji

systemd niedziałający mimo aktywacji wskazuje na błąd konfiguracji jednostki (unit) lub konflikt zależności w tym systemie inicjującym Linux.

systemd nie działa mimo aktywacji – czym jest ten objaw

Komunikat lub sytuacja opisywana jako „systemd nie działa mimo aktywacji” oznacza, że jednostka została włączona do uruchamiania, lecz w praktyce nie wystartowała poprawnie, zakończyła pracę albo nie osiągnęła stanu oczekiwanego przez system. W systemie Linux samo użycie polecenia aktywującego usługę nie jest równoznaczne z jej natychmiastowym uruchomieniem. Aktywacja zapisuje informację, że dana jednostka ma być włączana przy odpowiednim celu startowym, natomiast bieżący stan zależy od konfiguracji, warunków uruchomienia, uprawnień, dostępnych plików oraz relacji z innymi jednostkami.

Warto rozdzielić kilka podobnych pojęć. Jednostka może być włączona, czyli zaplanowana do uruchomienia podczas startu. Może być także uruchomiona w danej chwili, zatrzymana, nieaktywna, uszkodzona albo oznaczona jako zakończona błędem. Możliwe jest również wystąpienie sytuacji, w której usługa startuje, lecz po chwili kończy działanie, ponieważ wykonuje jednorazowe zadanie albo napotyka problem w programie uruchamianym przez systemd. Dlatego przy analizie nie należy ograniczać się do sprawdzenia jednej właściwości.

Systemd pełni funkcję menedżera uruchamiania i nadzorowania procesów. Odczytuje definicje jednostek, ustala kolejność wykonywania operacji, przygotowuje zależności i reaguje na błędy. Z tego powodu pozornie prosty problem może wynikać zarówno z literówki w pliku usługi, jak i z braku katalogu, nieprawidłowego użytkownika, niewłaściwej ścieżki programu lub konfliktu z inną jednostką.

systemd nie działa mimo aktywacji – kontekst techniczny i porównanie stanów

Najpierw należy ustalić, czy analizowana jednostka jest usługą systemową, usługą użytkownika, gniazdem, montowaniem zasobu, zadaniem wykonywanym jednorazowo czy innym typem obiektu. Różne rodzaje jednostek mają odmienne warunki działania. Usługa uruchamiana jako użytkownik może nie mieć dostępu do zmiennych środowiskowych dostępnych w powłoce interaktywnej. Usługa systemowa może natomiast działać z ograniczonymi uprawnieniami i widzieć inną ścieżkę plików niż osoba wykonująca test ręcznie.

Przydatne jest porównanie trzech informacji: stanu aktywacji, stanu bieżącego oraz przyczyny ostatniego niepowodzenia. Polecenie systemctl is-enabled nazwa.service pokazuje, czy jednostka została przewidziana do uruchamiania. Polecenie systemctl is-active nazwa.service wskazuje, czy działa teraz. Szczegółowy opis można uzyskać przez systemctl status nazwa.service, natomiast komunikaty z dziennika warto odczytać za pomocą journalctl -u nazwa.service. Nazwę jednostki należy zastąpić właściwą nazwą, bez przypadkowego pomijania rozszerzenia, jeśli jest wymagane.

Istotne jest także rozróżnienie aktywacji od uruchomienia. Po zmianie konfiguracji może być potrzebne przeładowanie definicji jednostek, a następnie osobne polecenie uruchamiające usługę. Jeżeli plik został zmieniony, a systemd nadal korzysta z wcześniejszej wersji, wynik testu może wprowadzać w błąd. W takiej sytuacji analizuje się między innymi wynik sprawdzenia składni, zależności oraz rzeczywistą lokalizację pliku jednostki.

Problemy z zależnościami często dotyczą warunków zapisanych w sekcjach odpowiedzialnych za kolejność, wymagania i uruchamianie po określonych celach. Jednostka może oczekiwać zamontowanego systemu plików, dostępnej sieci, konkretnego urządzenia albo innej usługi. Samo wskazanie zależności nie gwarantuje jednak, że wymagany element będzie poprawnie dostępny. Warto więc prześledzić pełny łańcuch uruchamiania, a nie tylko ostatni komunikat widoczny w statusie.

systemd nie działa mimo aktywacji – typowe problemy i komunikaty

Częstą przyczyną jest błędna ścieżka w polu ExecStart. Program może znajdować się w innym katalogu, mieć zmienioną nazwę albo nie posiadać prawa wykonywania. Równie częsty jest brak katalogu roboczego, pliku konfiguracyjnego lub podłączonego zasobu, który w czasie ręcznego testu był dostępny, ale podczas startu systemu jeszcze nie został przygotowany. W komunikatach dziennika mogą pojawić się informacje o nieistniejącym pliku, odmowie dostępu, nieznanym użytkowniku albo niepoprawnym argumencie.

Drugą grupę stanowią błędy uprawnień i użytkownika. Usługa uruchomiona przez określone konto nie korzysta automatycznie z uprawnień administratora ani z ustawień osoby, która uruchomiła polecenie w terminalu. Należy sprawdzić właścicieli plików, prawa dostępu do katalogów nadrzędnych, dostęp do urządzeń oraz możliwość zapisu w lokalizacji używanej przez program. W systemach z dodatkowymi mechanizmami kontroli dostępu przyczyną może być także reguła ograniczająca działanie procesu.

Jeżeli status wskazuje na pętlę restartów, przydatne jest ustalenie, dlaczego proces kończy się zaraz po uruchomieniu. Sam restart nie usuwa przyczyny, a przy wielu powtórzeniach może utrudniać odczytanie właściwego komunikatu. Pomocne bywa chwilowe uporządkowanie parametrów nadzoru, lecz zmiany powinny być wykonywane dopiero po zachowaniu kopii pliku jednostki i zrozumieniu skutków.

Może wystąpić również konflikt między nazwą usługi a inną definicją znajdującą się w katalogu z modyfikacjami lokalnymi. Wtedy sprawdza się, który plik jest faktycznie odczytywany, czy istnieją dowiązania oraz czy pochodzą one z pakietu systemowego, czy z ręcznej konfiguracji. Po każdej korekcie należy wykonać kontrolę składni, przeładować konfigurację i ponownie sprawdzić dziennik.

W przypadku usług sieciowych przyczyną może być niegotowe połączenie, niedostępny adres, zajęty port albo błędna nazwa interfejsu. Nie powinno się jednak zakładać, że sam komunikat o oczekiwaniu na sieć oznacza awarię sieci. Weryfikuje się kolejno stan interfejsu, rozwiązywanie nazw, dostępność wymaganego zasobu i zależności określone w jednostce.

systemd nie działa mimo aktywacji – praktyczne wskazówki diagnostyczne

Diagnostykę najlepiej prowadzić od informacji najmniej inwazyjnych. Najpierw zapisuje się dokładną nazwę jednostki i odczytuje jej status. Następnie sprawdza się ostatnie wpisy dziennika, wynik walidacji definicji oraz zależności uruchomieniowe. W razie potrzeby można wyświetlić zawartość jednostki wraz z późniejszymi modyfikacjami, aby upewnić się, że badany plik jest tym, który rzeczywiście wykorzystuje system.

Warto zwrócić uwagę na różnicę między konfiguracją główną a nadpisaniem ustawień. Drobna zmiana wykonana w niewłaściwym miejscu może nie przynieść żadnego efektu albo zostać zastąpiona przy aktualizacji pakietu. Bezpieczniejszym rozwiązaniem jest zachowanie kopii pierwotnej definicji i stosowanie jasno opisanej modyfikacji lokalnej. Każdą zmianę powinno się odnotować, aby można było wrócić do poprzedniego stanu i porównać zachowanie usługi.

Przydatny jest test uruchomienia z możliwie prostym środowiskiem oraz sprawdzenie, czy problem występuje wyłącznie po restarcie komputera, czy także przy ręcznym uruchamianiu. Jeżeli ręczne uruchomienie działa, a start automatyczny nie, należy porównać moment dostępności plików, montowań, sieci i zmiennych środowiskowych. Jeżeli nie działa również ręczne uruchomienie, większe znaczenie mają błędy programu, uprawnienia i ścieżki.

Nie powinno się usuwać plików jednostek ani wyłączać zabezpieczeń bez ustalenia przyczyny. Takie działania mogą ukryć objaw, przerwać inne procesy albo utrudnić późniejsze odtworzenie konfiguracji. Przydatne jest zachowanie fragmentu dziennika obejmującego moment uruchomienia, wersję systemu, nazwę jednostki i wykonane zmiany. Ułatwia to ocenę, czy problem powstał po aktualizacji, zmianie sprzętu, modyfikacji konfiguracji lub przywróceniu kopii.

systemd nie działa mimo aktywacji – kiedy zgłosić się do serwisu

Do serwisu warto zgłosić się wtedy, gdy jednostka nadal kończy pracę mimo poprawienia ścieżek i uprawnień, komunikaty dziennika są niejednoznaczne albo problem powraca po każdym restarcie. Pomocna będzie informacja, od kiedy występuje usterka, jakie zmiany wykonano przed jej pojawieniem się, czy system uruchamia się prawidłowo oraz czy inne usługi działają bez zakłóceń. Dobrze przygotowany opis skraca analizę, ponieważ pozwala od razu odtworzyć kolejność zdarzeń.

W Warszawie analizę takich problemów może przeprowadzić Warszawskie Pogotowie Komputerowe 24/7. W ramach diagnostyki sprawdza się stan systemu, definicje jednostek, logi, zależności, uprawnienia i wpływ ostatnich zmian, a następnie porządkuje konfigurację w sposób możliwy do późniejszego utrzymania. Jeżeli problem dotyczy również uruchamiania komputera, błędów nośnika, przegrzewania lub niestabilności sprzętu, analizuje się zależność między objawami systemowymi a stanem urządzenia.

Przed przekazaniem sprzętu nie powinno się kasować dzienników ani przywracać przypadkowych ustawień. Należy przygotować nazwę problematycznej jednostki, wynik poleceń statusu i najważniejsze wpisy dziennika, o ile nie zawierają danych poufnych. W przypadku systemu wykorzystywanego do pracy warto także wskazać, które funkcje muszą zostać zachowane po naprawie. Pozwala to odróżnić awarię samej usługi od błędu konfiguracji całego środowiska i ograniczyć zakres zmian do rzeczywiście potrzebnych elementów.