Quels sont les avantages / inconvénients d'Upstart et de systemd?

183

Il semble que systemd soit le nouveau système init chaud du bloc, comme Upstart l’ était il ya quelques années. Quels sont les avantages / inconvénients pour chacun? En outre, comment se compare-t-il aux autres systèmes init?

init upstart systemd Tshepang
la source
4
@keith IIRC OpenRC utilise simplement SysV, l'avantage est une collection bien conçu des scripts de démarrage qui utilisent des composants communs et sont portables ( ce qui signifie le travail sur une coquille) Il est un bon nettoyage, mais pas vraiment une nouvelle initd
xenoterracide
@ xeno C'est le cas, mais vous ne pouvez pas vraiment le dire. il n'y a pas du tout de liens symboliques rcX.d ou [KS]. En fait, sysv init lui-même est assez flexible et les niveaux d'exécution ne sont pas vraiment utilisés de la manière habituelle.
Keith
Bien que l'auteur de ce blog soit contre systemd, je suggère de lui donner une lecture. Il passe en revue les avantages et les inconvénients de systemd et de BSD init. textplain.net/blog/2015/…
Peschke
1
Veuillez consulter la mise à jour 2016 unix.stackexchange.com/a/287282/49091 également.
igaurav
Les avantages supposés de systemd ne compenseront pas, dans un siècle, les coûts déjà supportés par le monde pour mettre cela en œuvre. Chaque minute, chaque heure ou chaque jour passé par un administrateur Unix à traiter ces déchets doit déjà représenter des milliards et pour quels avantages réels autres que quelques cloches et sifflets?
Waslap

Réponses:

90

Mise à jour 2016

La plupart des réponses ici datent de cinq ans, il est donc temps de faire quelques mises à jour.

Ubuntu utilisait upstart par défaut mais ils l’ont abandonné l’année dernière au profit de systemd - voir:

À cause de cela, il y a un bel article Systemd for Upstart Users sur le wiki Ubuntu - une comparaison très détaillée entre upstart et systemd et un guide de transition de upstart à systemd.

(Notez que selon le wiki Ubuntu, vous pouvez toujours lancer les versions actuelles d'Ubuntu par défaut en installant le upstart-sysvet en cours d'exécution, sudo update-initramfs -umais compte tenu de la portée du projet systemd, je ne sais pas comment cela fonctionne dans la pratique, ni si systemd est ou non possible de désinstaller.)

La plupart des informations contenues dans les sections Commandes et scripts ci-dessous sont adaptées de certains exemples utilisés dans cet article (sous une licence pratique, tout comme les contributions d’utilisateur de Stack Exchange sous la licence Creative Commons Attribution-ShareAlike 3.0 ).

Voici une comparaison rapide des commandes courantes et des scripts simples, voir les sections ci-dessous pour une explication détaillée. Cette réponse compare l'ancien comportement des systèmes basés sur Upstart avec le nouveau comportement des systèmes basés sur systemd, comme indiqué dans la question, mais notez que les commandes marquées comme "Upstart" ne sont pas nécessairement spécifiques à Upstart - il s'agit souvent de commandes sont communs à tous les systèmes Linux et Unix non-système.

Les commandes

En cours d'exécution su:

  • parvenu: su
  • systemd: machinectl shell

(voir la section "remplacement de la commande su" ci-dessous)

Écran en cours d'exécution:

  • parvenu: screen
  • systemd: systemd-run --user --scope screen

(voir la section "Suppression inattendue de processus en arrière-plan" ci-dessous)

Lancer tmux:

  • parvenu: tmux
  • systemd: systemd-run --user --scope tmux

(voir la section "Suppression inattendue de processus en arrière-plan" ci-dessous)

Début d'emploi foo:

  • parvenu: start foo
  • systemd: systemctl start foo

Arrêt du travail foo:

  • parvenu: stop foo
  • systemd: systemctl stop foo

Relancer le travail foo:

  • parvenu: restart foo
  • systemd: systemctl restart foo

Liste des emplois:

  • parvenu: initctl list
  • systemd: systemctl status

Vérification de la configuration du travail foo:

  • parvenu: init-checkconf /etc/init/foo.conf
  • systemd: systemd-analyze verify /lib/systemd/system/foo.service

