Exécuter un script lors du démarrage / démarrage; init.d vs cron @reboot

@reboot actuellement de comprendre la différence entre init.d et cron @reboot pour exécuter un script au démarrage / démarrage du système.

L'utilisation de @reboot (cette méthode a été mentionnée dans ce forum par hs.chandra ) est quelque chose de plus simple, en allant simplement dans crontab -e et en créant un @reboot /some_directory/to_your/script/your_script.txt et ensuite your_script.txt doit être exécuté à chaque redémarrage du système. Une explication en profondeur de @reboot est ici

Sinon, en intégrant /etc/init.d/your_script.txt dans la deuxième ligne de votre script, par exemple:

 #!/bin/bash # /etc/init.d/your_script.txt 

Vous pouvez exécuter chmod +x /etc/init.d/your_script.txt et cela devrait également résulter de l' your_script.txt de votre your_script.txt à chaque démarrage du système.

Q1: Quelles sont les principales différences entre les deux?
Q2: Quel est le plus robuste?
Q3: Y a t-il un meilleur sur les deux?
Q4: Est-ce la bonne façon d'intégrer un script à exécuter pendant le démarrage?

Je vais incorporer un file bash .sh à exécuter pendant le démarrage.

init.d , également appelé script SysV, est destiné à démarrer et à arrêter les services lors de l'initialisation et de l'arrêt du système. ( /etc/init.d/ scripts sont également exécutés sur les systèmes activés par le système pour la compatibilité).

  • Le script est exécuté pendant le démarrage et l'arrêt (par défaut).
  • Le script devrait être un script init.d, pas seulement un script. Il devrait soutenir le start et l' stop et plus encore (voir la politique Debian )
  • Le script peut être exécuté pendant le démarrage du système (vous pouvez définir quand).

crontab (et donc @reboot ).

  • cron exécutera n'importe quelle command ou script ordinaire, rien de spécial ici.
  • tout user peut append un script @reboot (pas seulement root)
  • sur un système Debian avec systemd: @reboot de cron est exécuté pendant le multi-user.target .
  • sur un système Debian avec SysV (not systemd), crontab (5) mentionne: Notez que le démarrage, pour @reboot, est le moment où le démon cron (8) démarre. En particulier, il se peut que certains démons système ou d'autres installations soient en cours de démarrage. Cela est dû à la séquence d'ordre de démarrage de la machine.
  • il est facile de programmer le même script au démarrage et périodiquement.

/etc/rc.local est souvent considéré comme laid ou déconseillé (au less par redhat ), mais il a quand même quelques fonctionnalités intéressantes:

  • rc.local exécutera n'importe quelle command ou script ordinaire, rien de spécial ici.
  • sur un système Debian avec SysV (pas systemd): rc.local était (presque) le dernier service à démarrer.
  • mais sur un système Debian avec systemd: rc.local est exécuté après network.target par défaut (pas network-online.target !)

Concernant network.target et network-online.target de systemd, lisez les services en cours d'exécution une fois le réseau actif .

Premièrement, une clarification est en ordre:

  • init.d est le directory qui stocke les scripts de contrôle des services, qui contrôlent le démarrage et l'arrêt des services tels que httpd ou cron
  • rc.local est un service qui permet l'exécution de scripts arbitraires dans le cadre du process de démarrage du système

Pour ce qui est de savoir s'il vaut mieux utiliser rc.local ou cron pour exécuter votre script, je pense qu'il s'agit plus d'une question d'esthétique que de praticité. cron , en tant que planificateur de tâches, est conçu comme une méthode pour effectuer la maintenance ou l'entretien d'une machine, comme la vérification des mises à jour, le nettoyage des caches ou la réalisation d'audits de security. Cela ne signifie pas qu'il est limité à l'exécution de ces fonctions, car il peut exécuter n'importe quel script ou command désiré à l'heure spécifiée (par exemple, @reboot ).

L'utilisation de rc.local , d'autre part, tomberait plus dans un type de configuration du système de la tâche, comme rc.local , en cours d'exécution par les machines init système, est généralement responsable de la configuration du réseau des machines, des services ou des environnements , ne se limite pas à cette tâche).

Ces deux points doivent cependant être tempérés par le fait que tous les systèmes init ne proposent pas de mécanisme rc.local , et que tous les démons cron ne proposent pas de balise @reboot psuedo.

Points bonus

Comme indiqué précédemment, init.d est le directory qui contient les scripts qui contrôlent les services pouvant être démarrés ou arrêtés sur votre système (au less sur les machines qui utilisent un SysV initialisation de type SysV ). Selon votre système d'initialisation et le but de votre script, il peut être raisonnable de convertir votre script en un script d'initialisation qui sera exécuté de la même manière qu'un service. Ceci, cependant, dépend fortement de votre système d'initialisation car le cadre entourant la façon dont ces files sont construits peut différer considérablement.

Dernier mot

Il convient également de noter que les scripts bash se terminent généralement par un suffixe .sh plutôt que .txt , car cela indique immédiatement que le file est un script shell au lieu d'un file text. Cela étant dit, à condition qu'il ait un shebang ( #!/bin/bash ) en haut du file, ou s'appelle bash /path/to/script.whatever , cela n'a pas d'importance en termes d'exécution du script .

J'écris ma réponse ci-dessous;

Q1: Quelles sont les principales différences entre les deux?

Mis à part les différences mentionnées par les autres users ci-dessus, je voudrais souligner le fait que @reboot dépend du démon crond. Vous dépendez de l'ordre dans lequel débute le crond. Bien que la plupart des cas, crond commence bien mais il peut échouer un certain time pour commencer (au less j'ai vu quelques échecs dans certains de mes projets). Lorsque vous écrivez un script d'initialisation, l'échec se produit généralement si vous faites quelque chose de mal dans votre script (ex: countr sur un service qui démarrera après votre service)

Q2: Quel est le plus robuste?

Basé sur ci-dessus, je pense que init est plus robuste. Mais il y a un autre point mentionné par "Franklin Piat" dans la première réponse. Habituellement, vous avez besoin d'un script d'initialisation pour un démon et vous devez suivre la politique

Q3: Y a-t-il un meilleur sur les deux?

Je ne pense pas (rc.local est un peu vieux et déconseillé)

Q4: Est-ce la bonne façon d'intégrer un script à exécuter pendant le démarrage?

Oui. Habituellement, les auteurs d'applications / packages le font de cette façon.