Le changement le plus important qui accompagne Ubuntu 15.04 est le passage de upstart à systemd par défaut pour gérer le démarrage et le 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?
Les utilisateurs de Layman ne devraient pas remarquer de changement, de par leur conception. C'est un système d'initialisation, pas quelque chose avec lequel les utilisateurs interagissent traditionnellement. Il devrait remplacer complètement les fonctionnalités fournies par Upstart -et faire un peu supplémentaire choses- mais la seule fois qu'un utilisateur non-technique voir c'est quand il va mal.
Les utilisateurs, administrateurs système et développeurs qui utilisent et développent activement Upstart sont les personnes qui doivent résoudre les problèmes. Il existe un document de migration sur le wiki Ubuntu pour aider les développeurs à convertir leurs scripts init, mais les utilisateurs et les sysops peuvent continuer à utiliser Upstart en respectant la version 14.04 (qui est prise en charge jusqu'en 2019).
La raison et la justification du changement n'étaient vraiment pas du côté d'Ubuntu. Canonical était assez satisfait d'Upstart (leur projet), mais de nombreux utilisateurs de Debian voulaient passer à un moteur d'initialisation moderne pour obtenir une meilleure concurrence au démarrage et une meilleure fonctionnalité de surveillance dans tous les services.
Cela signifiait un combat entre diverses options (les justifications) et systemd finalement gagné.
Canonical est allé de pair avec Debian parce que c'est le plus simple et probablement le meilleur. Ils peuvent abandonner un projet et ne se battent pas en amont. Cela nous rapproche également d'autres distributions (Red Hat, Fedora, etc.) qui migrent également vers systemd. Plus de concentration et moins de duplication d'efforts.
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.
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 ne s'implique pas dans le détail du fonctionnement du système. Dans la pratique, il y a beaucoup de choses que vous allez voir.
Voici une liste incomplète:
init+ rcsont mordu par le fait que systemd est seulement en arrière compatible avec le système 5 rc. Comme upstart, et en fait la plupart des autres systèmes, il professe et fournit, pas de rétrocompatibilité avec System 5 initet son fichier de configuration /etc/inittab.Ainsi, les personnes qui ont suivi les conseils des 30 dernières années conseillant "Eh bien, vous pouvez simplement modifier cela en /etc/inittab...", ou les personnes qui utilisent des logiciels qui ont suivi ces conseils ont maintenant des logiciels qui ne commencent pas au bootstrap. Exemple: /unix//a/196197/5132
shutdowncommande systemd , comme vous le pouviez avec les shutdowncommandes précédentes . Mis à part le fait qu'il est appelé mode de secours dans le jargon systemd, le mode de secours n'est pas considéré comme un état d'arrêt dans la vision du monde systemd. Il est considéré comme un état courant . shutdown nowéteindra la machine. C'est systemctl rescuepour atteindre le mode mono-utilisateur dans le monde systemd. Pour en savoir plus: /unix//a/196471/5132--useroption systemctl. Cela ne s'applique pas (encore) à Ubuntu. upstart et systemd diffèrent considérablement dans ce domaine, et Ubuntu version 15 utilise toujours l' initialisation upstart par session plutôt qu'une instance systemd par utilisateur . Alors /superuser//a/860598/38062 ne sera pas le cas, par exemple. ☺Comme d'autres l'ont déjà noté ici, en théorie, cela ne devrait pas affecter l'utilisateur final non technique - et en théorie, il n'y a pas de différence entre la théorie et la pratique, mais en pratique, il y en a.
Je pense que peu de choses affichées ici nécessitent des éclaircissements:
C'est un système d'initialisation, pas quelque chose avec lequel les utilisateurs interagissent traditionnellement.
Ce fut le cas avec SysV init et avec Upstart mais ce n'est plus le cas avec systemd. Il fait beaucoup de choses avec lesquelles les utilisateurs interagissent traditionnellement:
Il devrait remplacer complètement les fonctionnalités fournies par Upstart - et faire quelques choses supplémentaires
Deux choses à clarifier - d'abord sur le remplacement complet d'Upstart:
L'un des problèmes que les gens ont avec systemd est qu'il n'exécute pas les scripts d'initialisation SysV. Il y a donc un exemple qui ne remplace pas complètement les fonctionnalités fournies par Upstart.
C'est quelque chose sur lequel nous pouvons compter depuis plus de 30 ans et traditionnellement, vous écriviez des scripts d'initialisation SysV 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 être un problème lorsque vous utilisez uniquement des packages provenant de référentiels officiels, car tous les packages qui avaient auparavant des scripts SysV init ou Upstart devraient probablement avoir leurs scripts réécrits avant d'être emballés.
Ce ne sera un problème que pour les personnes qui utiliseront des logiciels tiers ou personnalisés dont les scripts d'initialisation sont écrits pour SysV init ou pour Upstart et ceux-ci auront besoin des scripts d'initialisation réécrits avant la mise à niveau vers un système avec systemd (ou obtenir le parvenu installé, qui est également une option , ou migrer vers un système qui n'utilise pas systemd).
Il y a systemd-sysv-generator qui est censé traduire automatiquement les scripts d'initialisation SysV en scripts systemd mais il y a quelques bugs et une longue liste d' incompatibilités explicites .
Maintenant, la deuxième clarification - sur ces quelques choses supplémentaires:
Ces «quelques choses supplémentaires» que systemd va couvrir - selon A Perspective for systemd - What Has Been Achieved, and What Lies Ahead présentation par Lennart Poettering en 2014 sur GNOME.asia - sont les suivantes:
Revenons donc à: "C'est un système d'initialisation, pas quelque chose avec lequel les utilisateurs interagissent traditionnellement." - il faut 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] e seul moment où un utilisateur non technique verra que c'est quand ça tourne mal.
Oh, quel soulagement. :)
Les changements les plus notables pour les utilisateurs finaux (autres que les scripts eux-mêmes) sont le démarrage et l'arrêt des services et l'utilisation de commandes telles que:
qui ne fonctionnent plus comme prévu. Par exemple, nohupest une commande POSIX pour vous assurer que le processus continue de s'exécuter après votre déconnexion de votre session. Il ne fonctionne plus sur systemd. Des programmes comme screenet tmuxdoivent être invoqués d'une manière spéciale, sinon les processus que vous exécutez avec eux seront tués (alors que ne pas tuer ces processus est généralement la principale raison de l'exécution de screen ou tmux en premier lieu).
Ce n'est pas un bug, c'est un choix de conception, 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 d'UNIX qu'il laisse par défaut le code utilisateur arbitraire sans restriction après la déconnexion. Il a été discuté depuis des siècles parmi de nombreuses personnes utilisant le système d'exploitation, que cela devrait être possible, mais certainement pas la valeur par défaut, mais personne n'a osé jusqu'à présent basculer le commutateur pour le faire passer d'une option par défaut à une option. Ne pas nettoyer les sessions utilisateur après la déconnexion est non seulement laid et quelque peu hack mais aussi un problème de sécurité. systemd 230 a finalement basculé le commutateur et finalement par défaut nettoie tout correctement lorsque l'utilisateur se déconnecte.
Pour plus d'informations, voir:
screenscreensystemd-run --user --scope screen(Remarque: le comportement de "upstart" ci-dessus est vraiment tout sauf systemd, ce n'est pas spécifique à upstart)
start foosystemctl start foostop foosystemctl stop foorestart foosystemctl restart fooinitctl listsystemctl status(Voir ma réponse à Quels sont les avantages / inconvénients d'Upstart et de systemd? Pour plus de détails qui sont hors de portée de cette question.)
Il y a aussi 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é, donc 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
L'introduction de systemd d'abord sur Debian et plus tard sur Ubuntu n'a pas été sans controverse et sans grande opposition, comme le sait quiconque a écrit l'un des articles suivants:
La position officielle de Debian sur systemd et la controverse qui en a résulté ont conduit à la déclaration d'Exodus en 2014 et ont pris fin avec la démission d'Ian Jackson .
Les initiatives Init Freedom , Without-Systemd.org et Systemd-Free.org sont nées, avec beaucoup de discussions sur Hacker News .