odpowiedzią na chaos jest to, co mówi niektóre dokumenty. Ale tak naprawdę nie działa systemd. (Nie tak też rczrobił van Smoorenburg . Van Smoorenburgrc zdecydowanie nie zignorował nagłówków LSB, które na początku insservsłużyły do obliczania statycznych porządków.) Dokumentacja Freedesktop, taka jak strona „Niezgodności”, jest w rzeczywistości błędna, na te i inne punkty. ( HOMEZmienna środowiskowa w rzeczywistości jest często ustawiana, na przykład. To było całkowicie nieudokumentowane przez długi czas. Teraz jest to przynajmniej udokumentowane w podręczniku, ale ta strona WWW Freedesktop wciąż nie została poprawiona).
Natywnym formatem usługi dla systemd jest jednostka serwisowa . Właściwe zarządzanie usługami systemd działa wyłącznie w zakresie tych, które czyta z jednego z dziewięciu katalogów, w których mogą znajdować się .servicepliki (systemowe) . /etc/systemd/system, /run/systemd/system, /usr/local/lib/systemd/system, A /usr/lib/systemd/systemcztery z tych katalogów.
Kompatybilność ze rcskryptami van Smoorenburga jest osiągana dzięki programowi do konwersji o nazwie systemd-sysv-generator. Ten program znajduje się na liście w /usr/lib/systemd/system-generators/katalogu i dlatego jest uruchamiany automatycznie przez systemd na początku procesu ładowania przy każdym rozruchu, i ponownie za każdym razem, gdy systemd otrzymuje polecenie ponownego załadowania konfiguracji później.
Ten program jest generatorem , rodzajem pomocniczego narzędzia, którego zadaniem jest tworzenie plików jednostki usługowej w locie, w tmpfs, w którym znajdują się jeszcze trzy z tych dziewięciu katalogów (które mają być używane tylko przez generatory). systemd-sysv-generatorgeneruje jednostki usługowe, z których uruchamiane są rcskrypty van Smoorenburga /etc/init.d, jeśli nie znajdzie natywnej systemowej jednostki usługowej o takiej nazwie, która już istnieje w pozostałych sześciu lokalizacjach.
systemowe zarządzanie usługami zna tylko jednostki serwisowe. Te (ponownie) generowane automatycznie jednostki usługowe są zapisywane w celu wywołania rcskryptów van Smoorenburga . Mają między innymi:
[Jednostka]
SourcePath = / etc / init.d / wibble
[Usługa]
ExecStart = / etc / init.d / wibble start
ExecStop = / etc / init.d / wibble stop
Otrzymano mądrość, że rcskrypty van Smoorenburga muszą mieć nagłówek LSB i są uruchamiane równolegle bez uwzględnienia priorytetów narzuconych przez /etc/rc?.d/system. Jest to nieprawidłowe we wszystkich punktach.
W rzeczywistości nie muszą mieć nagłówka LSB, a jeśli nie są w stanie systemd-sysv-generatorrozpoznać bardziej ograniczonych starych nagłówków komentarzy RedHat ( description:, pidfile:itd.). Co więcej, przy braku nagłówka LSB wróci do zawartości /etc/rc?.dfarm symbolicznych linków, odczytuje priorytety zakodowane w nazwach linków i konstruuje przed nimi / po ich zamówieniu, szeregując usługi. Nagłówki LSB nie tylko nie są wymagane i nie tylko same kodują przed / po uporządkowaniu, które serializują dane w pewnym stopniu, zachowanie awaryjne przy ich całkowitej nieobecności jest w rzeczywistości działaniem zasadniczo niezrównoleglonym.
Przyczyną, która /etc/rc3.dnie wydawała się mieć znaczenia, jest to, że prawdopodobnie masz włączony ten skrypt w innym /etc/rc?.d/katalogu. systemd-sysv-generatorprzekłada te wymienione w dowolnym z /etc/rc2.d/, /etc/rc3.d/i /etc/rc4.d/do natywnego Wanted-Byzwiązku do Systemd roku multi-user.target. Poziomy uruchamiania są „przestarzałe” w świecie systemowym i można o nich zapomnieć.
Dalsza lektura
systemdi skrypt /etc/init.d nie jest ustawiony na „rozruch przy starcie”, nadal będzie działał zgodnie z oczekiwaniami, ale nie pojawi się w wykazy jednostek: unix.stackexchange.com/a/518894/8337Systemd jest wstecznie kompatybilny ze skryptami inicjującymi SysV. Zgodnie z LSB 3.1 skrypt inicjujący musi mieć informacyjne konwencje komentarza , określające, kiedy skrypt musi się uruchomić / zatrzymać i co jest wymagane do uruchomienia / zatrzymania skryptu. To jest przykład:
To jest sekcja z komentarzem, która jest ignorowana przez SysV. Z drugiej strony systemd odczytuje te informacje o zależnościach i uruchamia te skrypty w zależności od tego.
Ale jest jeden punkt, w którym systemd i SysV różnią się pod względem skryptów inicjujących. SysV wykonuje skrypty w kolejności sekwencyjnej na podstawie ich liczby w nazwie pliku. Systemd nie. Jeśli zależności są spełnione, systemd uruchamia skrypty natychmiast, bez honorowania numeracji nazw skryptów. Niektóre z nich najprawdopodobniej zawiodą z powodu zamówienia. Istnieje wiele innych niezgodności, które należy wziąć pod uwagę.
Jeśli istnieją skrypty startowe i pliki .service dla tej samej usługi, systemd wykona oba, gdy tylko zostaną spełnione zależności (w przypadku skryptu init, te zdefiniowane w nagłówku LSB).
źródło