W jaki sposób systemd używa skryptów /etc/init.d?


120

Właśnie przełączyłem się na debian jessie i większość rzeczy działa dobrze, w tym mój graficzny menedżer wyświetlania wdm.

Chodzi o to, że po prostu nie rozumiem, jak to działa. Oczywiście mój /etc/init.d/wdmskrypt jest wywoływany, ponieważ kiedy wstawiam tam wcześnie exit, wdm nie jest uruchamiany. Ale kiedy alternatywnie zmieniam nazwę katalogu /etc/rc3.d (mój domyślny poziom działania to 3), wtedy wdm jest nadal uruchamiany.

Nie mogłem dowiedzieć się, jak systemd znajduje ten skrypt i nie rozumiem, co robi ze wszystkimi innymi skryptami init.d.

  • Kiedy i jak systemd uruchamia init.d scrips?
  • Czy na dłuższą metę powinienem pozbyć się wszystkich skryptów init.d?

Odpowiedzi:


166

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


2
W systemie Debian katalog system-generators nie
— istnieje w

5
To prosta, niesamowita odpowiedź. Dobra robota, proszę pana.
— peelman

1
Dziękuję, dziękuję, dziękuję za to! Radzenie sobie z mieszanką systemów Debian 8 i RH / CentOS 7 sprawiło, że zarządzanie SysVInit vs. zarządzanie zależnością od usług Systemd było trochę kłopotliwe, ale to wyjaśnienie tego, co robi systemd bardzo pomogło mi zrozumieć.
— Toby

Ten generator działa. Wspomnę również, dla obserwujących, że jeśli masz starszą wersję 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/8337
— rogerdpack

Ten generator działa. Dla obserwujących wspomnę również, że jeśli masz starszą wersję skryptu systemd i skryptu /etc/init.d, który nie jest ustawiony na „rozruch przy starcie”, nadal będzie się uruchamiał / zatrzymywał zgodnie z oczekiwaniami przy użyciu systemctl, ale wygrał nie pojawią się na listach jednostek show: unix.stackexchange.com/questions/517872/... również zauważ , że w zasadzie „nie możesz” kontrolować tych usług poprzez bezpośrednie uruchomienie /etc/init.d/xx lub systemd dostaje ... mylony co do tego, co działa, a co nie: |
— rogerdpack

17

Systemd 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:

### BEGIN INIT INFO
# Provides: my-service
# Required-Start: $local_fs $network $remote_fs
# Required-Stop: $local_fs $network $remote_fs
# Default-Start:  2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: start and stop service my-service
# Description: my-service blah blah ...
### END INIT INFO

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).


Okej, ale mam też całą masę plików .service w / lib / systemd / system /. Co faktycznie wykonuje systemd? Cokolwiek jest określone w plikach serwisowych (w kolejności zależności), skryptach init.d lub obu?
— Martin Drautzburg,

@MartinDrautzburg Dodałem to do odpowiedzi
— chaos

1
Jak sidenote, Debian ogłosił właśnie zrzucić LSB kompatybilność: article.gmane.org/gmane.linux.debian.devel.lsb/1103
— sty

systemd jest wszystkim, ALE kompatybilnym ze skryptami SysV. To stwierdzenie jest nie tylko niepoprawne, ale odnośnik do linku wyjaśnia, że ​​jest „w większości kompatybilny”, a wysiłek potrzebny do uzyskania takich samych wyników jest oburzająco ogromny.
— Julie w Austin,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.