Liste des variables d'environnement du travail:

  • parvenu: initctl list-env
  • systemd: systemctl show-environment

Définition de la variable d'environnement du travail:

  • parvenu: initctl set-env foo=bar
  • systemd: systemctl set-environment foo=bar

Suppression de la variable d'environnement du travail:

  • parvenu: initctl unset-env foo
  • systemd: systemctl unset-environment foo

Les journaux

En amont, les journaux sont des fichiers texte normaux dans le répertoire / var / log / upstart, vous pouvez donc les traiter comme d'habitude:

cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log

Dans systemd, les journaux sont stockés dans un format binaire interne (et non sous forme de fichiers texte). Vous devez donc utiliser la journalctlcommande pour y accéder:

sudo journalctl -u foo
sudo journalctl -u foo -f

Les scripts

Exemple de script de démarrage écrit en /etc/init/foo.conf:

description "Job that runs the foo daemon"
start on runlevel [2345]
stop on runlevel [016]
env statedir=/var/cache/foo
pre-start exec mkdir -p $statedir
exec /usr/bin/foo-daemon --arg1 "hello world" --statedir $statedir

Exemple de script systemd écrit en /lib/systemd/system/foo.service:

[Unit]
Description=Job that runs the foo daemon
Documentation=man:foo(1)
[Service]
Type=forking
Environment=statedir=/var/cache/foo
ExecStartPre=/usr/bin/mkdir -p ${statedir}
ExecStart=/usr/bin/foo-daemon --arg1 "hello world" --statedir ${statedir}
[Install]
WantedBy=multi-user.target

remplacement de la commande su

Un suremplacement de commande a été fusionné dans systemd dans la demande d'extraction n ° 1022:

parce que, selon Lennart Poettering, "su est vraiment un concept cassé" .

Il explique que "vous pouvez utiliser su et sudo comme auparavant, mais ne vous attendez pas à ce que cela fonctionne pleinement " .

Le moyen officiel pour obtenir un sucomportement semblable à celui-ci est maintenant:

machinectl shell

Lennart Poettering a expliqué plus en détail le numéro 825:

"Eh bien, il y a eu de longues discussions à ce sujet, mais le problème est que ce que su est censé faire n'est pas très clair. [...] Longue histoire courte: le su est vraiment un concept cassé. Il vous donnera une sorte de coquille , et c’est bien de l’utiliser pour cela, mais ce n’est pas un login complet, et ne devrait pas être confondu avec un. " - Lennart Poettering

Voir également:

Élimination inattendue des processus d'arrière-plan

Des commandes comme:

ne fonctionne plus comme prévu . Par exemple, nohupune commande POSIX permet de s’assurer que le processus continue de s’exécuter une fois que vous vous êtes déconnecté de votre session. Cela ne fonctionne plus sur systemd. Des programmes tels que screenet tmuxdoivent être invoqués de manière spéciale, sinon les processus que vous exécutez avec eux seront tués (sans que ces processus soient tués, c'est généralement la raison principale de l'exécution de screen ou de tmux).

Ce n'est pas une erreur, c'est une décision délibérée, il est donc peu probable qu'il soit corrigé à l'avenir. Voici ce que Lennart Poettering a dit à ce sujet:

À mon avis, il était en fait assez étrange pour UNIX de laisser par défaut un code utilisateur arbitraire sans restriction après la déconnexion. Depuis de nombreuses années, de nombreux utilisateurs de systèmes d’exploitation discutent du fait que cela devrait être possible, mais ce n’est certainement pas le cas par défaut, mais personne n’a osé jusqu’à présent basculer le commutateur pour le transformer en option par défaut. Ne pas nettoyer les sessions des utilisateurs après la déconnexion n’est pas seulement vilain et quelque peu furtif, mais aussi un problème de sécurité. Enfin, systemd 230 a finalement basculé le commutateur et enfin, par défaut, il nettoie tout correctement lorsque l'utilisateur se déconnecte.

Pour plus d'informations, voir:

Concept de démarrage de haut niveau

