Comme d’autres l’ont déjà fait remarquer, 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 la théorie et la pratique, mais dans la pratique, cela existe.
Clarification
Je pense que peu de choses publiées ici ont besoin de précisions:
C'est un système d'initialisation, pas quelque chose avec lequel les utilisateurs interagissent traditionnellement.
C'était le cas avec SysV init et avec Upstart mais ce n'est plus le cas avec systemd. Cela fait beaucoup d’interactions avec les utilisateurs:
Il devrait remplacer complètement la fonctionnalité fournie par Upstart
-Et faire quelques trucs supplémentaires
Deux choses à clarifier - d’abord le remplacement complet de Upstart:
Aucun script d’initialisation SysV
L’un des problèmes que rencontrent les utilisateurs avec systemd est qu’il n’exécute pas les scripts d’initialisation SysV. Il y a donc un exemple qu'il 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 vous écriviez traditionnellement 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 poser de problème lorsque vous utilisez uniquement des paquets provenant de dépôts officiels, car il est probable que tous les paquets contenant des scripts SysV init ou Upstart devront être réécrits avant d'être empaquetés.
Ce ne sera qu'un problème pour les utilisateurs de logiciels tiers ou personnalisés dont les scripts d'initialisation sont écrits pour SysV init ou pour Upstart, et ceux qui auront besoin de réécrire les scripts d'initialisation avant de passer à un système avec systemd (ou installez-vous, qui est également une option , ou migrez vers un système qui ne fonctionne pas t utiliser systemd).
Il y a systemd-sysv-generator qui est censé traduire automatiquement les scripts d'initialisation SysV en scripts systemd mais il y a des bogues et une longue liste de incompatibilités explicites .
Maintenant, la deuxième clarification - à propos de ces quelques choses supplémentaires:
Quelques petites choses
Ce "peu de choses supplémentaires" que systemd va couvrir - selon Une perspective pour systemd - Qu'est-ce qui a été réalisé, et quoi Lies Ahead présentation
par Lennart Poettering en 2014 sur GNOME.asia - sont les suivants:
- système init
- journalisation du journal
- Gestion des connexions
- gestion des périphériques
- Gestion de fichiers temporaire et volatile
- Enregistrement au format binaire
- sauvegarde / restauration du rétro-éclairage
- rfkill save / restore
- Organigramme
- readahead
- Configuration du stockage chiffré
- 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 aléatoire des semences
- Gestion des variables sysctl
- Gestion de la console
- introspection
- découverte automatique
- plug and play
- 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
- mise en sandbox 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
- réinitialisation d'usine
- initialisation du noeud et mises à jour
- intégration avec le cloud
- gestion des services entre les nœuds
- images du système d’exploitation vérifiables jusqu’au micrologiciel
- Chargement du démarrage
- Construire le système d’exploitation de nouvelle génération de l’Internet Unifier les différences inutiles entre les distributions
Donc, revenons à: "C'est un système d'initialisation, pas quelque chose avec lequel les utilisateurs interagissent traditionnellement." - il faut souligner que le système d’initialisation n’est qu’un élément de cette liste.
Et enfin, la dernière chose que je voudrais commenter:
Le seul moment où un utilisateur non technique verra cela, c'est quand il se passe mal.
Oh, quel soulagement.:)
Modifications
La plupart des changements notables pour les utilisateurs finaux (autres que les scripts eux-mêmes) sont le démarrage et l’arrêt de 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 la déconnexion de votre session. Il ne fonctionne plus sur systemd. De même, les programmes tels que screen
et tmux
doivent être invoqués de manière spéciale ou autrement les processus que vous exécutez avec eux seront supprimés (bien que le fait de ne pas tuer ces processus est généralement la raison principale de l'exécution de screen ou de tmux). / p>
Ce n’est pas un bogue, c’est un choix de conception, donc il est peu probable qu’il soit corrigé à l’avenir. C’est ce que Lennart Poettering a déclaré sur ce problème:
À mon avis, il était en fait assez étrange d’UNIX de laisser par défaut du code utilisateur arbitraire sans restriction après la déconnexion. Il a été discuté depuis longtemps parmi de nombreux utilisateurs de systèmes d'exploitation, que cela devrait être possible, mais certainement pas par défaut, mais personne n'a encore osé basculer le commutateur pour le transformer en une option. Ne pas nettoyer les sessions utilisateur après la déconnexion n'est pas seulement moche et quelque peu piraté, mais aussi un problème de sécurité. systemd 230 a finalement renversé le commutateur et, par défaut, le nettoie correctement lorsque l'utilisateur se déconnecte.
Pour plus d’informations, voir:
En cours d'exécution screen
-
démarrage:
screen
-
systemd:
systemd-run --user --scope screen
(Note: le comportement de "upstart" ci-dessus est vraiment tout sauf systemd, ce n’est pas spécifique au démarrage)
Démarrer le travail foo:
-
démarrage:
start foo
-
systemd:
systemctl start foo
Arrêt du travail foo:
-
démarrage:
stop foo
-
systemd:
systemctl stop foo
Redémarrer le job foo:
-
démarrage:
restart foo
-
systemd:
systemctl restart foo
Liste des jobs avec leur statut:
-
démarrage:
initctl list
-
systemd:
systemctl status
(Voir ma réponse à Quels sont les avantages / inconvénients de Upstart et systemd? pour plus de détails qui sont hors de portée pour cette question.)
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é, 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 à Debian et plus tard à Ubuntu n’a pas été sans controverse et sans grande opposition, comme le savent tous ceux qui ont écrit l’un des articles suivants:
La position Debian officielle sur systemd et le controverse a conduit à la déclaration Exodus en 2014 et fini avec La démission de Ian Jackson .
Init Freedom , Sans-Systemd.org et Systemd-Free.org ont vu le jour, avec beaucoup de discussions sur Hacker News .
Lectures complémentaires