Sono appena passato a Debian Jessie e la maggior parte delle cose funziona bene, incluso il mio display manager grafico wdm .

Il fatto è che non capisco come funzioni. Ovviamente il mio /etc/init.d/wdm viene chiamato lo script, perché quando inserisco un exit anticipato lì dentro, wdm non è avviato. Ma quando rinomino in alternativa /etc/rc3.d directory (il mio runlevel predefinito era 3), quindi wdm è ancora avviato.

Non sono riuscito a scoprire come systemd trova questo script e non capisco cosa faccia a tutti gli altri script init.d.

• Quando e come systemd esegue gli script init.d?
• A lungo termine, dovrei eliminare tutti gli script init.d?

Risposta accettata:

La risposta del caos è ciò che dice una documentazione. Ma non è ciò che fa effettivamente systemd. (Non è quello che van Smoorenburg rc fatto, neanche. Il furgone Smoorenburg rc sicuramente non ignora le intestazioni LSB, che insserv utilizzato per calcolare gli ordini statici, per cominciare.) La documentazione di Freedesktop, come quella pagina "Incompatibilità", è in effetti sbagliata, su questi e altri punti. (La HOME la variabile di ambiente infatti è spesso impostato, per esempio. Questo è andato del tutto illegale da nessuna parte per molto tempo. Ora è almeno documentato nel manuale, ma quella pagina WWW di Freedesktop non è stata ancora corretta.)

Il formato del servizio nativo per systemd è 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 (a livello di sistema) .service i file possono vivere. /etc/systemd/system , /run/systemd/system , /usr/local/lib/systemd/system e /usr/lib/systemd/system sono quattro di queste directory.

La compatibilità con van Smoorenburg rc scripts si ottiene con un programma di conversione, chiamato systemd-sysv-generator . Questo programma è elencato in /usr/lib/systemd/system-generators/ directory e viene quindi eseguito automaticamente da systemd all'inizio del processo di 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 è creare file di unità di servizio al volo, in un tmpfs in cui si trovano altre tre di queste nove directory (che sono destinate ad essere utilizzate solo dai generatori). systemd-sysv-generator genera le unità di servizio che gestiscono il furgone Smoorenburg rc script da /etc/init.d , se non trova un'unità di servizio systemd nativa con quel nome già esistente nelle altre sei posizioni.

systemd service management conosce solo le unità di servizio. Queste unità di servizio (ri)generate automaticamente vengono scritte per invocare il rc van Smoorenburg script. Hanno, tra le altre cose:

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

Correlati:Ubuntu - Come eseguire gli script .sh?

La saggezza ricevuta è che il furgone Smoorenburg rc gli script devono avere un'intestazione LSB e vengono eseguiti in parallelo senza rispettare le priorità imposte dal /etc/rc?.d/ sistema. Questo non è corretto su tutti i punti.

In effetti, non è necessario che abbiano un'intestazione LSB e, se non lo fanno systemd-sysv-generator può riconoscere le vecchie intestazioni dei commenti RedHat più limitate (description: , pidfile: , e così via). Inoltre, in assenza di un'intestazione LSB ritornerà al contenuto del /etc/rc?.d farm di link simbolici, leggendo le priorità codificate nei nomi dei link e costruendo un prima/dopo aver ordinato da esse, serializzando i servizi. Non solo le intestazioni LSB non sono un requisito, e non solo codificano esse stesse 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 parallela.

Il motivo per cui /etc/rc3.d non sembrava importare è che probabilmente avevi quello script abilitato tramite un altro /etc/rc?.d/ directory. systemd-sysv-generator traduce l'essere elencato in uno qualsiasi di /etc/rc2.d/ , /etc/rc3.d/ e /etc/rc4.d/ in un Wanted-By nativo relazione con multi-user.target di systemd . I livelli di esecuzione sono "obsoleti" nel mondo systemd e puoi dimenticartene.

Ulteriori letture

• generatore systemd-sysv . pagine di manuale di sistema. Freedesktop.org.
• "Variabili d'ambiente nei processi generati". systemd.exec . pagine di manuale di sistema. 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