D'une certaine manière, systemd fonctionne à l'envers: dans les tâches qui démarrent, elles commencent dès qu'elles le peuvent et dans les tâches systemd, elles doivent être lancées dès qu'elles le doivent. À la fin de la journée, les deux systèmes peuvent lancer les mêmes tâches et dans le même ordre, mais vous pensez que cela va dans une direction opposée pour ainsi dire.

Voici comment Systemd for Upstart Users l' explique:

Le modèle de démarrage (processus) de Upstart est "basé sur des événements gloutons", c'est-à-dire que tous les travaux disponibles dont les événements de démarrage se produisent sont démarrés le plus tôt possible. Au démarrage, upstart synthétise certains événements initiaux tels que le démarrage ou rcS en tant que "racine de l'arborescence", les services les plus anciens démarrent sur ces derniers et les services ultérieurs démarrant lorsque les premiers sont en cours d'exécution. Un nouveau travail doit simplement installer son fichier de configuration dans / etc / init / pour devenir actif.

Le modèle de systemd pour les processus de démarrage (unités) est "basé sur la dépendance paresseuse", c'est-à-dire qu'une unité ne démarrera que si et quand une autre unité de départ en dépend. Au démarrage, systemd démarre une "unité racine" (default.target, qui peut être écrasée dans grub), qui ensuite se développe de manière transitoire et démarre ses dépendances. Une nouvelle unité doit s'ajouter elle-même en tant que dépendance d'une unité de la séquence d'amorçage (généralement plusieurs utilisateurs multiples) pour devenir active.

Utilisation dans les distributions

Maintenant, quelques données récentes selon Wikipedia:

Distributions utilisant upstart par défaut:

Distributions utilisant systemd par défaut:

(Voir Wikipedia pour des informations à jour)

Distributions n'utilisant ni Upstart ni systemd:

Controverse

Dans le passé, un fork de Debian a été proposé pour éviter systemd . Le devuan GNU + Linux a été créé - une fourchette de Debian sans systemd (grâce à fpmurphy1 pour le signaler dans les commentaires).

Pour plus d'informations sur cette controverse, voir:

Comme beaucoup d'entre vous le savent peut-être déjà, le vote Init GR sur Debian promu par Ian Jackson n'était pas utile pour protéger l'héritage de Debian et ses utilisateurs contre l'avalanche systémique.

Cette situation risque de verrouiller les dépendances système, ce qui menace de fait la liberté de développement et a de graves conséquences pour Debian, son amont et son aval.

Le CTTE a réussi à échanger une dépendance et à nous faire gagner du temps sur une installation subtile de systemd sur sysvinit, mais même ce processus a été épuisant et dramatique. En fin de compte, Ian Jackson a démissionné il y a une semaine. [...]

Je quitte le Comité technique avec effet immédiat.

S'il est important que les points de vue des 30 à 40% du projet qui sont d'accord avec moi continuent à être représentés au sein du TC, je suis moi-même clairement trop controversé pour pouvoir le faire. Je devrais me retirer pour tenter de réduire le degré de personnalisation des conversations sur la gouvernance du projet. [...]

Devuan est né d'une controverse sur la décision d'utiliser Debian comme système d'initialisation par défaut. La position officielle de Debian sur systemd regorge d’affirmations que d’ autres ont démystifiées . Les lecteurs intéressés peuvent continuer à discuter de ce sujet brûlant dans la controverse The systemd . Cependant, nous vous encourageons à garder votre tête froide et votre voix civile. Chez Devuan, nous sommes plus intéressés par une mauvaise programmation que par le passé. [...]

Quelques sites et articles consacrés à la controverse systémique ont été créés:

Il y a beaucoup de discussions intéressantes sur Hacker News:

Des tendances similaires dans d'autres distributions peuvent également être observées:

Philosophie

upstart suit la philosophie Unix de DOTADIW - "Fais un truc et fais-le bien." C'est un remplacement pour le démon d'init traditionnel. Il ne fait rien d'autre que le démarrage et l'arrêt des services. Les autres tâches sont déléguées à d'autres sous-systèmes spécialisés.

