Usługa Linuksa nie startuje. Znajdź pierwszy błąd i właściwą poprawkę

Komunikat „usługa nie wystartowała” opisuje rezultat, a nie przyczynę. Program mógł odrzucić konfigurację, nie dostać dostępu do pliku albo zakończyć się przed wykonaniem właściwego zadania. Zacznij od pierwszego istotnego błędu z konkretnej próby uruchomienia.

Ten poradnik dotyczy usług zarządzanych przez systemd. W poleceniach używam przykładowej nazwy moja-usluga.service; zastąp ją właściwą jednostką. Dla usług użytkownika potrzebny jest zakres --user, a dla czynności administracyjnych odpowiednie uprawnienia.

Odczytaj stan i komunikaty tej samej próby

systemctl status moja-usluga.service --no-pager
journalctl -b -u moja-usluga.service --since "-15 min" --no-pager

Sprawdź, czy jednostka istnieje, jest załadowana i czy zakończyła się błędem. Stan disabled dotyczy powiązania z automatycznym uruchamianiem, nie dowodzi awarii procesu. Usługa jednorazowa może poprawnie wykonać zadanie i później pozostać nieaktywna.

Zwróć uwagę na czas i kolejność. Kilka prób w krótkim odstępie może dawać podobne końcowe wpisy. Nie łącz komunikatu parsera z poprzedniej konfiguracji z kodem zakończenia późniejszej próby. Jeśli potrzebujesz węższego przedziału, skorzystaj z filtrowania journalctl.

Program nie został wykonany czy sam zgłosił błąd?

Kod 203/EXEC wskazuje problem wykonania procesu przez systemd. Sprawdź ścieżkę pliku wykonywalnego, jego dostępność i możliwość uruchomienia. Przy skrypcie znaczenie ma również właściwy interpreter. Nie zakładaj, że każda taka sytuacja wynika z braku jednego prawa dostępu.

Kod 200/CHDIR kieruje do katalogu roboczego, a 217/USER do ustalenia lub zastosowania danych użytkownika i powiązanych warunków wykonania. To punkty orientacyjne, które trzeba połączyć z treścią wpisów, nie gotowa instrukcja zmiany właściciela wszystkich plików.

Gdy proces rzeczywiście się uruchomił i zwrócił własny błąd, szukaj komunikatu aplikacji: brakującej biblioteki, nieprawidłowego parametru, błędu składni albo odmowy dostępu. Zapis „status=1” bez tej treści zwykle nie wystarcza. Nie każdy program zapisuje szczegóły do journala; sprawdź także jego własny log.

Przeczytaj jednostkę wraz z nadpisaniami

systemctl cat moja-usluga.service

Odczyt obejmuje plik jednostki i dodatkowe fragmenty konfiguracji. Sprawdź polecenie startowe, użytkownika, katalog roboczy oraz pliki środowiska. Lokalna modyfikacja może zmienić ustawienie z pakietu, dlatego samo otwarcie pliku producenta nie zawsze pokaże warunki próby.

Program uruchamiany ręcznie z terminala może mieć inne środowisko niż usługa. Dotyczy to katalogu, zmiennych, dostępu do plików i sposobu przekazania argumentów. Nie przenoś bezpośrednio składni powłoki do ExecStart, zakładając, że każda operacja z przekierowaniem lub potokiem będzie interpretowana identycznie.

Przy błędzie dostępu sprawdź wskazany plik oraz katalogi prowadzące do niego. Uwzględnij użytkownika usługi i jej ograniczenia wykonania. Nie stosuj chmod 777 dla całego drzewa i nie zmieniaj usługi na root jako uniwersalnej naprawy. Poprawka powinna wynikać z rzeczywistego wymagania.

Błąd konfiguracji: sprawdź wskazany plik

Jeżeli log podaje linię konfiguracji, przygotuj kopię i porównaj ostatnią zmianę. Sprawdź również pliki dołączane przez główny plik. Komunikat może dotyczyć parametru, którego zmodyfikowanej wersji nie obsługuje obecne wydanie programu.

Użyj własnego testu składni aplikacji, jeśli producent go udostępnia. Przykładowo Nginx ma nginx -t, sprawdzające konfigurację i możliwość otwarcia wskazanych plików. Dobierz polecenie oraz wymagane uprawnienia do swojej instalacji. Poprawny test składni nie gwarantuje jeszcze dostępności wszystkich zewnętrznych zależności.

Jeśli zmieniałeś plik jednostki ręcznie, systemd musi ponownie odczytać jego konfigurację przez daemon-reload. To inna czynność niż reload konkretnej aplikacji. Ponowne odczytanie definicji nie oznacza automatycznego restartu ani naprawy błędnej treści.

Port, zależność i zbyt wiele prób startu

Przy komunikacie o zajętym adresie sprawdź, który proces nasłuchuje i na jakim interfejsie. Do odczytu gniazd TCP służy między innymi ss -ltnp; widoczność informacji o procesach zależy od uprawnień. Nie kończ znalezionego procesu, dopóki nie ustalisz jego zadania.

Komunikat o zależności wymaga odczytania stanu wskazanej jednostki. Samo dodanie opóźnienia do startu nie wyjaśnia braku dysku, sieci lub usługi bazowej. Sprawdź również warunki jednostki, jeśli została pominięta, zamiast zakończona błędem procesu.

Po wielu nieudanych startach może zadziałać ograniczenie częstotliwości prób. Najpierw usuń pierwotną przyczynę. Ewentualny reset-failed pozwala wyczyścić stan błędu i związane liczniki, ale nie naprawia konfiguracji. Wyłączenie limitu bez diagnozy może tylko utrwalić pętlę awarii.

Naprawę potwierdź funkcją usługi

Po jednej uzasadnionej zmianie uruchom usługę w odpowiednim terminie, odczytaj świeży stan i log. Przy usłudze sieciowej sprawdź również właściwy adres i funkcję, a nie sam zielony status. Proces może działać, lecz nie obsługiwać oczekiwanego żądania.

Jeśli przyczyną był brak miejsca, przejdź do analizy zajętości dysku. Do dalszego zgłoszenia zachowaj nazwę jednostki, wersję aplikacji, pierwszy błąd i wykonaną zmianę. Taki materiał pozwala ocenić problem bez wielokrotnego uruchamiania usługi na ślepo.