init.d

init.d to katalog w systemach Linux przechowujący skrypty startowe usług — dotyczy WSL i dystrybucji korzystających ze starszego systemu inicjalizacji SysV.

init.d – czym jest i do czego służy

init.d to tradycyjny mechanizm uruchamiania i zatrzymywania usług w systemach Linux. Nazwa odnosi się przede wszystkim do katalogu, w którym umieszczane są skrypty odpowiedzialne za obsługę procesów działających w tle. Taki skrypt może definiować czynności wykonywane podczas startu systemu, zatrzymywania systemu, ponownego uruchamiania konkretnej usługi albo sprawdzania jej bieżącego stanu.

Skrypty znajdujące się zwykle w /etc/init.d/ korzystają z konwencji znanej z systemu inicjalizacji SysV. Najczęściej przyjmują argumenty takie jak start, stop, restart i status. Dzięki temu można było obsługiwać różne usługi według podobnego schematu, niezależnie od tego, czy chodziło o proces sieciowy, usługę systemową, zadanie pomocnicze czy program uruchamiany automatycznie po starcie systemu.

Znaczenie init.d nie ogranicza się do samego katalogu. Ważne są również reguły określające kolejność uruchamiania skryptów, zależności między usługami oraz moment wykonywania poszczególnych operacji. W klasycznym modelu wykorzystywano do tego między innymi poziomy pracy systemu, zwane runlevelami. Współczesne dystrybucje mogą zachowywać skrypty zgodne z tym mechanizmem dla kompatybilności, nawet jeśli podstawowym systemem inicjalizacji jest już inne rozwiązanie.

W środowisku WSL obecność katalogu init.d nie musi oznaczać, że wszystkie klasyczne usługi Linuxa działają dokładnie tak jak na osobnej instalacji systemu. Wiele zależy od wersji WSL, używanej dystrybucji oraz sposobu uruchamiania procesów. W szczególności należy odróżnić zwykłe uruchomienie powłoki od pełnego startu systemowego z aktywnym mechanizmem inicjalizacji.

Kontekst techniczny i porównanie z nowszymi mechanizmami

Najważniejszym współczesnym punktem odniesienia dla init.d jest systemd. W modelu SysV pojedynczy skrypt powłoki wykonywał określone działania, a kolejność pracy była ustalana za pomocą nazw, dowiązań i poziomów uruchomieniowych. systemd posługuje się natomiast jednostkami usługowymi, zwykle zapisanymi jako pliki .service, oraz osobnym mechanizmem zależności, warunków uruchomienia i nadzorowania procesu.

Różnica jest widoczna także w sposobie diagnozowania. Przy klasycznym skrypcie analizuje się jego treść, kod zakończenia oraz komunikaty powłoki. Przy systemd sprawdza się między innymi stan jednostki, dziennik zdarzeń, zależności i parametry uruchomienia. W praktyce jedna usługa może mieć zarówno dawny skrypt w /etc/init.d/, jak i współczesną jednostkę zarządzającą tym skryptem przez warstwę kompatybilności.

W systemach korzystających z SysV znaczenie mają katalogi powiązane z poziomami pracy, na przykład /etc/rc.d/ lub katalogi rc*.d. Umieszczone tam dowiązania wskazują, które skrypty mają zostać uruchomione oraz w jakiej kolejności. Litery i liczby występujące w nazwach pozwalają ustalić, czy dana operacja ma zostać wykonana przed inną. Taki model jest czytelny po poznaniu konwencji, ale mniej elastyczny przy złożonych zależnościach i usługach wymagających precyzyjnego nadzoru.

W WSL należy dodatkowo sprawdzić, czy używana konfiguracja zapewnia pełną obsługę systemd. Bez niej wpisanie polecenia kojarzonego z klasycznym startem usługi może nie dać oczekiwanego rezultatu, a skrypt w init.d może być uruchamiany ręcznie lub przez inny proces. Sama nazwa katalogu nie przesądza więc o tym, jaki mechanizm faktycznie kontroluje dany program.