Systemd fait beaucoup plus que cela. Outre le démarrage et l'arrêt des services, il gère également les mots de passe, les connexions, les terminaux, la gestion de l'alimentation, les réinitialisations d'usine, le traitement des journaux, les points de montage du système de fichiers, la mise en réseau et bien plus encore - voir le fichier NEWS pour quelques-unes des fonctionnalités.

Plans d'expansion

Selon A Perspective for systemd, ce qui a été réalisé et ce qui nous attend, présentation de Lennart Poettering en 2014 sur GNOME.asia, voici les principaux objectifs de systemd, les domaines déjà couverts et ceux en cours:

objectifs systemd:

Nos objectifs

  • Transformer Linux d’un sac de bits en un système d’exploitation polyvalent concurrentiel.
  • Construire le système d'exploitation de nouvelle génération de l'Internet Unifier les différences inutiles entre les distributions

  • Ramener l'innovation au coeur du système d'exploitation

  • Bureau, Serveur, Conteneur, Embarqué, Mobile, Cloud, Cluster,. . . Ces zones sont plus proches que vous ne le pensez

  • Réduire la complexité de l'administrateur, la fiabilité sans supervision
  • Tout introspectable
  • La découverte automatique, plug and play est la clé
  • Nous réparons les choses là où elles sont brisées, nous ne les collons jamais

Zones déjà couvertes:

Ce que nous couvrons déjà:

système d'initialisation, journalisation du journal, gestion des connexions, gestion des périphériques, gestion des fichiers temporaires et volatiles, enregistrement au format binaire, sauvegarde / restauration du rétroéclairage, sauvegarde / restauration de rfkill, bootchart, readahead, configuration du stockage chiffré, découverte de la partition EFI / GPT, machine virtuelle / conteneur enregistrement, gestion minimale des conteneurs, gestion des noms d 'hôte, gestion des paramètres régionaux, gestion du temps, gestion des semences aléatoires, gestion des variables sysctl, gestion de la console,. . .

Travaux en cours:

Sur quoi nous travaillons:

  • la gestion du réseau
  • systemd-networkd
  • Cache DNS local, répondeur mDNS, répondeur LLMNR, vérification DNSSEC
  • IPC dans le noyau
  • kdbus, sd-bus
  • Synchronisation de l'heure avec NTP
  • systemd-timesyncd
  • Plus d'intégration avec les conteneurs
  • Sandboxing des services
  • Sandboxing des applications
  • Format d'image du système d'exploitation
  • Format d'image du conteneur
  • Format d'image d'application
  • GPT avec découverte automatique
  • Systèmes sans état, systèmes instantanés, réinitialisation d'usine
  • / usr est l'OS
  • / etc est la configuration (optionnelle)
  • / var est l'état (optionnel)
  • Initialisation et mises à jour du noeud atomique
  • Intégration avec le cloud
  • Gestion des services sur les nœuds
  • Images de système d'exploitation vérifiables
  • Tout le chemin au firmware
  • Chargement de démarrage

Portée de cette réponse

Comme le note fpmurphy1 dans les commentaires, "il convient de souligner que systemd a élargi son champ de travail au cours des années, bien au-delà du simple démarrage du système".

J'ai essayé d'inclure la plupart des informations pertinentes ici. Ici, je compare les fonctionnalités communes d'Upstart et de systemd lorsqu'elles sont utilisées en tant que systèmes init, comme indiqué dans la question. Je mentionne uniquement les fonctionnalités de systemd qui dépassent le cadre d'un système init car elles ne peuvent pas être comparées à Startup, mais leur présence est importante. comprendre la différence entre ces deux projets. La documentation pertinente doit être vérifiée pour plus d'informations.

Plus d'informations

Plus d'informations peuvent être trouvées à:

Suppléments

L’ équipe LinOxide a créé une feuille de mise à jour Linux Systemd vs SysV Init .

