Tout ce que vous voulez savoir se trouve probablement ici sur les pages " Debate Init System To Use " que le projet Debian a rassemblées pour prendre la décision de quel initsystem utiliser. Dans cette page est un lien séparé vers chacun des choix des initsystems.
Pour une introduction sur Systemd, cette page contient à peu près tout ce que vous devez savoir pour commencer, RHEL7: Comment démarrer avec Systemd .
Ressources supplémentaires que j'ai trouvées utiles pour mieux comprendre les 2 principaux choix. J'ai également lu les pages Wikipédia sur les technologies respectives:
Le projet Gentoo maintient également une belle comparaison de certaines des fonctionnalités clés à travers les différents initsytems:
Ma réponse à vos questions
Q # 1: Comment systemd se compare-t-il aux autres systèmes init?
C'est une question très difficile à résoudre dans l'espace d'une réponse SE donc je préfère m'en remettre aux différentes sources que j'ai référencées ci-dessus. Je dirai ceci cependant. En lisant la plupart des articles sur systemd
les alternatives, il essaie de traiter de nombreux aspects de ce qui était déficient dans les outils précédents utilisés pour démarrer des services sur des systèmes Linux. Il a une conception très bien pensée et essaie de le fournir de manière très modulaire.
composants systemd
Donc, l'OMI, je dirais qu'il se compare très favorablement à la fois en termes d'effort dans sa conception, d'exécution de cette conception et d'adoption de celle-ci par plusieurs grandes distributions Linux.
Q # 2: Qu'est-ce qui le distingue - que peut-il faire que les autres systèmes init ne peuvent pas faire?
Il y a beaucoup de choses que sytemd
les autres systèmes peuvent faire. Probablement 3 de ses caractéristiques les plus fortes sont:
- Enregistrement
- Limitation des ressources
- Gérer les démons qui bifurquent
1. journalisation
Sur le front de l'exploitation forestière, systemd
a institué un nouveau système d'enregistrement appelé le "Journal", le service est appelé systemd-journald.service
. Il s'agit de son propre sujet, vous pouvez en savoir plus ici dans cet article intitulé: Présentation du Journal . Voici un exemple d'un utilisateur, "harald", qui se connecte.
_SERVICE=systemd-logind.service
MESSAGE=User harald logged in
MESSAGE_ID=422bc3d271414bc8bc9570f222f24a9
_EXE=/lib/systemd/systemd-logind
_COMM=systemd-logind
_CMDLINE=/lib/systemd/systemd-logind
_PID=4711
_UID=0
_GID=0
_SYSTEMD_CGROUP=/system/systemd-logind.service
_CGROUPS=cpu:/system/systemd-logind.service
PRIORITY=6
_BOOT_ID=422bc3d271414bc8bc95870f222f24a9
_MACHINE_ID=c686f3b205dd48e0b43ceb6eda479721
_HOSTNAME=waldi
LOGIN_USER=500
2 & 3. Limitation des ressources et démons qui bifurquent
systemd
utilise ici une nouvelle approche consistant à utiliser cgroups
à la fois pour contenir et limiter les ressources de tous les services qui nécessitent une fourche ou une limitation de l'accès aux ressources.
extrait
Systemd a une solution très intelligente au problème du suivi des démons qui se bifurquent, ce qui arrive par hasard pour gérer la limitation des ressources en même temps. Là où Upstart utilise ptrace pour regarder le forking, systemd exécute chaque démon dans un groupe de contrôle (nécessite Linux 2.6.24 ou plus récent) dont il ne peut pas s'échapper avec n'importe quel volume de forking. Cela permet de limiter facilement les ressources, à la fois pour les démons forking et non-forking, car les groupes de contrôle ont été créés pour ce genre de chose.
Source: Daemon Showdown: Upstart vs Runit vs Systemd vs Circus vs God
Q # 3: Y a - t-il quelque chose à perdre en passant d'un autre système d'initialisation à celui-ci?
La plus grande mise en garde contre le passage à systemd via Upstart ou sysV init est probablement d'avoir à accepter de nombreuses nouvelles complexités. Systemd a beaucoup de pièces mobiles et est extrêmement riche en fonctionnalités et avec ces capacités supplémentaires, vous passerez probablement beaucoup de temps à comprendre comment tout cela fonctionne.
Q # 4: Comment l'administration de systemd se compare-t-elle aux autres?
Comme indiqué dans ma réponse ci-dessus à Q # 3. Je réitère ici encore. Là où sysV init était assez trivial pour apprendre à gérer et à naviguer en quelques heures à quelques jours, Upstart vous mettra probablement une semaine ou plus pour vous mettre à jour, tandis que systemd vous prendra probablement beaucoup plus de temps, je prévois d'en prendre plusieurs semaines pour acquérir suffisamment de connaissances superficielles à ce sujet, où je pourrai à la fois produire mes propres .service
fichiers, pour arrêter / démarrer des services avec la même facilité que j'apprécie maintenant avec sysV init.
Les références