Systemd connaît-il toujours les niveaux d'exécution?


17

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



Je ne connais pas les réponses ci-dessous, mais dans RHEL / Centos 7.6 init 1ou init 3ou init 5ou init 6ou init 0ou runlevelencore, ils se comportent comme ils l'ont toujours fait, et c'est tout ce qui m'importe. Syntaxe beaucoup plus facile alorssystemctl blabla blabla.blabla
ron

Réponses:


14

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

Puis-je toujours utiliser la commande init pour basculer entre les niveaux d'exécution?
drpaneas

2
Si votre package systemd est construit avec le support de compat SysV, il inclura un lien symbolique telinit vers le binaire systemd, qui, lorsqu'il est appelé telinit, mappera les niveaux d'exécution 0-6 aux cibles systemd - consultez telinit (8) pour une liste de ces mappages .
Wieland

2
Pour modifier la cible par défaut, vous devez utiliser systemctl set-default [target name].targetplutôt que de créer manuellement le lien.
Centimane

13

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


4

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

Oui, je crois que vous comprenez cela correctement. Je serai un adopteur tardif de SystemD, car le système procédural, étape par étape, INIT.D est ce que je connais le mieux ... J'applaudis que vous explorez SystemD. La meilleure partie de SystemD est son multi-threading parallèle, qui permet un démarrage plus rapide. Le démarrage multi-thread peut être accompli avec INIT.D, mais nécessite un script BASH fort.
Tyler Maginnis

BTW, ls -llest équivalent à ls -l. Vous voudrez peut-être prendre l'habitude d'utiliser ls -ld.
G-Man dit 'Réinstalle Monica'

telinit 0/ telinit 6fonctionne toujours. Étant donné que cela aide à la migration, et je pense que la plupart des distributions ne voient toujours pas de raison de supprimer le support. isolatevisait clairement à imiter le fonctionnement des niveaux d'exécution, mais il existe divers cas de méchanceté. Je recommande fortement d'ignorer toutes les instructions à isolate runlevel5.targetou même isolate graphical.target. Exemple de cas de bord: github.com/systemd/systemd/issues/6505
sourcejedi

0

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 .

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.