Portage des anciennes habitudes sysvinit à 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 d'autres cas, j'ai dû modifier manuellement le file /etc/inittab . J'ai aussi d'autres changements comme append --noclear à la ligne 1:2345:respawn:/sbin/getty --noclear 38400 tty1 .

Parce que j'ai dû personnaliser le process d'arrêt, j'ai fini par faire ça:

 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 

C'était la première fois que j'installais un nouveau Debian 8 avec systemd comme système d'initialisation par défaut. Je n'y ai pas pensé et j'ai été surpris d' /etc/inittab file /etc/inittab était manquant.

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

Je sais que je peux changer à l'ancien sysvinit mais je veux voir les différences avec systemd . De plus, je personnalise une nouvelle installation en ce moment et je n'ai pas trop de time pour la terminer, c'est pourquoi je n'ai pas le time de regarder la documentation.

Ma question est la suivante: y a-t-il un moyen de changer rapidement le comportement de systemd afin que je puisse append --noclear à getty et en utilisant /etc/rc.halt comme sharepoint départ pour reboot / stop?

Fondamentalement puis-je rapidement importer mes anciens changements inittab à systemd ?

Merci

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

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

/etc/inittab est un file de configuration traité par init . systemd ne fournit aucun mécanisme de rétrocompatibilité pour cela. Le mécanisme de rétrocompatibilité du System 5 de Systemd est uniquement pour System 5 rc , qui exécute les programmes dans /etc/init.d/ . De plus, 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. À peu près pas de rlocation init / gestionnaire de système (avec seulement 1 exception en trois décennies) process /etc/inittab .

Pour installer un service dans systemd, vous devez utiliser les mécanismes qu'il prend en charge, à savoir ses propres files d' unité de service et (via un générateur qui convertit automatiquement en files unitaires) les files de configuration rc System 5 dans /etc/init.d/ .

Oubliez les niveaux d'exécution.

Tous les trucs de niveau d'exécution avec lesquels vous travaillez ont été déclarés «obsolètes» sur les systèmes d'exploitation Linux de Systemd. Il n'y a pas de niveau d'exécution 0 ou 6 pour entrer. Ils n'existent pas en dehors de quelques cales de compatibilité.

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

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

 [Un service]
 Type = oneshot
 Utilisateur = banc d'essai
 RemainAfterExit = true
 ExecStart = / bin / true
 ExecStop = / home / teststand / stop_server.sh

 [Installer]
 WantedBy = multi-user.target

Ne roulez pas le superviseur Dæmon de votre pauvre homme dans le script shell.

De telles choses sont toujours mal écrites.

Si votre «service» est simplement l'exécution d'une command nommée «stop_server.sh», l'inférence est qu'il s'agit d'un script qui arrête un server sous un système de gestion de service shell-manuscrit roulé à la main.

C'est pour ces désastres mal écrits, rachitiques, peu fiables et dangereux: 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 est couru ici en utilisant les mécanismes de gestion de service appropriés. Vous n'aurez pas besoin de ce service ExecStop si vous effectuez votre service réel via systemd avec DefaultDependencies=true , car systemd prendra en charge l'arrêt du service au moment de l'arrêt.

Prendre le superviseur Dæmon d'un pauvre homme dans un script shell qui «gère» un service, puis l'empackageer dans une unité de service systemd pour un deuxième service que l'on arrête alors de démarrer à l'arrêt, quand le but n'est 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 pour une input dans le système House of Horror.

Le monde veut que vous nettoyiez votre écran.

Vouloir ne pas effacer un terminal virtuel entre la déconnection et la connection subséquente nage beaucoup à contre-courant, comme Greg Wooledge et d'autres l'ont découvert. Depuis les années 70, la présence de sorties sensibles d'users privilégiés ou de patrons rest un problème de security pour les Unices (et bien d'autres systèmes d'exploitation à distance à access distant) et il faut beaucoup d'efforts pour annuler tout les choses que les gens ont mis pour éviter ce problème.

  • De nombreux systèmes ont une command clear_console dans leurs scripts de déconnection shell en standard. (Ceci est problématique à part entière car il ne fonctionne pas bien avec les programmes charts exécutés sur le terminal virtuel # 1 du kernel et ne fonctionne pas avec d'autres types de terminaux, virtuels ou réels).

    Cette command doit être supprimée.

  • La valeur par défaut des programmes getty destinés aux terminaux virtuels, tels que mingetty , consiste à effacer le terminal. (Il le fait avant la connection, ce qui signifie que la sortie du terminal peut restr non effacée si un service de connection TTY est arrêté. Ironiquement, cette fonctionnalité aurait été mieux placée lors de la login , qui fonctionne encore à la fermeture de session .)

    L'option --noclear doit être déployée pour désactiver cette option. Cela implique d'écrire un ou plusieurs files de rlocation de file d'unité, de modifier le paramètre ExecStart ou simplement de pointer autovt@.service dans un file d'unité locale de sa propre design.

  • L'unité de service model getty@.service fournie par systemd définit TTYVTDisallocate=yes qui request à systemd d'effacer un terminal virtuel du kernel. (Cela ne fonctionne toujours pas avec d'autres types de terminaux, pas même les terminaux virtuels de l'espace user, tels que reflétés en partie dans son nom.)

    Cela aussi doit être supprimé, encore une fois avec un override ou un autre model de service pointé par autovt@.service .

Plus de lecture

  • Jonathan de Boyne Pollard (2015). /etc/inittab appartient au passé. . Réponses fréquentes.
  • 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 abandonner les privilèges d'user. . Réponses fréquentes.
  • Greg Wooledge (2014-04-08). Arrêtez d'effacer ma console Damned Damned . Le Wiki de Greg.
  • Jonathan de Boyne Pollard (2015-08-22). Gel du système avec plusieurs ttys dans Debian Jessie . 55D8CF3E.6090704@NTLWorld.com. debian-user.
  • https://unix.stackexchange.com/a/194218/5132
  • Jonathan de Boyne Pollard (2015). Le systemd House of Horror . Réponses fréquentes.

Je travaille à partir de CentOS 7, qui peut avoir une configuration différente. Cependant, pour moi, l'invocation de getty est contrôlée par le file de service /usr/lib/systemd/system/getty@.service . (Le @ sert de model, il est lancé en tant que getty@tty1.service et la string tty1 est passée dans le file et contrôle quel TTY est exécuté). Dans ce file, il y a une ligne commençant par ExecStart= , qui spécifie la command line . Les options seraient ajoutées ici. (Il est préférable de ne pas modifier directement le file sous /usr car il pourrait être écrasé par les mises à jour du système, il faut le copyr quelque part sous /etc premier, probablement /etc/systemd/system . .)

Il semble que ce que vous voulez à l'arrêt / redémarrage ne soit pas géré en modifiant le process d'arrêt / redémarrage directement, mais en ajoutant l'action à la list des actions d'arrêt du service, que systemd effectuera automatiquement sur un arrêt du système ou un redémarrage ou lorsque vous désactivez manuellement le service avec systemctl ). Le moyen rapide de le faire est de transformer le script en une ligne ExecStop d'une command de service système; en fonction de la configuration, vous pouvez également créer un file de service user qui gouverne l'set et y installe l' ExecStop .