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.
Clarification
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:
Aucun script d'initialisation SysV
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:
Peu de 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:
- système init
- journalisation du journal
- gestion des connexions
- gestion d'appareils
- gestion des fichiers temporaires et volatils
- enregistrement au format binaire
- sauvegarde / restauration du rétroéclairage
- rfkill enregistrer / restaurer
- diagramme de démarrage
- readahead
- configuration de stockage crypté
- Découverte de partition EFI / GPT
- enregistrement de machine virtuelle / conteneur
- gestion de conteneurs
- gestion du nom d'hôte
- gestion des paramètres régionaux
- gestion du temps
- gestion aléatoire des semences
- 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 de l'heure avec NTP
- systemd-timesyncd
- intégration avec des conteneurs
- sandboxing de services
- sandboxing des applications
- Format d'image du système d'exploitation
- Format d'image du conteneur
- Format d'image de l'application
- GPT avec découverte automatique
- Systèmes sans état
- systèmes instanciables
- retour aux paramètres d'usine
- initialisation et mises à jour des nœuds
- 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
- Création du système d'exploitation nouvelle génération d'Internet Unification des différences inutiles entre les distributions
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. :)
Changements
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, nohup
est 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 screen
et tmux
doivent ê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:
Fonctionnement screen
- parvenu:
screen
- systemd:
systemd-run --user --scope screen
(Remarque: le comportement de "upstart" ci-dessus est vraiment tout sauf systemd, ce n'est pas spécifique à upstart)
Démarrage du job foo:
- parvenu:
start foo
- systemd:
systemctl start foo
Arrêt du travail foo:
- parvenu:
stop foo
- systemd:
systemctl stop foo
Redémarrage du travail foo:
- parvenu:
restart foo
- systemd:
systemctl restart foo
Liste des emplois avec leur statut:
- parvenu:
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 de portée de cette question.)
Journaux
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
Controverses
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 .
Lectures complémentaires