web-dev-qa-db-fra.com

Raison pour passer de upstart à systemd?

La modification la plus importante fournie avec Ubuntu 15.04 est le passage d’upstart à systemd en tant que valeur par défaut pour la gestion du démarrage et du démarrage du service système.

Quelqu'un pourrait-il expliquer de manière adéquate à un utilisateur non technique comment et si cela nous affecte du tout? Et pourquoi c'est important?

upstart15.04systemd
28
Nikos Grigoriadis

Les utilisateurs Layman ne devraient remarquer aucun changement, de par leur conception. C'est un système init, pas quelque chose que les utilisateurs interagissent traditionnellement. Il devrait complètement remplacer les fonctionnalités fournies par Upstart — et faire quelques choses supplémentaires — mais le seul moment où un utilisateur non technique verra voir c'est quand il se passera mal.

Les utilisateurs, les administrateurs système et les développeurs qui ont activement utilisé et développé Upstart sont ceux qui ont besoin de résoudre les problèmes. Il y a n document de migration sur le wiki Ubunt pour aider les développeurs à convertir leurs scripts d'initialisation, mais les utilisateurs et les sysops peuvent continuer à utiliser Upstart en conservant la version 14.04 (prise en charge jusqu'en 2019).

La raison et la raison du changement ne venaient vraiment pas d'Ubuntu. Canonical était assez satisfait d'Upstart (leur projet), mais de nombreux utilisateurs de Debian souhaitaient passer à un moteur d'initialisation moderne pour obtenir une meilleure concurrence au démarrage et une meilleure fonctionnalité de surveillance pour tous les services.

Cela signifiait ne lutte entre différentes options (les raisonnements) et systemd finit par l'emporter.

Canonical s'est associé à Debian car c'est le plus simple et probablement le meilleur. Ils peuvent abandonner un projet et ne se battent pas en amont. Cela nous aligne également sur d'autres distributions (Red Hat, Fedora, etc.) qui migrent également vers systemd. Plus de concentration et moins de duplication d'effort.

tl; dr Pour une personne non technique, cela ne devrait pas vous affecter du tout. Pour Ubuntu, cela devrait signifier moins de travail et un meilleur système d’initialisation.

29
Oli

Quelqu'un pourrait-il expliquer de manière adéquate à un utilisateur non technique comment et si cela nous affecte du tout?

En théorie, cela ne devrait pas affecter l'utilisateur final non technique qui n'intervient pas dans les détails du fonctionnement réel du système. En pratique, il y a beaucoup de choses que vous allez voir.

