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.