Systemd a-t-il toujours le concept des niveaux d'exécution? Par exemple, est-il inutile d'utiliser telinit <number>?

SystemD Run-Level Low-Down

Dans le SystemD (aemon), les niveaux d'exécution sont exposés en tant que «cibles». Le concept est toujours là, mais le flux de travail pour produire le résultat souhaité pour votre besoin est différent.

La pièce jointe devrait clarifier cette question.

Comment changer le niveau d'exécution actuel?

$ systemctl isolate runlevelX.target

Comment changer le niveau d'exécution par défaut pour le prochain démarrage?

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

• ln -sf TARGET DESTINATION
• -s crée un lien symbolique
• -f supprime le fichier de destination existant

OU (comme l'a suggéré @centimane), utilisez simplement la systemdcommande "blessed" :

systemctl set-default [target name].target

Comment identifier le niveau d'exécution actuel?

$ systemctl list-units --type=target

Non. Comme les gens du système eux-mêmes l'ont écrit deux fois, une fois dans leur telinitmanuel et une fois dans leur runlevelmanuel, les niveaux d'exécution sont "obsolètes". Vous pouvez oublier les niveaux d'exécution.

Ces choses n'existent pas du tout dans systemd, à part quelques cales de compatibilité.

• Il existe des liens symboliques pour les noms de cibles, mais ces cibles ne sont jamais réellement utilisées par systemd proprement dit.
  • Au contraire, le processus d'amorçage utilise un default.target(et de là un ou les deux de a graphical.targetet a multi-user.target), a rescue.targetou an emergency.target. Et le processus d'arrêt implique un shutdown.target, un reboot.target, un halt.targetou un poweroff.target. Aucun objectif au niveau de l'exécution n'est impliqué dans l'amorçage ou l'arrêt.
  • La telinitcommande, dont on pourrait penser qu'elle utilise les liens symboliques de compatibilité pour mapper ses arguments de ligne de commande, ne le fait pas non plus. Il y a une table dans le code câblé source du telinitprogramme, et les chiffres 2, 3, 4et 5comme arguments à la commande sont Hardwired à mapper multi-user.targetet graphical.target.
  • systemd-update-utmp a également une table câblée interne.
• Il n'y a pas de "table init" de trucs de niveau d'exécution. systemd est uniquement compatible avec van Smoorenburg rc, pas avec van Smoorenburginit .
• Il n'y a pas de valeur de "niveau d'exécution actuel" gérée par systemd lui-même. Au contraire, la presque entièrement sans papier systemd-update-utmpcommande fonctionne en interne en termes de l'activation des états rescue.target, multi-user.targetet graphical.target.
• systemd-sysv-generator, le générateur d'unités de service à compatibilité descendante de systemd, fusionne les /etc/rc[234].drépertoires en une seule Wanted-Byrelation avec multi-user.targetles unités de service générées. Il n'existe aucune référence réelle aux niveaux d'exécution dans les unités de service générées. (Il y en avait, il y a des années, mais les gens du système ont constaté que cela avait mal tourné, car ils n'étaient référencés nulle part ailleurs.)

Si l'on est un utilisateur d'un système qui construit systemd comme Arch Linux pour l'interrogateur à " Pourquoi est-ce que` init 0` aboutit à "Excess Arguments" sur Arch install? ", On n'obtient même pas les shims de compatibilité, et des commandes telles commeinit 0 résultat du comportement systemd "natif", qui est de se plaindre que la commande a été invoquée de manière incorrecte.

Lectures complémentaires

• Lennart Poettering et al .. runlevel. pages de manuel de systemd. Freedesktop.org.
• Lennart Poettering et al .. telinit. pages de manuel de systemd. Freedesktop.org.
• Lennart Poettering et al .. bootup. pages de manuel de systemd. Freedesktop.org.
• Lennart Poettering (2015-02-08). partout: supprimez la configurabilité du niveau d'exécution sysv sur le mappage cible . 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/inittabappartient au passé. . Réponses fréquemment données.

Merci beaucoup. Donc, si j'ai bien compris:

Par exemple:

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

Production:

/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

Donc, comme vous pouvez le voir, le concept des niveaux d'exécution existe, mais il est assez obsolète du fait que les fichiers runlevel.target ne sont pas en fait de «vrais» fichiers mais des liens logiciels vers le nouveau schéma de fichiers moderne et systemd aime les appeler «cibles».

Donc, si vous voulez faire quelque chose comme telinit 5ça ce serait comme ça: systemctl isolate runlevel5.target qui est identique à: systemctl isolate graphical.target(recommandé à mon avis).

Au cas où vous souhaiteriez connaître toutes les cibles possibles:

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

systemd a introduit des cibles comme contrepartie pour les niveaux d' exécution dans le système d'initialisation sysV. Les développeurs de sytemd l'ont rendu presque compatible avec la plupart des scripts sysV. Il en va de même pour telinit <runlevel> . Ceci est traduit en équivalent systemd.

Par exemple telinit 0, éteint la machine. systemd a poweroff.target pour faire la même chose que le niveau d' exécution 0 . Ainsi telinit 0est traduit par systemd pour activer poweroff.target .

Mais certains problèmes de compatibilité existent avec les systèmes sytemd et sysV init-> https://www.freedesktop.org/wiki/Software/systemd/Incompatibility .