Voici une liste incomplète:

  • Si vous aviez des logiciels complémentaires qui utilisaient des fichiers de définition de travail en amont pour démarrer des programmes, ils ne fonctionneraient plus. Vous devrez installer (et peut-être écrire mais plus généralement simplement supprimer quelqu'un qui a déjà écrit) des fichiers systemd nité de service. Exemple: https://askubuntu.com/questions/613785
  • Diverses hypothèses de conception formulées par les développeurs Systemd sur des éléments tels que la gestion de l'alimentation entraînent des valeurs par défaut incompatibles avec celles auxquelles vous vous êtes habitués. Les développeurs de systemd ont des idées bien définies sur ce qui devrait se passer en réponse aux commutateurs du couvercle sur les ordinateurs portables , par exemple.
  • Si vous utilisez le pilote d'affichage propriétaire nvidia, plusieurs décisions de conception dans systemd vous concernent. Exemple: https://askubuntu.com/questions/61377
  • Cela n’a pas vraiment de sens quand on vient de l’arrivée, car les utilisateurs d’Ubuntu ont une page de manuel qui le leur dit depuis quelques années, mais je le mentionne pour les utilisateurs non-Ubuntu qui pourraient lire ceci: Autres utilisateurs de systèmes d’exploitation Linux venant de System 5 init + rc sont mordus par le fait que systemd est seulement ​​rétrocompatible avec System 5 rc. À l'instar de Upstart et de la plupart des autres systèmes, il déclare ne fournit aucune compatibilité avec le Système 5 init et son fichier de configuration /etc/inittab. .

    Ainsi, les personnes qui ont suivi les conseils des quelque 30 ans de conseils "Eh bien, vous pouvez simplement éditer ceci dans /etc/inittab…", ou les personnes qui utilisent les logiciels qui ont suivi ces conseils ont maintenant des logiciels qui ne démarrent pas au démarrage. Exemple: https://unix.stackexchange.com/a/196197/5132

  • Vous ne pouvez pas accéder à mode mono-utilisateur via la commande systemd shutdown, comme avec les commandes précédentes shutdown. Mis à part le fait qu'il s'appelle mode de secours dans le jargon de systemd, le mode de secours n'est pas considéré comme un état d'arrêt dans la vision du monde de systemd. Il est considéré comme un état en cours. shutdown now mettra la machine hors tension. C'est systemctl rescue pour atteindre le mode mono-utilisateur dans le monde systemd. Lectures supplémentaires: https://unix.stackexchange.com/a/196471/5132
  • Suite à ce dernier sujet: Si vous n’avez pas déjà jeté l’idée de niveaux d’exécution, le moment est venu de le faire. Lecture ultérieure: https://unix.stackexchange.com/a/196014/5132
  • Vous devrez faire attention à suivre les conseils généraux de systemd trouvés par la navigation sur Internet WWW aléatoire, parce que vous "savez" que "tout est systemd maintenant". Vous allez voir des gens parler de l'exécution de commandes avec l'option --user dans systemctl. Cela ne s'applique pas (encore) à Ubuntu. upstart et systemd diffèrent considérablement dans ce domaine, et Ubuntu version 15 utilise toujours upstart par session plutôt qu'un systemd par instance d'utilisateur. Ainsi, https://superuser.com/a/860598/38062 ne s'appliquera pas, par exemple. ☺
18
JdeBP

Comme d’autres l’ont déjà fait remarquer ici, en théorie, cela ne devrait pas affecter l’utilisateur final non technique - et en théorie, il n’ya pas de différence entre théorie et pratique, mais dans la pratique.

Clarification

Je pense que peu de choses affichées ici nécessitent des éclaircissements:

C'est un système init, pas quelque chose que les utilisateurs interagissent traditionnellement.

C'était le cas avec SysV init et Upstart, mais ce n'est plus le cas avec systemd. Cela fait beaucoup de choses avec lesquelles les utilisateurs interagissent traditionnellement:

Il devrait complètement remplacer les fonctionnalités fournies par Upstart - et faire quelques choses supplémentaires

Deux choses à clarifier - d’abord sur le remplacement complet de Upstart:

Pas de scripts init SysV

L'un des problèmes que rencontrent les utilisateurs de systemd est qu'il n'exécute pas les scripts d'initialisation SysV. Donc, il y a un exemple qui ne remplace pas complètement les fonctionnalités fournies par Upstart.

C’est quelque chose sur lequel nous pouvions compter depuis plus de 30 ans et traditionnellement, vous écriviez des scripts SysV init pour une portabilité maximale sans vous répéter (en écrivant plusieurs versions des mêmes scripts), ce qui n’est plus le cas.

Cela ne devrait pas poser de problème lorsque vous utilisez uniquement des packages de référentiels officiels, car il est probable que tous les packages contenant des scripts SysV init ou Upstart auraient besoin de réécrire leurs scripts avant de les empaqueter.

Ce ne sera un problème que pour les personnes qui utilisent un logiciel tiers ou personnalisé dont les scripts init sont écrits pour SysV init ou Upstart. Ces scripts devront être réécrits avant la mise à niveau vers un système avec systemd (ou le parvenu installé, qui est également une option , ou migrer vers un système qui n'utilise pas systemd).

Il y a un générateur systemd-sysv qui est supposé traduire automatiquement les scripts d'initialisation SysV en scripts systemd, mais il existe quelques bogues et une longue liste de incompatibilités explicites .

Maintenant, la deuxième clarification - à propos de ces quelques choses supplémentaires:

Peu de choses supplémentaires

Ces "quelques petites choses" que systemd va couvrir - selon ne perspective pour systemd - Ce qui a été réalisé et ce qui nous attend présentation de Lennart Poettering en 2014 à GNOME.asia - sont les suivants:

  • système init
  • journalisation
  • gestion de la connexion
  • gestion d'appareils
  • gestion de fichiers temporaires et volatiles
  • enregistrement au format binaire
  • rétro-éclairage enregistrer/restaurer
  • rfkill enregistrer/restaurer
  • tableau de démarrage
  • lire à l'avance
  • configuration de stockage cryptée
  • Découverte de partition EFI/GPT
  • enregistrement de machine virtuelle/conteneur
  • gestion des conteneurs
  • gestion du nom 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
  • introspection
  • découverte automatique
  • plug and play
  • la gestion du réseau
  • systemd-networkd
  • Cache DNS
  • répondeur mDNS
  • Répondeur LLMNR
  • Vérification DNSSEC
  • IPC dans le noyau
  • kdbus
  • sd-bus
  • synchronisation horaire avec NTP
  • systemd-timesyncd
  • intégration avec des 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
  • retour aux paramètres d'usine
  • initialisation et mises à jour des noeuds
  • intégration avec le cloud
  • gestion des services sur les nœuds
  • images du système d'exploitation vérifiables jusqu'au micrologiciel
  • Chargement de démarrage
  • Construire le système d’exploitation de nouvelle génération d’Internet Unifier les différences inutiles entre les distributions

Donc, revenons à: "C'est un système init, pas quelque chose que les utilisateurs interagissent traditionnellement." - il convient de souligner que le système init n'est qu'un élément de cette liste.

Et enfin, la dernière chose que je voudrais commenter:

[L] a seule fois qu'un utilisateur non technique verra que cela se passe mal.

Oh, quel soulagement. :)

Changements

Les modifications les plus remarquables pour les utilisateurs finaux (autres que les scripts eux-mêmes) consistent à démarrer et arrêter des services et à utiliser des commandes telles que:

qui ne fonctionnent plus comme prévu. Par exemple, Nohupest une commande POSIX permettant 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 également être appelés de manière spéciale ou autrement les processus que vous exécutez avec eux seront supprimés (le fait de ne pas tuer ces processus soit généralement la principale raison de l'exécution de screen ou de tmux en premier lieu).

Ce n'est pas un bogue, c'est un choix de conception, il est donc peu probable qu'il soit corrigé à l'avenir. C'est ce que Lennart Poettering a dit à propos de cette question:

À 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é. 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:

Lancer screenname__

  • upstart: screenname__
  • systemd: systemd-run --user --scope screen

(Remarque: le comportement de "upstart" ci-dessus est vraiment différent de systemd, ce n'est pas spécifique à l'amorçage)

Début d'emploi foo:

  • upstart: start foo
  • systemd: systemctl start foo

Arrêt du travail foo:

  • upstart: stop foo
  • systemd: systemctl stop foo

Relancer le travail foo:

  • upstart: restart foo
  • systemd: systemctl restart foo

Liste des emplois avec leur statut:

  • upstart: initctl list
  • systemd: systemctl status

(Voir ma réponse à Quels sont les avantages/inconvénients d'Upstart et de systemd? pour plus de détails qui sont hors du champ de cette question.)

Les journaux

Il existe également une grande différence dans la gestion des journaux car contrairement à la tradition Unix, les journaux de systemd sont stockés dans des fichiers binaires dans un format personnalisé. Par conséquent, au lieu de:

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

vous devez utiliser des commandes spéciales pour accéder à vos journaux:

Sudo journalctl -u foo
Sudo journalctl -u foo -f

Des controverses

L'introduction de systemd d'abord à Debian et plus tard à Ubuntu ne s'est pas faite sans controverses ni opposition, comme le sait quiconque a écrit l'un des articles suivants:

Le position officielle de Debian sur systemd et le résultat controverse ont conduit au déclaration d'Exodus en 2014 et se terminent par la démission de Ian Jackson .

La Liberté Init , Sans-Systemd.org et Systemd-Free.org Des initiatives sont nées, avec beaucoup de - discussion sur Hacker News .

Lectures complémentaires

6
rsp