Les utilisateurs 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 quelques choses supplémentaires - mais le seul moment où un utilisateur non technique verra voir que c'est quand ça ne va pas.

Les utilisateurs, les administrateurs système et les développeurs qui ont activement utilisé et développé pour Upstart sont ceux qui ont besoin d’adresser des choses. Il y a 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 collant avec 14.04 (qui est pris en charge jusqu'en 2019).

La raison et la raison d'être du changement ne sont pas du côté d'Ubuntu. Canonical était assez satisfait de 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 dans tous les services.

Cela signifiait un combat entre différentes options (les justifications) et systemd a finalement gagné.

Canonical est allé de pair avec Debian car il est plus facile et probablement le meilleur. Ils arrivent à abandonner un projet et ne se battent pas en amont. Cela nous permet également de nous aligner sur d’autres distributions (Red Hat, Fedora, etc.) qui passent également à systemd. Plus de concentration et moins de duplication des efforts.

tl; dr Pour un non-spécialiste, 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 adéquatement à 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 les détails concrets 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 supplémentaires utilisant des fichiers de définition de travail pour démarrer des programmes, ils cesseraient de fonctionner. Vous devrez installer (et éventuellement écrire, mais plus communément, tout simplement quelqu'un qui a déjà écrit) les fichiers systemd service unit . Exemple: lien
• Diverses hypothèses de conception formulées par les développeurs systemd à propos d'éléments tels que la gestion de l'alimentation entraînent des valeurs par défaut qui sont en contradiction avec ce que vous pourriez être habitué. Les développeurs systemd ont des idées très précises sur ce qui doit se passer en réponse aux interrupteurs du couvercle sur les ordinateurs portables , par exemple.
• Si vous utilisez le pilote d’affichage propriétaire nvidia, diverses décisions de conception dans systemd vous concernent. Exemple: lien
• Ce n’est pas vraiment pertinent lorsque vous venez de l’avant, car les utilisateurs d’Ubuntu ont une page de manuel qui leur dit cela depuis quelques années, mais je le mentionne pour les utilisateurs non-Ubuntu qui pourraient lire ceci: Le système 5 init + rc est mordu par le fait que systemd est seulement compatible avec System 5 rc . Comme pour les nouveaux systèmes, et même pour la plupart des autres systèmes, il ne profite pas de la compatibilité descendante avec System 5 init et de son fichier de configuration /etc/inittab .

  conseillant "Eh bien, vous pouvez simplement éditer ceci dans /etc/inittab ...", ou les personnes qui utilisent des logiciels qui suivent ce conseil ont maintenant des logiciels qui ne démarrent pas au démarrage. Exemple: lien

• Vous ne pouvez pas accéder au mode mono-utilisateur via la commande systemd shutdown , comme vous pouvez le faire avec les précédentes commandes shutdown . 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 de systemd. Il est considéré comme un état en cours d'exécution . shutdown now mettra la machine hors tension. Il est systemctl rescue d'atteindre le mode mono-utilisateur dans le monde systemd. Lectures complémentaires: lien
• Suite à ce dernier sujet: Si vous n'avez pas encore rejeté l'idée de exécuter les niveaux , le moment est venu de le faire. Lecture ultérieure: lien
• Vous devez faire attention à suivre les conseils généraux de systemd trouvés lors de la navigation au hasard dans WWW, car vous "savez" que tout est "systemd maintenant". Vous allez voir des gens parler de l'exécution de commandes avec l'option --user à systemctl . Cela ne s'applique pas à Ubuntu (encore). upstart et systemd diffèrent de manière significative dans ce domaine, et la version 15 d'Ubuntu utilise toujours l'initiation de démarrage par session plutôt qu'une instance systèmed par utilisateur . Ainsi, lien ne s'applique pas, par exemple. ☺

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:

• lien

  

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:

• écran
• tmux
• nohup

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:

• Systemd commence à tuer vos antécédents Processus par défaut
• Systemd v230 élimine les processus d’arrière-plan après la déconnexion de l’utilisateur, l’interruption de l’écran, le tmux
• Debian Bogue n ° 825394: Processus en arrière-plan de systemd kill après que l'utilisateur se soit déconnecté

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:

• Rencontrez Devuan, la fourchette Debian né d'une révolte systémique amère (PCWorld)
• Prenez vos fourches: Ubuntu pour passer à systemd lundi (The Register)
• Linus Torvalds et d’autres personnes sur Linux systemd (ZDNet)
• À propos de la controverse de systemd (sécurité des errata)

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 .