Je ne trouve pas la bonne façon d'exécuter certains éléments local scripts (ou commandes très locales) chez 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 consiste à créer rc.local et à lui donner des autorisations d'exécution.
printf '#!/bin/bash nnexit 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 cela va faire mal de mettre à niveau ou d'installer quelque chose de nouveau sur la distribution, car rc.local était respecté par externe packages, mais d'un autre côté 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 peut-être installés sur une mise à jour, causant des problèmes pour mes scripts !
Je vois une autre question demander où est rc.local et la réponse était de le créer et de donner des autorisations d'exécution, je pense que ma question n'est vraiment pas un double , parce que je ne veux pas savoir où il se trouve - croyez-moi, je veux juste accepter qu'il est obsolète , mais je ne trouve pas la bonne façon de faire ce genre de choses, dois-je vraiment créer une unité juste pour une simple comme ça ?
Réponse acceptée :
Comme indiqué ailleurs, il devient modérément impur d'utiliser rc-local.service sous systemd .
- Il est théoriquement possible que votre distribution ne l'active 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/rebootcommandes que beaucoup de gens utilisent). - La sémantique n'est pas entièrement claire. Systemd définit
rc-local.servicedans un sens, mais Debian fournit un fichier d'insertion qui modifie au moins un paramètre important.
rc-local.service peut souvent bien fonctionner. Si vous êtes inquiet à propos de ce qui précède, tout ce que vous avez à faire est 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.
-
Vous devez l'activer avec
systemctl enable my-startup.service. -
Si votre script dépend d'un autre service, y compris
network-online.target, vous devez le déclarer. Par exemple. ajouter un[Unit]section, avec les lignesWants=network-online.targetetAfter=network-online.target.Vous n'avez pas à vous soucier des dépendances sur les services de "démarrage anticipé" - en particulier, les services qui sont déjà commandés avant
basic.target. Des services commemy-startup.servicesont automatiquement classés aprèsbasic.target, à moins qu'ils ne définissentDefaultDependencies=no.Si vous ne savez pas si l'une de vos dépendances est un service de "démarrage anticipé", une approche consiste à répertorier les services commandés avant
basic.target, en exécutantsystemctl list-dependencies --after basic.target. (Notez que c'est--after, pas--before).
Il y a certaines considérations qui, je pense, s'appliquent également à rc.local pré-systemd :
- Vous devez vous assurer que vos commandes n'entrent pas en conflit avec un autre programme qui essaie de contrôler la même chose.
- Il est préférable de ne pas lancer de programmes de longue durée, c'est-à-dire des démons depuis
rc.local.
[*] J'ai utilisé Type=oneshot + RemainAfterExit=yes car cela a plus de sens pour la plupart des scripts ponctuels. Il formalise que vous exécuterez une série de commandes, que my-startup seront affichés comme "actifs" une fois qu'ils seront terminés, et que vous ne démarrerez pas de démon.