Je ne trouve pas la bonne façon d'exécuter certains scripts locaux (ou des commandes très locales) sur systemd, je sais déjà que je ne dois pas créer de service (dans systemd une unité) pour ce genre de scripts (ou je dois?) ....

La solution de contournement que j'ai trouvée est de créer rc.local et de lui donner des autorisations d'exécution.

printf '#!/bin/bash \n\nexit 0' >/etc/rc.local 
chmod +x /etc/rc.local

Par exemple, si j'obtiens un serveur hérité avec un simple rc.local configuré par vous, je saurai ce que vous avez fait et combien ça va faire mal de mettre à niveau ou d'installer quelque chose de nouveau sur la distribution, car rc.local a été respecté par les externes packages, mais d'autre part si j'installe un serveur et crée une unité systemd ou deux ou trois (ou même des services sysvinit), juste pour faire une tâche simple, cela peut parfois vous rendre la vie plus difficile, et bien plus que cela mes unités les noms peuvent un jour entrer en conflit avec les noms des nouveaux services créés par le développement de la distribution, et peuvent être installés sur une mise à niveau, causant des problèmes pour mes scripts!

Je vois une autre question demandant où est rc.local et la réponse a été de le créer et de donner des autorisations d'exécution, je pense que ma question n'est vraiment pas un doublon , parce que je ne veux pas savoir où elle est - croyez-moi, je veux juste d' accepter qu'il est obsolète , mais je ne trouve pas la bonne façon de faire ce genre de choses, devrais-je vraiment créer une unité juste pour quelques simples comme ça?

Comme indiqué ailleurs, il devient modérément impur à utiliser rc-local.servicesous systemd.

1. Il est théoriquement possible que votre distribution ne le permette pas. (Je pense que ce n'est pas courant, par exemple parce que la désactivation de la même option de construction supprime également poweroff/reboot commandes que beaucoup de gens utilisent).
2. La sémantique n'est pas entièrement claire. Systemd définit rc-local.serviceune façon, mais Debian fournit un fichier de dépôt qui modifie au moins un paramètre important.

rc-local.servicepeut souvent bien fonctionner. Si vous vous inquiétez de ce qui précède, il vous suffit d'en faire votre propre copie! Voici la magie:

# /etc/systemd/system/my-startup.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/libexec/my-startup-script

[Install]
WantedBy=multi-user.target

Je ne pense pas que vous ayez besoin de comprendre chaque détail [*], mais il y a deux choses que vous devez savoir ici.

1. Vous devez l'activer avec systemctl enable my-startup.service.

2. Si votre script a une dépendance sur tout autre service, y compris network-online.target, vous devez le déclarer. Par exemple, ajoutez une [Unit]section, avec les lignes Wants=network-online.targetetAfter=network-online.target .

   Vous n'avez pas à vous soucier des dépendances des services de "démarrage précoce" - en particulier, les services qui sont déjà commandés auparavant basic.target. Les services comme my-startup.servicesont automatiquement commandés après basic.target, sauf s'ils sont définis DefaultDependencies=no.

   Si vous ne savez pas si l'une de vos dépendances est un service de «démarrage rapide», une approche consiste à répertorier les services qui sont commandés avant basic.target, en exécutant systemctl list-dependencies --after basic.target. (Notez que ce n'est --afterpas le cas --before).

Il y a quelques considérations qui, je pense, s'appliquent également à la version pré-système rc.local:

1. Vous devez vous assurer que vos commandes ne sont pas en conflit avec un autre programme qui essaie de contrôler la même chose.
2. Il est préférable de ne pas démarrer de programmes de longue durée appelés démons rc.local.

[*] J'ai utilisé Type=oneshot+ RemainAfterExit=yescar cela a plus de sens pour la plupart des scripts one-shot. Il formalise que vous exécuterez une série de commandes, qui my-startupseront affichées comme "actives" une fois qu'elles seront terminées, et que vous ne démarrerez pas un démon.

Oubliez rc.local.

Comme je l'ai dit à propos de CentOS 7 et de Debian 8 et d'Ubuntu 15 :

Vous utilisez un système d'exploitation systemd + Linux. /etc/rc.localest un mécanisme de double compatibilité descendante dans systemd, car il s'agit d'un mécanisme de compatibilité descendante pour un mécanisme qui était lui-même un mécanisme de compatibilité dans le système van Smoorenburg 5rc clone .

L'utilisation /etc/rc.localpeut mal tourner. Les gens ont été surpris par le fait que systemd ne fonctionne rc.localpas de la même manière, au même endroit dans le bootstrap, comme ils sont habitués. (Ou attendez-vous à tort: ​​en fait, il ne fonctionnait pas en dernier dans l'ancien système, comme le souligne encore le manuel d'OpenBSD.) D'autres ont été surpris par le fait que ce qu'ils ont mis en place en rc.locals'attendant aux anciennes façons de faire, est puis complètement défaits par les goûts de nouvelles udevrègles, NetworkManager, systemd-logind, systemd-resolvedou divers « Kit » s.

