la risposta del caos è ciò che dicono alcuni documenti. Ma non è quello che fa effettivamente systemd. (Non è nemmeno quello che ha fatto van Smoorenburg rc. Il van Smoorenburgrc sicuramente non ha ignorato le intestazioni LSB, che insservper calcolare gli ordini statici, per cominciare.) La documentazione di Freedesktop, come quella pagina "Incompatibilità", è in realtà errata, su questi e altri punti. (La HOMEvariabile d'ambiente infatti è spesso impostata, ad esempio. È rimasta completamente priva di documenti ovunque per lungo tempo. Ora è almeno documentata nel manuale, ma la pagina WWW di Freedesktop non è ancora stata corretta.)
Il formato di servizio nativo per systemd è l' unità di servizio . La corretta gestione dei servizi di systemd opera esclusivamente in termini di quelli, che legge da una delle nove directory in cui i file (a livello di sistema) .servicepossono vivere. /etc/systemd/system, /run/systemd/system, /usr/local/lib/systemd/system, E /usr/lib/systemd/systemsono quattro di queste directory.
La compatibilità con gli rcscript di van Smoorenburg è ottenuta con un programma di conversione, denominato systemd-sysv-generator. Questo programma è elencato nella /usr/lib/systemd/system-generators/directory e viene quindi eseguito automaticamente da systemd all'inizio del processo bootstrap ad ogni avvio, e di nuovo ogni volta che viene richiesto a systemd di ricaricare la sua configurazione in un secondo momento.
Questo programma è un generatore , un tipo di utilità ausiliaria il cui compito è quello di creare file di unità di servizio al volo, in un tmpfs in cui si trovano altre tre di quelle nove directory (che sono destinate ad essere utilizzate solo dai generatori). systemd-sysv-generatorgenera le unità di servizio che eseguono gli rcscript di van Smoorenburg /etc/init.d, se non trova un'unità di servizio nativa con quel nome già esistente nelle altre sei posizioni.
la gestione dei servizi di systemd conosce solo le unità di servizio. Queste unità di servizio (ri) generate automaticamente sono scritte per invocare gli rcscript di van Smoorenburg . Hanno, tra le altre cose:
[Unità]
SourcePath = / etc / init.d / Wibble
[Servizio]
ExecStart = / etc / init.d / inizio wibble
ExecStop = / etc / init.d / wibble stop
La saggezza ricevuta è che gli rcscript di Van Smoorenburg devono avere un'intestazione LSB e sono eseguiti in parallelo senza onorare le priorità imposte dal /etc/rc?.d/sistema. Questo non è corretto su tutti i punti.
In realtà, essi non hanno bisogno di avere un LSB intestazione, e non se lo fanno systemd-sysv-generatorin grado di riconoscere i più limitati vecchi RedHat intestazioni di commento ( description:, pidfile:, e così via). Inoltre, in assenza di un'intestazione LSB, tornerà al contenuto delle /etc/rc?.dfarm di link simbolici, leggendo le priorità codificate nei nomi dei link e costruendo un precedente / successivo da essi, serializzando i servizi. Non solo le intestazioni LSB non sono un requisito, e non solo codificano essi stessi prima / dopo gli ordini che serializzano le cose in una certa misura, il comportamento di fallback in loro completa assenza è in realtà un'operazione significativamente non parallelizzata.
La ragione per cui /etc/rc3.dnon sembra importare è che probabilmente lo script è stato abilitato tramite un'altra /etc/rc?.d/directory. systemd-sysv-generatorsi traduce in un elenco di /etc/rc2.d/, /etc/rc3.d/e /etc/rc4.d/in una Wanted-Byrelazione nativa con systemd multi-user.target. I livelli di esecuzione sono "obsoleti" nel mondo dei sistemi e puoi dimenticartene.
Ulteriori letture