web-dev-qa-db-fra.com

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

J'essaie 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 un peu plus simple, en allant simplement dans crontab -e et en créant un @reboot /some_directory/to_your/script/your_script.txt et alors your_script.txt doit être exécuté à chaque redémarrage du système. Une explication approfondie de @reboot est ici

Alternativement en intégrant /etc/init.d/your_script.txt dans la deuxième ligne de votre script ie:

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

Tu peux courir chmod +x /etc/init.d/your_script.txt et cela devrait également résulter pour your_script.txt pour s'exécuter à 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 des deux?
Q4: Est-ce la bonne façon d'incorporer un script à exécuter pendant le démarrage?

J'incorporerai un fichier bash .sh à exécuter lors du démarrage.

scriptingcronstartupinit-scriptsysvinit
52
3kstc

init.d, également connu sous le nom de script SysV, est destiné à démarrer et arrêter les services pendant l'initialisation et l'arrêt du système. (Les scripts /etc/init.d/ Sont également exécutés sur des systèmes compatibles systemd pour des raisons de compatibilité).

  • Le script est exécuté pendant le démarrage et l'arrêt (par défaut).
  • Le script doit être un script init.d, pas seulement un script. Il devrait prendre en charge start et stop et plus (voir 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 commande ou script ordinaire, rien de spécial ici.
  • tout utilisateur peut ajouter un script @reboot (pas seulement root)
  • sur un système Debian avec systemd: @reboot de cron est exécuté pendant multi-user.target.
  • sur un système Debian avec SysV (pas systemd), crontab (5) mentionne: Veuillez noter que le démarrage, en ce qui concerne @reboot, est le moment où le démarrage du démon cron (8). En particulier, cela peut se produire avant le démarrage de certains démons système ou d'autres fonctionnalités. Cela est dû à la séquence d'ordre de démarrage de la machine.
  • il est facile de planifier le même script au démarrage et périodiquement.

/etc/rc.local est souvent considéré comme moche ou obsolète (au moins par redhat ), mais il en avait encore Belles fonctionnalités:

  • rc.local exécutera n'importe quelle commande 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!)

En ce qui concerne network.target Et network-online.target De systemd, lisez Exécution des services une fois le réseau activé .

39
Franklin Piat

Tout d'abord, une clarification s'impose:

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

Pour savoir s'il vaut mieux utiliser rc.local ou cron pour exécuter votre script, je soupçonne que c'est plus 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 sécurité. Cela ne signifie pas qu'il est limité à l'exécution de ces fonctions, car il peut exécuter n'importe quel script ou commande souhaité à l'heure spécifiée (comme @reboot).

En utilisant rc.local, d'autre part, relèverait davantage d'un type de tâche de configuration système, comme rc.local, exécuté par le système d'initialisation des machines, est généralement responsable de la définition de la configuration réseau, des services ou des environnements des machines (mais là encore, il ne se limite pas à cette tâche).

Cependant, ces deux points doivent être tempérés par le fait que tous les systèmes init n'offrent pas un rc.local mécanisme, et tous les démons cron n'offrent pas un @reboot balise psuedo.

Points bonus

Comme mentionné, init.d est le répertoire qui contient les scripts qui contrôlent les services qui peuvent être démarrés ou arrêtés sur votre système (au moins sur les machines qui utilisent un système init de type SysV). En fonction de votre système d'initialisation et de l'objectif de votre script, il peut être raisonnable de convertir votre script en script d'initialisation à exécuter de la même manière que un service. Cependant, cela dépend fortement de votre système d'initialisation car le cadre entourant la façon dont ces fichiers 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 fichier est un script Shell au lieu d'un fichier texte. Cela étant dit, à condition qu'il ait soit un Shebang (#!/bin/bash) en haut du fichier, ou s'appelle bash /path/to/script.whatever, peu importe l'exécution du script.

12
wraeth

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

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

Outre les différences mentionnées par les autres utilisateurs ci-dessus, je voudrais souligner le fait que @reboot dépend du démon crond. Vous dépendez de l'ordre de démarrage de crond. Bien que la plupart des cas, crond démarre bien mais il peut échouer à certains moments (au moins j'ai vu des échecs dans certains de mes projets). Lorsque vous écrivez un script d'initialisation, un échec se produit généralement si vous faites quelque chose de mal dans votre script (un ex: en s'appuyant sur un service qui démarrera après votre service)

Q2: Quel est le plus robuste?

Sur la base de ce qui précède, je pense que l'init est plus robuste. Mais il y a un autre point tel que mentionné par "Franklin Piat" dans la première réponse. Habituellement, vous avez besoin d'un script init pour un démon et vous devez suivre la politique

Q3: Y en a-t-il un meilleur des deux?

Je ne pense pas (rc.local est un peu vieux et obsolète)

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

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

3
shubham