Comme illustré par « Pourquoi« init 0 »entraîne-t-il des« Arguments excédentaires »lors de l'installation d'Arch? », Certains systèmes d'exploitation fournissent déjà systemd sans les fonctionnalités de compatibilité descendante telles que le systemd-rc-local-generatorgénérateur . Alors que Debian conserve toujours les fonctionnalités de compatibilité descendante , Arch Linux construit systemd avec elles désactivées . Ainsi, sur Arch et les systèmes d'exploitation comme celui-ci, ils /etc/rc.local devraient être entièrement ignorés .

Oubliez rc.local. Ce n'est pas la voie à suivre. Vous avez un système d'exploitation systemd + Linux. Faites donc une unité de service systemd appropriée et ne partez pas d'un point qui est à deux niveaux de compatibilité descendante. (Sur Ubuntu et Fedora, il a été supprimé à trois reprises, le rcclone van Smoorenburg System 5 qui a suivi rc.localayant ensuite été lui-même remplacé deux fois , il y a plus de dix ans, d'abord par un parvenu puis par systemd.)

Souvenez-vous également de la première règle de migration vers systemd .

Ce n'est même pas une nouvelle idée spécifique à systemd. Sur les rcsystèmes van Smoorenburg et Upstart, la chose à faire était de créer un rcscript van Smoorenburg ou un fichier de travail Upstart approprié plutôt que de l'utiliser rc.local. Même le manuel de FreeBSD note qu'aujourd'hui, on crée un rcscript Mewburn approprié au lieu de l'utiliser /etc/rc.local. Mewburn a rcété introduit par NetBSD 1.5 en 2000.

/etc/rc.localdate de l'époque de la septième édition Unix et avant. Il a été remplacé /etc/inittabet basé rcsur un niveau d'exécution dans AT&T Unix System 3 (avec un peu différent /etc/inittabdans AT&T Unix System 5) en 1983 . Même cela appartient désormais à l'histoire.

Créez des définitions de service natives appropriées pour votre système de gestion des services, qu'il s'agisse d'un ensemble de services pour l'ensemble d'outils Nosh service-manageret system-control, d'un /etc/rc.d/script pour Mewburn rc, d'un fichier d'unité de service pour systemd, d'un fichier de travail pour Upstart, d'un répertoire de service pour runit / s6 / daemontools -encore, ou même un /etc/init.d/script pour van Smoorenburg rc.

Dans systemd, ces fichiers d'unité de service ajoutés par l'administrateur entrent /etc/systemd/system/généralement (ou /usr/local/lib/systemd/system/rarement). Avec le nosh service manager, /var/local/sv/est un lieu conventionnel pour les bundles de services locaux. Mewburn rcsur les utilisations de FreeBSD /usr/local/etc/rc.d/. Les fichiers d'unité de service et les packs de services, si vous les créez, vont cependant à des endroits différents.

Lectures complémentaires

• Lennart Poettering et al. (2014). systemd-rc-local-generator . pages de manuel de systemd. Freedesktop.org.
• rc.local. Manuel du gestionnaire de système FreeBSD . 2016-04-23.
• /unix//a/233581/5132
• Lennart Poettering (29/08/2011). Plese retirer /etc/rc.localou chmod -xil . Bogue Redhat # 734268.
• /unix//a/211927/5132
• Dirk Schmitt (2017-12-19). rc.localcommence trop tôt . bogue systemd # 7703
• https://wiki.archlinux.org/index.php?title=Systemd&diff=378926&oldid=378924
• Benjamin Cane (30/12/2011). Quand c'est ok et pas ok à utiliserrc.local . bencane.com.
• /unix//a/49636/5132
• Lennart Poettering (2010-10-01). Comment convertir un script d'initialisation SysV en un fichier de service systemd? . 0pointer.de.
• /ubuntu/523369/
• Jonathan de Boyne Pollard (2015). /etc/inittabappartient au passé. . Réponses fréquemment données.
• Jonathan de Boyne Pollard (2014). Un regard côte à côte sur les scripts d'exécution et les unités de service. . Réponses fréquemment données.
• Jonathan de Boyne Pollard (2014). Un exemple concret de la mise en place et de l'exécution d'un service avec nosh . Logiciels.
• Jonathan de Boyne Pollard (2016). Msgstrsystemd.unit " Chemins de recherche système manquants dans la page de manuel ". Errata pour systemd doco . Réponses fréquemment données.

Résumé de https://www.linuxbabe.com/linux-server/how-to-enable-etcrc-local-with-systemd

Créez /etc/systemd/system/rc-local.service:

# /etc/systemd/system/rc-local.service
[Unit]
 Description=/etc/rc.local Compatibility
 ConditionPathExists=/etc/rc.local

[Service]
 Type=forking
 ExecStart=/etc/rc.local start
 TimeoutSec=0
 StandardOutput=tty
 RemainAfterExit=yes
 SysVStartPriority=99

[Install]
 WantedBy=multi-user.target

Ensuite:

sudo touch /etc/rc.local
sudo chmod +x /etc/rc.local
sudo systemctl enable rc-local

Vérifier avec:

sudo systemctl start rc-local.service
sudo systemctl status rc-local.service