RC.local

RC.local to skrypt startowy w systemach Linux/Unix, wykonywany na końcu procesu rozruchu do uruchamiania niestandardowych poleceń.

RC.local – czym jest i gdzie występuje w systemie

RC.local jest elementem spotykanym przede wszystkim w tradycyjnych systemach Linux i Unix, w których proces uruchamiania opiera się na skryptach inicjalizacyjnych oraz poziomach pracy. Jego zadaniem jest wykonanie poleceń zdefiniowanych przez administratora po uruchomieniu podstawowych usług systemowych. Dzięki temu można dopisać własne działania startowe bez modyfikowania wielu plików odpowiedzialnych za podstawową inicjalizację systemu.

Nazwa pochodzi od połączenia oznaczenia katalogu lub mechanizmu skryptów uruchamianych przy starcie oraz słowa „local”, wskazującego na lokalne, ręcznie wprowadzone ustawienia. W zależności od dystrybucji oraz wersji systemu plik może znajdować się w innym miejscu, mieć odmienną składnię albo być jedynie zgodnością wsteczną dla starszych mechanizmów. Nie należy więc zakładać, że każdy system Linux będzie obsługiwał RC.local identycznie.

Najczęściej umieszcza się w nim krótkie polecenia wykonywane po przejściu systemu do określonego stanu pracy. Mogą one dotyczyć uruchomienia własnego programu, ustawienia parametru urządzenia, wykonania prostego skryptu konserwacyjnego albo przygotowania środowiska dla aplikacji, która nie ma własnej jednostki startowej. Polecenia są zwykle wykonywane z uprawnieniami administracyjnymi, dlatego każda zmiana wymaga ostrożności i sprawdzenia skutków po ponownym uruchomieniu.

RC.local na tle innych mechanizmów startowych

W starszych instalacjach RC.local pełnił funkcję prostego miejsca na polecenia dodawane poza standardową konfiguracją systemu. Jego zaletą była łatwość użycia: wystarczyło otworzyć jeden plik, dopisać komendy i nadać odpowiednie prawa wykonywania. Wadą pozostawał brak rozbudowanej kontroli nad kolejnością, zależnościami, ponawianiem działań oraz rejestrowaniem błędów.

W nowszych dystrybucjach coraz częściej stosuje się mechanizmy oparte na jednostkach usług, zadaniach uruchamianych przy starcie, timerach lub konfiguracji środowiska. Takie rozwiązania pozwalają wskazać zależności, ustalić warunki wykonania, określić użytkownika, pod którego konto ma działać proces, oraz łatwiej sprawdzać komunikaty diagnostyczne. RC.local może nadal działać, lecz bywa wyłączony domyślnie, wymaga utworzenia odpowiedniej usługi pośredniej albo jest dostępny wyłącznie jako element zgodności.

Różnica jest istotna także z punktu widzenia obsługi awarii. W prostym skrypcie kolejne polecenia mogą zostać wykonane mimo wcześniejszego błędu, chyba że zastosowano właściwe warunki i kontrolę kodów zakończenia. W bardziej uporządkowanym mechanizmie można zdefiniować, co ma się wydarzyć po nieudanym starcie, ile razy należy ponowić próbę oraz gdzie szukać informacji o problemie. Przy rozbudowanej konfiguracji wygodniejsze staje się rozdzielenie poszczególnych zadań zamiast umieszczania wszystkich komend w jednym pliku.

Nie oznacza to, że RC.local jest zawsze rozwiązaniem niewłaściwym. Dla pojedynczego, krótkiego polecenia, prostego komputera domowego lub starszego środowiska może być wystarczający. W przypadku systemu aktualizowanego przez wiele lat, zmienianego z jednej wersji na inną albo wykorzystywanego do ważnych zadań należy jednak sprawdzić, czy wybrany mechanizm nadal jest wspierany i czy jego działanie odpowiada obecnej architekturze systemu.

RC.local i typowe problemy z uruchamianiem poleceń

Jednym z częstszych problemów jest brak wykonania pliku mimo poprawnie zapisanej komendy. Przyczyną może być brak prawa wykonywania, nieprawidłowa pierwsza linia wskazująca interpreter, błędna ścieżka do programu albo brak końcowego zakończenia skryptu. W niektórych systemach wymagane jest również umieszczenie właściwego pliku w konkretnym katalogu lub włączenie usługi, która go wywołuje.

Problemy sprawia także środowisko, w którym skrypt jest wykonywany. Przy ręcznym uruchomieniu w terminalu dostępne mogą być zmienne środowiskowe, inna ścieżka wyszukiwania programów oraz katalog roboczy użytkownika. Podczas startu systemu tych elementów może nie być. Z tego powodu bezpieczniej jest stosować pełne ścieżki do poleceń i plików, nie opierać się na skrótach powłoki oraz jawnie wskazywać lokalizację danych potrzebnych do działania programu.

Inną przyczyną jest zbyt wczesne wykonanie polecenia. Jeżeli skrypt próbuje odwołać się do urządzenia, interfejsu sieciowego albo zamontowanego zasobu, który nie jest jeszcze gotowy, działanie może zakończyć się błędem. Pomocne bywa wtedy przeniesienie zadania do mechanizmu obsługującego zależności lub dodanie kontrolowanego oczekiwania, ale samo opóźnienie nie zawsze rozwiązuje problem. Lepsze jest wskazanie rzeczywistego warunku gotowości.

