Mise à jour 2016
La plupart des réponses ici datent de cinq ans, il est donc temps de faire quelques mises à jour.
Ubuntu utilisait upstart par défaut mais ils l’ont abandonné l’année dernière au profit de systemd - voir:
À cause de cela, il y a un bel article Systemd for Upstart Users sur le wiki Ubuntu - une comparaison très détaillée entre upstart et systemd et un guide de transition de upstart à systemd.
(Notez que selon le wiki Ubuntu, vous pouvez toujours lancer les versions actuelles d'Ubuntu par défaut en installant le upstart-sysvet en cours d'exécution, sudo update-initramfs -umais compte tenu de la portée du projet systemd, je ne sais pas comment cela fonctionne dans la pratique, ni si systemd est ou non possible de désinstaller.)
La plupart des informations contenues dans les sections Commandes et scripts ci-dessous sont adaptées de certains exemples utilisés dans cet article (sous une licence pratique, tout comme les contributions d’utilisateur de Stack Exchange sous la licence Creative Commons Attribution-ShareAlike 3.0 ).
Voici une comparaison rapide des commandes courantes et des scripts simples, voir les sections ci-dessous pour une explication détaillée. Cette réponse compare l'ancien comportement des systèmes basés sur Upstart avec le nouveau comportement des systèmes basés sur systemd, comme indiqué dans la question, mais notez que les commandes marquées comme "Upstart" ne sont pas nécessairement spécifiques à Upstart - il s'agit souvent de commandes sont communs à tous les systèmes Linux et Unix non-système.
Les commandes
En cours d'exécution su:
- parvenu:
su
- systemd:
machinectl shell
(voir la section "remplacement de la commande su" ci-dessous)
Écran en cours d'exécution:
- parvenu:
screen
- systemd:
systemd-run --user --scope screen
(voir la section "Suppression inattendue de processus en arrière-plan" ci-dessous)
Lancer tmux:
- parvenu:
tmux
- systemd:
systemd-run --user --scope tmux
(voir la section "Suppression inattendue de processus en arrière-plan" ci-dessous)
Début d'emploi foo:
- parvenu:
start foo
- systemd:
systemctl start foo
Arrêt du travail foo:
- parvenu:
stop foo
- systemd:
systemctl stop foo
Relancer le travail foo:
- parvenu:
restart foo
- systemd:
systemctl restart foo
Liste des emplois:
- parvenu:
initctl list
- systemd:
systemctl status
Vérification de la configuration du travail foo:
- parvenu:
init-checkconf /etc/init/foo.conf
- systemd:
systemd-analyze verify /lib/systemd/system/foo.service
Liste des variables d'environnement du travail:
- parvenu:
initctl list-env
- systemd:
systemctl show-environment
Définition de la variable d'environnement du travail:
- parvenu:
initctl set-env foo=bar
- systemd:
systemctl set-environment foo=bar
Suppression de la variable d'environnement du travail:
- parvenu:
initctl unset-env foo
- systemd:
systemctl unset-environment foo
Les journaux
En amont, les journaux sont des fichiers texte normaux dans le répertoire / var / log / upstart, vous pouvez donc les traiter comme d'habitude:
cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log
Dans systemd, les journaux sont stockés dans un format binaire interne (et non sous forme de fichiers texte). Vous devez donc utiliser la journalctlcommande pour y accéder:
sudo journalctl -u foo
sudo journalctl -u foo -f
Les scripts
Exemple de script de démarrage écrit en /etc/init/foo.conf:
description "Job that runs the foo daemon"
start on runlevel [2345]
stop on runlevel [016]
env statedir=/var/cache/foo
pre-start exec mkdir -p $statedir
exec /usr/bin/foo-daemon --arg1 "hello world" --statedir $statedir
Exemple de script systemd écrit en /lib/systemd/system/foo.service:
[Unit]
Description=Job that runs the foo daemon
Documentation=man:foo(1)
[Service]
Type=forking
Environment=statedir=/var/cache/foo
ExecStartPre=/usr/bin/mkdir -p ${statedir}
ExecStart=/usr/bin/foo-daemon --arg1 "hello world" --statedir ${statedir}
[Install]
WantedBy=multi-user.target
remplacement de la commande su
Un suremplacement de commande a été fusionné dans systemd dans la demande d'extraction n ° 1022:
parce que, selon Lennart Poettering, "su est vraiment un concept cassé" .
Il explique que "vous pouvez utiliser su et sudo comme auparavant, mais ne vous attendez pas à ce que cela fonctionne pleinement " .
Le moyen officiel pour obtenir un sucomportement semblable à celui-ci est maintenant:
machinectl shell
Lennart Poettering a expliqué plus en
détail
le numéro 825:
"Eh bien, il y a eu de longues discussions à ce sujet, mais le problème est que ce que su est censé faire n'est pas très clair. [...] Longue histoire courte: le su est vraiment un concept cassé. Il vous donnera une sorte de coquille , et c’est bien de l’utiliser pour cela, mais ce n’est pas un login complet, et ne devrait pas être confondu avec un. " - Lennart Poettering
Voir également:
Élimination inattendue des processus d'arrière-plan
Des commandes comme:
ne fonctionne plus comme prévu . Par exemple, nohupune commande POSIX permet 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 être invoqués de manière spéciale, sinon les processus que vous exécutez avec eux seront tués (sans que ces processus soient tués, c'est généralement la raison principale de l'exécution de screen ou de tmux).
Ce n'est pas une erreur, c'est une décision délibérée, 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 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é. Enfin, 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:
Concept de démarrage de haut niveau
D'une certaine manière, systemd fonctionne à l'envers: dans les tâches qui démarrent, elles commencent dès qu'elles le peuvent et dans les tâches systemd, elles doivent être lancées dès qu'elles le doivent. À la fin de la journée, les deux systèmes peuvent lancer les mêmes tâches et dans le même ordre, mais vous pensez que cela va dans une direction opposée pour ainsi dire.
Voici comment Systemd for Upstart Users l' explique:
Le modèle de démarrage (processus) de Upstart est "basé sur des événements gloutons", c'est-à-dire que tous les travaux disponibles dont les événements de démarrage se produisent sont démarrés le plus tôt possible. Au démarrage, upstart synthétise certains événements initiaux tels que le démarrage ou rcS en tant que "racine de l'arborescence", les services les plus anciens démarrent sur ces derniers et les services ultérieurs démarrant lorsque les premiers sont en cours d'exécution. Un nouveau travail doit simplement installer son fichier de configuration dans / etc / init / pour devenir actif.
Le modèle de systemd pour les processus de démarrage (unités) est "basé sur la dépendance paresseuse", c'est-à-dire qu'une unité ne démarrera que si et quand une autre unité de départ en dépend. Au démarrage, systemd démarre une "unité racine" (default.target, qui peut être écrasée dans grub), qui ensuite se développe de manière transitoire et démarre ses dépendances. Une nouvelle unité doit s'ajouter elle-même en tant que dépendance d'une unité de la séquence d'amorçage (généralement plusieurs utilisateurs multiples) pour devenir active.
Utilisation dans les distributions
Maintenant, quelques données récentes selon Wikipedia:
Distributions utilisant upstart par défaut:
Distributions utilisant systemd par défaut:
(Voir Wikipedia pour des informations à jour)
Distributions n'utilisant ni Upstart ni systemd:
Controverse
Dans le passé, un fork de Debian a été proposé pour éviter systemd . Le devuan GNU + Linux a été créé - une fourchette de Debian sans systemd (grâce à fpmurphy1 pour le signaler dans les commentaires).
Pour plus d'informations sur cette controverse, voir:
Comme beaucoup d'entre vous le savent peut-être déjà, le vote Init GR sur Debian promu par Ian Jackson n'était pas utile pour protéger l'héritage de Debian et ses utilisateurs contre l'avalanche systémique.
Cette situation risque de verrouiller les dépendances système, ce qui menace de fait la liberté de développement et a de graves conséquences pour Debian, son amont et son aval.
Le CTTE a réussi à échanger une dépendance et à nous faire gagner du temps sur une installation subtile de systemd sur sysvinit, mais même ce processus a été épuisant et dramatique. En fin de compte, Ian Jackson a démissionné il y a une semaine. [...]
Je quitte le Comité technique avec effet immédiat.
S'il est important que les points de vue des 30 à 40% du projet qui sont d'accord avec moi continuent à être représentés au sein du TC, je suis moi-même clairement trop controversé pour pouvoir le faire. Je devrais me retirer pour tenter de réduire le degré de personnalisation des conversations sur la gouvernance du projet. [...]
Devuan est né d'une controverse sur la décision d'utiliser Debian comme système d'initialisation par défaut. La position officielle de Debian sur systemd regorge d’affirmations que d’ autres ont démystifiées . Les lecteurs intéressés peuvent continuer à discuter de ce sujet brûlant dans la controverse The systemd . Cependant, nous vous encourageons à garder votre tête froide et votre voix civile. Chez Devuan, nous sommes plus intéressés par une mauvaise programmation que par le passé. [...]
Quelques sites et articles consacrés à la controverse systémique ont été créés:
Il y a beaucoup de discussions intéressantes sur Hacker News:
Des tendances similaires dans d'autres distributions peuvent également être observées:
Philosophie
upstart suit la philosophie Unix de DOTADIW - "Fais un truc et fais-le bien." C'est un remplacement pour le démon d'init traditionnel. Il ne fait rien d'autre que le démarrage et l'arrêt des services. Les autres tâches sont déléguées à d'autres sous-systèmes spécialisés.
Systemd fait beaucoup plus que cela. Outre le démarrage et l'arrêt des services, il gère également les mots de passe, les connexions, les terminaux, la gestion de l'alimentation, les réinitialisations d'usine, le traitement des journaux, les points de montage du système de fichiers, la mise en réseau et bien plus encore - voir le fichier NEWS pour quelques-unes des fonctionnalités.
Plans d'expansion
Selon A Perspective for systemd, ce qui a été réalisé et ce qui nous attend, présentation de Lennart Poettering en 2014 sur GNOME.asia, voici les principaux objectifs de systemd, les domaines déjà couverts et ceux en cours:
objectifs systemd:
Nos objectifs
- Transformer Linux d’un sac de bits en un système d’exploitation polyvalent concurrentiel.
- Construire le système d'exploitation de nouvelle génération de l'Internet Unifier les différences inutiles entre les distributions
Ramener l'innovation au coeur du système d'exploitation
Bureau, Serveur, Conteneur, Embarqué, Mobile, Cloud, Cluster,. . . Ces zones sont plus proches que vous ne le pensez
- Réduire la complexité de l'administrateur, la fiabilité sans supervision
- Tout introspectable
- La découverte automatique, plug and play est la clé
- Nous réparons les choses là où elles sont brisées, nous ne les collons jamais
Zones déjà couvertes:
Ce que nous couvrons déjà:
système d'initialisation, journalisation du journal, gestion des connexions, gestion des périphériques, gestion des fichiers temporaires et volatiles, enregistrement au format binaire, sauvegarde / restauration du rétroéclairage, sauvegarde / restauration de rfkill, bootchart, readahead, configuration du stockage chiffré, découverte de la partition EFI / GPT, machine virtuelle / conteneur enregistrement, gestion minimale des conteneurs, gestion des noms 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,. . .
Travaux en cours:
Sur quoi nous travaillons:
- la gestion du réseau
- systemd-networkd
- Cache DNS local, répondeur mDNS, répondeur LLMNR, vérification DNSSEC
- IPC dans le noyau
- kdbus, sd-bus
- Synchronisation de l'heure avec NTP
- systemd-timesyncd
- Plus d'intégration avec les 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, réinitialisation d'usine
- / usr est l'OS
- / etc est la configuration (optionnelle)
- / var est l'état (optionnel)
- Initialisation et mises à jour du noeud atomique
- Intégration avec le cloud
- Gestion des services sur les nœuds
- Images de système d'exploitation vérifiables
- Tout le chemin au firmware
- Chargement de démarrage
Portée de cette réponse
Comme le note fpmurphy1 dans les commentaires, "il convient de souligner que systemd a élargi son champ de travail au cours des années, bien au-delà du simple démarrage du système".
J'ai essayé d'inclure la plupart des informations pertinentes ici. Ici, je compare les fonctionnalités communes d'Upstart et de systemd lorsqu'elles sont utilisées en tant que systèmes init, comme indiqué dans la question. Je mentionne uniquement les fonctionnalités de systemd qui dépassent le cadre d'un système init car elles ne peuvent pas être comparées à Startup, mais leur présence est importante. comprendre la différence entre ces deux projets. La documentation pertinente doit être vérifiée pour plus d'informations.
Plus d'informations
Plus d'informations peuvent être trouvées à:
Suppléments
L’ équipe LinOxide a créé une feuille de mise à jour Linux Systemd vs SysV Init .