Právě jsem přešel na debian jessie a většina věcí běží v pořádku, včetně správce grafického zobrazení wdm .

Jde o to, že prostě nechápu, jak to funguje. Zřejmě můj /etc/init.d/wdm skript se nazývá, protože když vložím předčasný exit tam se wdm nespustí. Ale když alternativně přejmenuji /etc/rc3.d adresář (můj výchozí runlevel býval 3), pak se wdm stále spouští.

Nepodařilo se mi zjistit, jak systemd našel tento skript, a nechápu, co dělá se všemi ostatními skripty init.d.

• Kdy a jak systemd spouští skripty init.d?
• Měl bych se z dlouhodobého hlediska zbavit všech skriptů init.d?

Přijatá odpověď:

odpověď chaosu je to, co říká nějaká dokumentace. Ale to není to, co systemd ve skutečnosti dělá. (Není to to, co van Smoorenburg rc udělal, buď. Van Smoorenburg rc zcela určitě ne ignorovat hlavičky LSB, které insserv používá se pro začátek k výpočtu statického uspořádání.) Dokumentace Freedesktop, jako je stránka „Nekompatibility“, je ve skutečnosti v těchto a dalších bodech chybná. (HOME proměnná prostředí ve skutečnosti je často nastavováno např. Dlouho to bylo nikde nezdokumentováno. Nyní je to alespoň zdokumentováno v příručce, ale tato webová stránka Freedesktop stále nebyla opravena.)

Nativní formát služby pro systemd je jednotka služby . Vlastní správa služeb systemd funguje pouze pokud jde o ty, které čte z jednoho z devíti adresářů, kde (v celém systému) .service soubory mohou žít. /etc/systemd/system , /run/systemd/system , /usr/local/lib/systemd/system a /usr/lib/systemd/system jsou čtyři z těchto adresářů.

Kompatibilita s van Smoorenburg rc skriptů je dosaženo pomocí konverzního programu s názvem systemd-sysv-generator . Tento program je uveden v /usr/lib/systemd/system-generators/ adresář a je tedy spouštěn automaticky systemd na začátku procesu bootstrap při každém bootování a znovu pokaždé, když systemd dostane pokyn k opětovnému načtení konfigurace později.

Tento program je generátor , typ pomocného nástroje, jehož úkolem je vytvářet soubory servisních jednotek za běhu, v tmpfs, kde jsou umístěny tři další z těchto devíti adresářů (které jsou určeny pouze pro použití generátory). systemd-sysv-generator generuje servisní jednotky, které provozují van Smoorenburg rc skripty z /etc/init.d , pokud nenajde nativní systémovou servisní jednotku s tímto názvem, která již existuje v ostatních šesti umístěních.

systemd service management zná pouze servisní jednotky. Tyto automaticky (znovu)generované servisní jednotky jsou napsány tak, aby vyvolaly van Smoorenburg rc skripty. Mají mimo jiné:

[Unit]
SourcePath=/etc/init.d/wibble
[Service]
ExecStart=/etc/init.d/wibble start
ExecStop=/etc/init.d/wibble stop

Související:Ubuntu – Jak spouštět skripty .sh?

Přijatá moudrost je, že van Smoorenburg rc skripty musí mít hlavičku LSB a jsou spouštěny paralelně, aniž by respektovaly priority stanovené /etc/rc?.d/ Systém. Toto je nesprávné ve všech bodech.

Ve skutečnosti nepotřebují mít hlavičku LSB, a pokud ji nemají systemd-sysv-generator dokáže rozpoznat omezenější stará záhlaví komentářů RedHat (description: , pidfile: , a tak dále). Navíc v případě absence hlavičky LSB se vrátí zpět k obsahu /etc/rc?.d symbolické odkazové farmy, čtení priorit zakódovaných do názvů odkazů a vytváření před/po objednání z nich, serializace služeb. Nejen, že hlavičky LSB nejsou požadavkem, a nejen že samy kódují před/po objednání, které věci do určité míry serializují, záložní chování při jejich úplné absenci je ve skutečnosti výrazně neparalelní operace.

Důvod, proč /etc/rc3.d nezdálo se, že by záleželo na tom, že jste pravděpodobně měli tento skript povolený prostřednictvím jiného /etc/rc?.d/ adresář. systemd-sysv-generator překládá být uveden v některém z /etc/rc2.d/ , /etc/rc3.d/ a /etc/rc4.d/ do nativního Wanted-By vztah k multi-user.target systemd . Úrovně běhu jsou ve světě systemd „zastaralé“ a můžete na ně zapomenout.

Další čtení

• systemd-sysv-generator . systémové manuálové stránky. Freedesktop.org.
• „Proměnné prostředí ve spawnovaných procesech“. systemd.exec . systémové manuálové stránky. Freedesktop.org.
• https://unix.stackexchange.com/a/394191/5132
• https://unix.stackexchange.com/a/204075/5132
• https://unix.stackexchange.com/a/196014/5132
• https://unix.stackexchange.com/a/332797/5132