rsp
la source
4
... et une telle fourchette de Debian a eu lieu. Devuan GNU + Linux est un fork de Debian sans systemd.
fpmurphy
2
Il convient de noter que systemd a étendu son champ de travail au fil des ans, au-delà du simple démarrage du système.
fpmurphy
1
Poste remarquable et extrêmement utile à Cent guy. Merci d'avoir pris le temps monsieur !!!
origine1tech
4
@ronsmith service <foo> start/stop/restart/statusfonctionne toujours très bien. Comme la plupart des logiciels unix, systemd assure la compatibilité des commandes avec les valeurs par défaut bien connues.
Shadur
2
Très bonne réponse. Un point cependant: les systèmes d'exploitation BSD ne sont pas des distributions Linux: ce sont des systèmes d'exploitation Unix différents avec leur propre noyau.
Giorgio
68

Upstart et systemd tentent tous deux de résoudre certains des problèmes liés aux limitations du système SysV init traditionnel. Par exemple, certains services doivent démarrer après d'autres services (par exemple, vous ne pouvez pas monter de systèmes de fichiers NFS tant que le réseau n'est pas en cours d'exécution), mais le seul moyen de gérer cela dans SysV consiste à définir les liens dans le répertoire rc # .d tel que l'un est devant l'autre. Ajoutez à cela, vous devrez peut-être tout ré-numéroter ultérieurement lorsque des dépendances seront ajoutées ou modifiées. Upstart et Systemd ont des paramètres plus intelligents pour définir les exigences. En outre, il y a le problème avec le fait que tout est un script shell et que tout le monde n'écrit pas les meilleurs scripts d'initialisation. Cela influe également sur la vitesse de la mise en route.

Je peux voir certains des avantages de systemd:

  • Chaque processus démarré obtient son propre groupe de contrôle ou un groupe de contrôle particulier.
  • La pré-création de sockets et de descripteurs de fichier pour les services, similaire à celle de xinetd pour ses services, permet aux services dépendants de démarrer plus rapidement. Par exemple, systemd gardera ouvert le descripteur de fichier pour / dev / log pour syslog, et les messages envoyés ultérieurement à / dev / log verront leurs messages mis en mémoire tampon jusqu'à ce que syslogd soit prêt à prendre le relais.
  • Moins de processus sont exécutés pour démarrer un service. Cela signifie que vous n'écrivez pas de script shell pour démarrer votre service. Cela peut être une amélioration de la vitesse, et (IMO) quelque chose de plus facile à configurer en premier lieu.

Je connais un inconvénient: pour tirer parti de la préallocation socket / FH de systemd, de nombreux démons devront être corrigés pour que FH leur soit transmis par systemd.

jsbillings
la source
13
PulseAudio est un système sonore très décrié ( pulseaudio.org ), écrit à l'origine par Lennart Poettering, l'auteur de systemd. Je faisais surtout une blague ici, car je connais plusieurs personnes qui aiment se plaindre de pulseaudio et je suis sûre qu’elles se plaindraient aussi de systemd. Honnêtement, je n'ai pas eu de problème avec systemd ou pulseaudio.
Jsbillings
4
C'est presque un pin pour les nombreux fjords de Plan9 ... tout est un fichier.
dhchdhd
4
Pour être honnête, pulseaudio était une solution à un problème inexistant. Il n’ya rien que PA puisse faire que ALSA ne puisse faire, et j’ai entendu maintes et maintes fois des gens avoir des problèmes avec PA.
WhyNotHugo
3
Deux inconvénients système que vous avez manqués: (1) tous les scripts de démarrage doivent être réécrits. (2) il y a beaucoup moins de compatibilité avec les systèmes d'exploitation autres que Linux (tels que les BSD, par exemple).
WhyNotHugo
8
Tout simplement génial. S'il vous plaît jeter un oeil à 0pointer.de/blog/projects/the-biggest-myths . J'ai été témoin de la croissance de systemd et peux attester que la plupart des critiques formulées ici sont totalement sans fondement. Au lien, vous trouverez coup par coup une réfutation raisonnée .
vonbrand
30

Saw systemdmentionné sur Arch General ML aujourd'hui. Alors lisez sur le sujet. H Online, comme toujours, est une excellente source de technologie Linux et c’est là que j’ai trouvé mon lieu de départ pour faire des recherches sur Systemd en tant qu’alternative SysV Init et Upstart . Cependant, l'article en ligne de H Online (dans ce cas) n'est pas une lecture très utile, mais son véritable usage est de donner des liens vers les lectures utiles.

