Porter les anciennes habitudes de Sysvinit vers Systemd ?

J'ai une série de scripts avec lesquels j'ai pu installer et configurer de nouveaux systèmes stables Debian. Pour démarrer automatiquement les programmes, j'utilise /etc/rc.local mais pour les autres cas, j'ai dû modifier manuellement le /etc/inittab dossier. J'ai également d'autres modifications telles que l'ajout de --noclear à la ligne 1:2345:respawn:/sbin/getty --noclear 38400 tty1 .

Parce que je devais personnaliser le processus d'arrêt, j'ai fini par faire ceci :

l0:0:wait:/etc/rc.halt 0
...
l6:6:wait:/etc/rc.halt 6

et mon /etc/rc.halt ressemble à ceci

#!/bin/sh
#   
# rc.halt
#   
# This script is executed when entering level 6/0 (on halt or reboot)

su - teststand -c "/home/teststand/stop_server.sh"  # my custom command

# making sure the halt/reboot process is resumed
test -n "${1}" && /etc/init.d/rc ${1}

exit 0

Aujourd'hui, c'était la première fois que j'installais une nouvelle Debian 8 avec systemd comme système d'initialisation par défaut. Je n'y ai pas pensé et j'ai d'abord été surpris que le /etc/inittab le fichier était manquant.

Sur mes systèmes en cours d'exécution (@work &@home), j'exécute toujours mes systèmes avec sysvinit et c'est pourquoi j'ai 0 expérience avec systemd .

Je sais que je peux passer à l'ancien sysvinit mais je veux voir les différences avec systemd . D'ailleurs je suis en train de personnaliser une nouvelle installation en ce moment et je n'ai pas trop le temps de la finir, c'est pourquoi je n'ai pas le temps en ce moment de regarder la documentation.

Ma question :existe-t-il un moyen de changer rapidement systemd comportement pour que je puisse ajouter --noclear à getty et en utilisant /etc/rc.halt comme point de départ pour le redémarrage/l'arrêt ?

Fondamentalement, puis-je importer rapidement mon ancien inittab modifications apportées à systemd ?

Merci

Réponse acceptée :

systemd n'est pas rétrocompatible avec System 5 `init` , uniquement System 5 `rc` .

La gestion du système de style Linux System 5 comprend deux parties, init qui s'exécute en tant que processus #1 et rc qui est en charge de l'exécution des scripts de démarrage et d'arrêt. Ceux-ci proviennent en fait de deux packages distincts dans Debian. init provient du package sysvinit ; et rc provient généralement du package sysv-rc, mais peut provenir du package file-rc ou openrc.

/etc/inittab est un fichier de configuration traité par init . systemd ne fournit aucun mécanisme de rétrocompatibilité pour cela. Le mécanisme de rétrocompatibilité System 5 de systemd est uniquement pour System 5 rc , qui exécute les programmes dans /etc/init.d/ . (Ce n'est que pour cette version spécifique de rc , en outre. systemd n'implémente aucun mécanisme de rétrocompatibilité pour les mécanismes de configuration de file-rc et openrc.)

Ce n'est pas quelque chose qui est spécifique à systemd. Pratiquement non remplacement init/system manager (avec seulement 1 exception en trois décennies) traite /etc/inittab .

Pour connecter un service à systemd, vous devez utiliser les mécanismes qu'il fait support, à savoir sa propre unité de service fichiers et (via un générateur qui se convertit automatiquement en fichiers unitaires) le System 5 rc fichiers de configuration dans /etc/init.d/ .

Oubliez les niveaux d'exécution.

Tous ces éléments de niveau d'exécution avec lesquels vous travaillez ont été déclarés «obsolètes» sur les systèmes d'exploitation Linux systemd. Il n'y a pas exécutez le niveau 0 ou 6 pour entrer. Ils n'existent pas sans quelques cales de compatibilité.

Pour faire fonctionner un service à l'arrêt, la réponse évidente, donnée par beaucoup, est de créer une unité de service qui est WantedBy le shutdown.target . Cela comporte cependant quelques pièges subtils. Une meilleure réponse, mais moins évidente, consiste à créer une unité de service par ailleurs normale, avec DefaultDependencies=yes pour s'assurer qu'il est en conflit avec la cible d'arrêt et mettre la viande du service dans ExecStop au lieu de dans ExecStart .

[Unit]
Documentation=https://unix.stackexchange.com/questions/233561/

[Service]
Type=oneshot
User=teststand
RemainAfterExit=true
ExecStart=/bin/true
ExecStop=/home/teststand/stop_server.sh