Warto zwrócić uwagę na prawa dostępu. Skrypt wykonywany z uprawnieniami administracyjnymi może zmieniać konfigurację całego systemu, nadpisywać pliki lub uruchamiać procesy w sposób niedostępny dla zwykłego użytkownika. Błąd w jednej linijce może więc prowadzić do braku startu wybranej usługi albo do powtarzających się komunikatów o błędach. Przed zmianą dobrze jest wykonać kopię pliku, zapisać jego wcześniejszą zawartość i przetestować komendy osobno.

Jeżeli system zatrzymuje się podczas uruchamiania po edycji RC.local, można sprawdzić komunikaty rozruchowe z użyciem dostępnych narzędzi diagnostycznych, uruchomić system w trybie awaryjnym lub tymczasowo pominąć wadliwe polecenie. Należy unikać dopisywania kolejnych komend bez ustalenia, która z wcześniejszych powoduje problem. Czytelne komentarze, logiczne nazwy skryptów i sprawdzanie kodów zakończenia ułatwiają późniejszą analizę.

RC.local – praktyczne wskazówki konfiguracji

Przed wykorzystaniem RC.local należy ustalić, jaki mechanizm startowy jest używany w konkretnej dystrybucji. Sama obecność pliku nie gwarantuje, że system go wykona. Warto sprawdzić dokumentację danej wersji, status odpowiedniej usługi oraz komunikaty zapisane podczas uruchamiania. Ta sama nazwa może oznaczać inny sposób działania w systemie opartym na starszych skryptach i inny w systemie korzystającym z nowoczesnego menedżera usług.

Komendy powinny być możliwie krótkie, jednoznaczne i odporne na brak interaktywnego terminala. Nie powinno się umieszczać w takim pliku poleceń wymagających odpowiedzi z klawiatury, otwarcia okna graficznego lub hasła wpisywanego ręcznie. Jeżeli konieczne jest uruchomienie programu, lepiej przygotować osobny skrypt z kontrolą błędów, opisem parametrów oraz zapisem komunikatów do ustalonego pliku dziennika.

Przydatne jest sprawdzenie konfiguracji przed ponownym uruchomieniem. Najpierw można wykonać każde polecenie ręcznie z odpowiednimi uprawnieniami, następnie uruchomić cały skrypt w trybie kontrolowanym i dopiero później przetestować automatyczne wykonanie. Należy przy tym pamiętać, że wynik testu w terminalu może różnić się od wyniku podczas startu systemu, ponieważ zmieniają się zmienne środowiskowe, kolejność uruchamiania oraz dostępność urządzeń.

Dobrym zwyczajem jest unikanie poleceń, które mogą być wykonywane wielokrotnie bez sprawdzenia bieżącego stanu. Jeżeli skrypt za każdym razem dopisuje te same dane do pliku, tworzy kolejne procesy albo zmienia ustawienia bez weryfikacji, po wielu restartach może powstać trudna do prześledzenia konfiguracja. Warto stosować warunki sprawdzające, czy dana czynność została już wykonana, oraz rejestrować najważniejsze etapy działania.

Po aktualizacji systemu należy ponownie zweryfikować działanie RC.local. Zmiana położenia programu, nazwy urządzenia, sposobu montowania zasobów lub domyślnych praw dostępu może sprawić, że wcześniejszy skrypt przestanie działać. Jeżeli zadanie stało się ważne dla codziennej pracy, korzystniejsze może być przeniesienie go do dedykowanej jednostki lub innego mechanizmu, który wyraźnie opisuje zależności i błędy.

RC.local – kiedy zgłosić się do serwisu

Wsparcie serwisowe jest wskazane, gdy po zmianie RC.local komputer nie przechodzi prawidłowo procesu uruchamiania, polecenia wykonywane są w niewłaściwej kolejności albo po każdym restarcie pojawiają się nowe komunikaty o błędach. Dotyczy to również sytuacji, w której nie jest jasne, czy problem wynika z samego skryptu, uszkodzenia systemu plików, niezgodności pakietów czy błędów urządzenia. Przed przekazaniem sprzętu dobrze jest zanotować ostatnią zmianę, treść komunikatu oraz moment, w którym pojawiła się usterka.

W Warszawie analizę takiej konfiguracji można zlecić firmie Warszawskie Pogotowie Komputerowe 24/7, kontaktując się pod numerem +48 22 100 48 29. W ramach prac można sprawdzić pliki startowe, przeanalizować komunikaty systemowe, uporządkować skrypty i przywrócić możliwość prawidłowego uruchamiania komputera. Przed rozpoczęciem czynności warto zabezpieczyć ważne dane oraz poinformować o zmianach wykonanych bezpośrednio przed wystąpieniem problemu.

Nie każda usterka związana z RC.local oznacza konieczność ponownej instalacji systemu. Często możliwe jest odnalezienie błędnej komendy, przywrócenie poprzedniej wersji pliku, poprawienie praw dostępu albo zastąpienie przestarzałego rozwiązania właściwą konfiguracją. Po zakończeniu prac należy wykonać kilka kontrolnych uruchomień i sprawdzić, czy wszystkie potrzebne programy oraz urządzenia są dostępne w oczekiwanym momencie.