La vraie réponse est dans l' annonce de systemd . Ce qui donne quelques points cruciaux sur ce qui ne va pas avec SysV initd et ce que les nouveaux systèmes doivent faire

  • Pour commencer moins.
  • Et pour commencer plus en parallèle.

Son principal objectif semble être de démarrer les services uniquement selon leurs besoins et de démarrer un socket pour ce service, afin que le service qui en a besoin puisse se connecter au socket créé bien avant que le démon ne soit entièrement en ligne. Apparemment, un socket conservera une petite quantité de données en mémoire tampon, ce qui signifie qu'aucune donnée ne sera perdue pendant le décalage, elle sera traitée dès que le démon sera en ligne.

Une autre partie du plan semble être de ne pas sérialiser les systèmes de fichiers, mais plutôt de monter ceux-ci à la demande, pour ne pas attendre votre /home/, etc. (ne pas confondre avec /etc), et / ou fsckquand vous pourriez être les démons de démarrage en tant que /et /var/etc, sont déjà montés. Il a dit qu'il allait utiliser des autofs à cette fin.

Il a également pour objectif de créer des .desktopdescripteurs d'initiation de style en remplacement des scripts. Cela évitera des tonnes de shprocessus lents et encore plus de fourches de processus provenant d'éléments similaires sedou grepsouvent utilisés dans les scripts shell.

Ils prévoient également de ne pas démarrer certains services tant qu'ils ne sont pas sollicités, et peut-être même de les arrêter s'ils ne sont plus nécessaires. Le module Bluetooth et le démon ne sont nécessaires que lorsque vous utilisez un périphérique Bluetooth, par exemple. Un autre exemple donné est le démon ssh. C'est le genre de chose dont inetd est capable. Personnellement, je ne suis pas sûr d’apprécier cela, car cela pourrait signifier une latence quand j’en ai besoin, et dans le cas de ssh, cela signifie une possible vulnérabilité de la sécurité. Si mon inetd était compromis, l’ensemble du système le serait. Cependant, on m'a informé que l'utilisation de cette méthode pour enfreindre ce système est infaisable et que, si je le souhaite, je peux désactiver cette fonctionnalité par service et par d'autres moyens.

Une autre caractéristique semble être la possibilité de démarrer en fonction d'événements temporels, soit à intervalles réguliers, soit à une certaine heure. Ceci est similaire à quoi crondet à atdfaire maintenant. Bien que l’on m’ait dit que cela ne supporterait pas l’utilisateur "cron". Personnellement, cela semble être la chose la plus inutile. Je pense que cela a été écrit / pensé par des personnes qui ne travaillent pas dans des environnements multi-utilisateurs. Il n'y a pas vraiment de raison d'utiliser cron si vous êtes le seul utilisateur du système, mis à part le fait que vous ne vous exécutez pas en tant que root. Je travaille quotidiennement sur des systèmes multi-utilisateurs, et la règle consiste toujours à exécuter des scripts utilisateur en tant qu'utilisateur. Mais peut-être que je n'ai pas la clairvoyance dont ils disposent, et que cela ne pourra en aucun cas empêcher de courir crondou ne pas courir atd, de manière à ne blesser que les développeurs, je suppose.

Le gros inconvénient de systemd est que certains démons devront être modifiés pour en tirer le meilleur parti. Ils fonctionneront maintenant, mais ils fonctionneraient mieux s'ils étaient écrits spécifiquement pour son modèle de socket.

Il semble que le système des événements pose le problème principal des peuples du monde, et qu’ils pensent que cela n’a pas de sens ou n’est pas inutile. Peut-être que leurs mots le disent mieux.

Ou pour le dire plus simplement: le fait que l'utilisateur vienne de démarrer D-Bus ne signifie en aucun cas que NetworkManager doit également être démarré (mais c'est ce que Upstart ferait). C'est l'inverse qui se produit: lorsque l'utilisateur demande NetworkManager, cela indique clairement que D-Bus doit également être démarré (ce qui est certainement ce à quoi la plupart des utilisateurs s'attendent, n'est-ce pas?).
Un bon système d’initialisation ne devrait démarrer que ce qui est nécessaire, et cela à la demande. Paresseusement ou en parallèle et à l'avance. Cependant, il ne faut pas commencer plus que nécessaire, en particulier pas tout ce qui est installé et qui pourrait utiliser ce service.