[Install]
WantedBy=multi-user.target

Ne lancez pas votre propre Poor Man's Dæmon Supervisor dans un script shell.

De telles choses sont toujours mal écrites.

Connexes :Faire sortir tail -f sur un tuyau cassé ?

Si votre "service" est simplement l'exécution d'une commande nommée "stop_server.sh", alors l'inférence est qu'il s'agit d'un script qui arrête un serveur sous un système de gestion de service de script shell lancé à la main.

C'est pour ces catastrophes mal écrites, branlantes, peu fiables et dangereuses :stop_server.sh stop_server.sh stop_server.sh stop_server.sh stop_server.sh stop_server.sh

Vous avez systemd. Utilisez-le et exécutez n'importe quel service en cours d'exécution ici en utilisant des mécanismes de gestion de service appropriés. Vous n'aurez pas besoin de cet excentrique ExecStop -seul service du tout si vous faites votre réel service exécutable via systemd avec DefaultDependencies=true , car systemd se chargera d'arrêter le service au moment de l'arrêt.

Prendre un Poor Man's Dæmon Supervisor dans un script shell qui "gère" un service, puis l'envelopper dans une unité de service systemd pour un deuxième service que l'on s'arrange ensuite pour démarrer à l'arrêt, lorsque le but n'est pas plus que de gérer le premier service et le faire éteindre lorsque le système est arrêté ou éteint, est un bon moyen d'entrer dans la maison de l'horreur systemd.

Le monde veut que vous nettoyiez votre écran.

Vouloir ne pas vider un terminal virtuel entre la déconnexion et la connexion suivante va à contre-courant, comme Greg Wooledge et d'autres l'ont découvert. La présence de sorties sensibles d'utilisateurs privilégiés, ou de patrons, restant après la déconnexion a été un problème de sécurité pour les Unix (et en fait d'autres systèmes d'exploitation d'accès à distance en temps partagé) depuis les années 1970, et il faut beaucoup d'efforts pour défaire tout cela. les choses que les gens ont mises en place pour éviter ce problème.

De nombreux systèmes ont une clear_console commande dans leurs scripts de déconnexion shell en standard. (Ceci est problématique en soi, car il ne fonctionne pas bien avec les programmes graphiques exécutés sur le terminal virtuel du noyau n ° 1 et ne fonctionne pas avec d'autres types de terminaux, virtuels ou réels.)

Cette commande doit être supprimée.
La valeur par défaut dans les programmes getty destinés aux terminaux virtuels, tels que mingetty , est d'effacer le terminal. (Il le fait avant la connexion, ce qui signifie que la sortie du terminal peut rester non effacée si un service de connexion TTY est arrêté. Ironiquement, cette fonctionnalité aurait été mieux placée dans login , qui, grâce aux nécessités de PAM, fonctionne toujours à la déconnexion.)

Le --noclear L'option doit être déployée pour désactiver cela. Cela implique d'écrire un ou plusieurs fichiers de remplacement de fichier d'unité, de modifier le ExecStart ou pointant simplement [email protected] dans un fichier d'unité locale de sa propre conception.
[email protected] fourni par systemd ensembles d'unités de service de modèles TTYVTDisallocate=yes qui demande à systemd d'effacer un terminal virtuel du noyau. (Cela ne fonctionne pas non plus avec d'autres types de terminaux, pas même les terminaux virtuels de l'espace utilisateur, comme le reflète en partie son nom.)

Cela aussi doit être supprimé, encore une fois avec un remplacement ou un modèle de service différent pointé par [email protected] .

Autres lectures

Jonathan de Boyne Pollard (2015). /etc/inittab appartient au passé. . Réponses fréquemment données.
https://unix.stackexchange.com/a/196014/5132
Comment exécuter un script avec systemd juste avant l'arrêt ?
Jonathan de Boyne Pollard (2014). N'abusez pas de su pour supprimer les privilèges de l'utilisateur. . Réponses fréquemment données.
Greg Woedge (2014-04-08). Arrêtez de vider ma console God Damned . Wiki de Greg.
Jonathan de Boyne Pollard (2015-08-22). Gel du système avec plusieurs ttys dans Debian Jessie . [email protected] utilisateur-debian.
https://unix.stackexchange.com/a/194218/5132
Jonathan de Boyne Pollard (2015). La maison de l'horreur systemd . Réponses fréquemment données.

En relation :Bonne explication détaillée de la syntaxe /etc/network/interfaces ?