Typowe problemy, błędy i objawy nieprawidłowego działania - init.d

Jednym z częstszych problemów jest brak prawa wykonywania skryptu. Plik może istnieć, ale próba uruchomienia zakończy się błędem uprawnień albo nie wykona żadnej operacji wymagającej dostępu administracyjnego. Konieczne bywa wtedy sprawdzenie właściciela, trybu pliku oraz sposobu wywołania. Należy zachować ostrożność, ponieważ zmiany w skryptach startowych mogą wpływać na zachowanie całego środowiska.

Inny błąd wynika z niezgodności skryptu ze środowiskiem. Skrypt przygotowany dla pełnej instalacji Linuxa może zakładać obecność określonych katalogów, urządzeń, zmiennych środowiskowych albo narzędzi, których nie ma w danej dystrybucji lub w WSL. W takim przypadku proces może uruchamiać się częściowo, kończyć z błędem albo pozostawiać niepełną konfigurację po restarcie.

Problemy mogą powodować również nieaktualne ścieżki, brak wymaganych zależności, błędna składnia powłoki oraz nieprawidłowe wartości w plikach konfiguracyjnych. Objawem bywa usługa, która działa po ręcznym uruchomieniu, lecz nie startuje automatycznie. Czasem sytuacja wygląda odwrotnie: proces pojawia się po uruchomieniu systemu, ale nie reaguje poprawnie na stop lub restart.

Ważną wskazówką diagnostyczną są komunikaty zwracane bezpośrednio przez skrypt oraz wpisy w dziennikach systemowych. Przy analizie należy ustalić, czy problem dotyczy samego programu, mechanizmu inicjalizacji, uprawnień, kolejności uruchamiania, połączenia sieciowego czy konfiguracji środowiska. Bez takiego rozróżnienia łatwo poprawić niewłaściwy element i uzyskać tylko pozorną naprawę.

Nie powinno się także bezrefleksyjnie kopiować skryptów z innych dystrybucji. Różnice w nazwach usług, układzie katalogów, wersjach interpreterów i sposobie zarządzania procesami mogą sprawić, że pozornie poprawny plik wywoła błędy podczas startu. Bezpieczniej jest najpierw wykonać kopię konfiguracji, odczytać zawartość skryptu i sprawdzić zależności, a dopiero później wprowadzać zmianę.

Kiedy warto przekazać urządzenie do naprawy - init.d

Pomoc serwisowa jest uzasadniona, gdy środowisko Linux lub WSL przestało uruchamiać wymagane usługi, system zgłasza błędy podczas startu albo ręczne działania w init.d powodują nieprzewidywalne skutki. Dotyczy to zwłaszcza sytuacji, w której nie wiadomo, czy przyczyną jest uszkodzony skrypt, nieprawidłowa konfiguracja, brak uprawnień, niezgodność wersji czy różnica między SysV a systemd.

Przed przekazaniem urządzenia warto zanotować dokładny komunikat błędu, nazwę dystrybucji, sposób uruchamiania WSL oraz czynności, po których wystąpiła awaria. Takie informacje ułatwiają odtworzenie problemu i ograniczają ryzyko zmiany ustawień niezwiązanych z usterką. W przypadku laptopa w Warszawie działa serwis komputerowy oferujący darmową diagnozę LAPTOPA, co pozwala najpierw ustalić źródło problemu, a dopiero potem dobrać zakres prac.

Do konsultacji warto zgłosić się również wtedy, gdy system uruchamia się poprawnie, lecz wybrana usługa nie startuje automatycznie, znika po ponownym uruchomieniu albo wymaga każdorazowego ręcznego wywołania. Prawidłowa analiza obejmuje wtedy nie tylko katalog init.d, lecz także jednostki systemowe, skrypty powłoki, logi, uprawnienia i zależności między procesami. Dzięki temu można rozstrzygnąć, czy należy naprawić istniejący mechanizm, dostosować konfigurację, czy zastąpić przestarzały sposób uruchamiania rozwiązaniem właściwym dla danej dystrybucji.