Comme je l'ai déjà dit, cela fait l'objet d'une discussion beaucoup plus détaillée dans l' annonce de systemd .

xénoterracide
la source
désolé mais l'annonce est comme un livre. Je dois lire et grok, avant que je puisse vraiment inclure plus ici.
xenoterracide
2
Comment est-ce mieux que la réponse de @ John? Est-ce un espace réservé? Une promo de H Online ?
Tshepang
1
@tshepang et bien il relie en fait à l'annonce de system d et le contenu en ligne h contient des liens vers d'autres liens intéressants. c'est une longue lecture fastidieuse. J'ajouterai peut-être plus une fois que je l'aurai corrigée… ce n'est pas un sujet simple . Quand j'ai écrit ceci, j'ai pensé que vous voudriez peut-être commencer à lire plus tôt que plus tard. mais n'hésitez pas à me modérer. La réponse de @ jsbillings est certainement décente, et meilleure que la mienne jusqu’à présent. mais pas aussi bon que de lire l'annonce elle
xenoterracide
@tshepang, je vais probablement en ajouter plus demain, après le coucher. En ligne, c’était juste le fait que je sois un bon journaliste et que je cite mes sources.
xenoterracide
@tshepang. J'ai mis à jour ma réponse. Je suis sûr que j'en aurai terminé à moins que les personnes utiles sur irc: //frenode.net/systemd décident qu'elles souhaitent proposer une correction quelconque.
xenoterracide
11

La plupart des gens ont oublié l’organisation des processus dans les groupes de contrôle .

Donc, si systemd a démarré une chose, il la mettra dans son propre groupe de contrôle et il n'y a pas de moyen (non privilégié) permettant au processus d'échapper à ce groupe de contrôle. Voici les conséquences de cela:

  • Un administrateur d’un grand système comptant de nombreux utilisateurs dispose de nouveaux moyens efficaces d’identifier les utilisateurs / processus malveillants.
  • Les priorités pour la planification de l'UC peuvent être mieux déterminées comme le fait le "correctif Wondergroup automatique" .
Tshepang
la source
8

Pour un aperçu très détaillé de systemd, en commençant par les premiers projets de conception (et une critique détaillée des systèmes init existants, y compris upstart, et de la façon dont systemd propose de les corriger), allez à sa page d'accueil . Au fil du temps, plusieurs articles sur la startup ont été publiés dans LWN . Sachez simplement que toute mention de systemd (ou pulseaudio) y déclenche une guerre de flammes sans fin.

IMVHO (et en tant qu'utilisateur de Fedora), j'en suis très heureux. Quelque chose dans cette ligne était attendu depuis longtemps pour gérer la complexité des systèmes Linux actuels. Fedora a utilisé upstart pendant un certain temps, mais il n’a jamais quitté le stade de remplacement de sysvinit, en exécutant principalement des scripts init inchangés. Sa promesse de simplifier la configuration de démarrage se fait au prix de nouveauconfigurer manuellement les interdépendances, et cela ne fonctionne tout simplement pas. systemd représente les dépendances par lui-même (ou permet simplement de commencer des choses sans tenir compte des dépendances, elles se trient elles-mêmes). Un autre gros avantage (certains disent que c'est un inconvénient majeur) est qu'elle exploite à fond les fonctionnalités spécifiques à Linux (notamment les groupes de contrôle permettent d'isoler un démon et tous ses descendants, il est donc facile de surveiller, limiter les ressources ou de les tuer un groupe, il y en a beaucoup d'autres).

vonbrand
la source
3

Journalisation - Systemd ressemble littéralement au dossier WinSXS en ce qui concerne la journalisation. Il crée des copies de copies à moins que vous ne supprimiez ou réduisiez manuellement la taille du fichier que le lecteur rongerait sans cesse. Je l'appelle les cookies de chargeur de démarrage.

Bert
la source
faux. Ce ne sont pas des copies et sa limite est configurable. freedesktop.org/software/systemd/man/journald.conf.html
pal