Systemd ha ancora il concetto di runlevel? Ad esempio, è inutile usare telinit <number>?

SistemaD Run-Level Low-Down

All'interno del SystemD (aemon), i runlevel sono esposti come "Target". Il concetto è ancora lì, ma il flusso di lavoro per produrre il risultato desiderato per le vostre esigenze è diverso.

L'allegato dovrebbe chiarire questo problema.

Come cambio l'attuale runlevel?

$ systemctl isolate runlevelX.target

Come posso modificare il runlevel predefinito per il prossimo avvio?

# Create a symlink
$ ln -sf /usr/lib/systemd/system/multi-user.target /etc/systemd/system/default.target

• ln -sf TARGET DESTINATION
• -s crea un collegamento simbolico
• -f rimuove il file di destinazione esistente

OPPURE (come suggerito da @centimane) usa semplicemente il systemdcomando "benedetto" :

systemctl set-default [target name].target

Come posso identificare l'attuale runlevel?

$ systemctl list-units --type=target

No. Come hanno scritto due volte le stesse persone del sistema, una volta nel loro telinitmanuale e una volta nel loro runlevelmanuale, i runlevel sono "obsoleti". Puoi dimenticare i runlevel.

Queste cose in realtà non esistono affatto in systemd, con alcuni spessori di compatibilità.

• Esistono alcuni collegamenti simbolici per i nomi dei target, ma questi target non vengono mai effettivamente utilizzati da systemd.
  • Piuttosto, il processo bootstrap impiega un default.target(e quindi uno o entrambi di a graphical.targete a multi-user.target), a rescue.targeto a emergency.target. E il processo di spegnimento comporta a shutdown.target, a reboot.target, a halt.targeto a poweroff.target. Nessuna destinazione a livello di runtime non è coinvolta né in bootstrap né in shutdown.
  • Il telinitcomando, che si potrebbe pensare che utilizza i collegamenti simbolici di compatibilità per mappare i suoi argomenti della riga di comando, non lo fa neanche. C'è una tabella cablata nel codice sorgente del telinitprogramma e i numeri 2, 3e 4, 5poiché gli argomenti del comando sono cablati per il mapping a multi-user.targete graphical.target.
  • systemd-update-utmp ha anche una tabella cablata interna.
• Non esiste una "tabella init" di roba runlevel. systemd è compatibile solo con van Smoorenburg rc, non con van Smoorenburg init.
• Non esiste un valore di "livello corrente" gestito da systemd stesso. Piuttosto, la quasi interamente non documentato systemd-update-utmpcomando opera internamente in termini di attivazione di stati rescue.target, multi-user.targete graphical.target.
• systemd-sysv-generator, generatore di unità di servizio di compatibilità con le versioni precedenti di systemd, unisce le /etc/rc[234].ddirectory in un'unica Wanted-Byrelazione con le multi-user.targetunità di servizio generate. Non esiste alcun riferimento effettivo per l'esecuzione dei livelli nelle unità di servizio generate. (Ci sono stati anni fa, ma la gente del sistema ha scoperto che questo è andato storto, perché non venivano citati altrove.)

Se uno è un utente di un sistema che costruisce systemd come Arch Linux per l'interrogatore in " Perché" init 0 "si traduce in" Argomenti in eccesso "su Arch? ", Non si ottengono nemmeno gli shim di compatibilità e comandi come init 0risultato nel comportamento systemd "nativo", che è quello di lamentarsi che il comando è stato invocato in modo errato.

Ulteriori letture

• Lennart Poettering et al runlevel. pagine di manuale di systemd. Freedesktop.org.
• Lennart Poettering et al telinit. pagine di manuale di systemd. Freedesktop.org.
• Lennart Poettering et al bootup. pagine di manuale di systemd. Freedesktop.org.
• Lennart Poettering (2015-02-08). ovunque: rimuovi la configurabilità del runlevel sysv sulla mappatura di destinazione . systemd. github.
• /unix//a/196014/5132
• /unix//a/196197/5132
• /unix//a/233581/5132
• /unix//a/211927/5132
• /unix//a/392612/5132
• Jonathan de Boyne Pollard (2015). /etc/inittabè un ricordo del passato. . Risposte frequentemente fornite.

Grazie mille. Quindi, se avessi capito correttamente:

Per esempio:

ls -ll /usr/lib/systemd/system/runlevel*.target

Produzione:

/usr/lib/systemd/system/runlevel0.target -> poweroff.target
/usr/lib/systemd/system/runlevel1.target -> rescue.target
/usr/lib/systemd/system/runlevel2.target -> multi-user.target
/usr/lib/systemd/system/runlevel3.target -> multi-user.target
/usr/lib/systemd/system/runlevel4.target -> multi-user.target
/usr/lib/systemd/system/runlevel5.target -> graphical.target
/usr/lib/systemd/system/runlevel6.target -> reboot.target

Come puoi vedere, esiste il concetto di runlevel, ma è piuttosto obsoleto a causa del fatto che i file runlevel.target non sono in realtà file "reali" ma collegamenti soft al nuovo, moderno e meglio definito schema di file che a systemd piace chiamarli "obiettivi".

Quindi, se ti piacerebbe fare qualcosa del genere telinit 5sarebbe così: systemctl isolate runlevel5.target che è identico a: systemctl isolate graphical.target(consigliato a mio parere).

Nel caso in cui sei interessato a conoscere tutti i possibili obiettivi:

ls /usr/lib/systemd/system/*.target

systemd ha introdotto gli obiettivi come controparte per i runlevel nel sistema init sysV. Gli sviluppatori di sistemi hanno reso quasi compatibile con la maggior parte degli script sysV. Lo stesso succede per telinit <runlevel>. Questo è tradotto in equivalente systemd.

Ad esempio telinit 0, spegne la macchina. systemd ha poweroff.target per fare lo stesso di runlevel 0 . Quindi telinit 0è tradotto da systemd per attivare poweroff.target .

Ma ci sono alcuni problemi di compatibilità con i sistemi init sytemd e sysV-> https://www.freedesktop.org/wiki/Software/systemd/Incompatibilità .