J'essaie actuellement de comprendre la différence entre init.det cron @rebootpour l'exécution d'un script au démarrage / au 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 -eet en créant un @reboot /some_directory/to_your/script/your_script.txtet devant your_script.txtêtre exécuté à chaque fois que le système est redémarré. Une explication détaillée de @rebootest ici

Alternativement, en intégrant /etc/init.d/your_script.txtdans la deuxième ligne de votre script, à savoir:

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

Vous pouvez exécuter chmod +x /etc/init.d/your_script.txtet cela devrait également avoir pour résultat your_script.txtd'exécuter chaque fois que le système est démarré.

Q1: Quelles sont les principales différences entre les deux?
Q2: Lequel 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 lors du démarrage?

Je vais incorporer un fichier .sh bash à exécuter au démarrage.

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

• Le script est exécuté lors du démarrage et de l'arrêt (par défaut).
• Le script doit être un script init.d, pas seulement un script. Il devrait supporter startet stopet plus (voir politique Debian )
• Le script peut être exécuté lors du démarrage du système (vous pouvez définir quand).

crontab(et donc @reboot).

• cron exécutera toute commande ou script habituel, rien de spécial ici.
• n'importe quel utilisateur peut ajouter un @rebootscript (pas seulement root)
• sur un système Debian avec systemd: la commande @reboot de cron est exécutée 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émon cron (8) démarre. Cela peut notamment être le cas avant que certains démons du système, ou d’autres installations, ne soient démarrés. Cela est dû à la séquence de démarrage de la machine.
• il est facile de planifier le même script au démarrage et périodiquement.

/etc/rc.localest souvent considéré comme laid ou déprécié (du moins par redhat ), mais il présentait encore quelques fonctionnalités intéressantes:

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

En ce qui concerne systemd network.targetet network-online.target, lisez Running Services After the Network .

Tout d'abord, une clarification s'impose:

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

Quant à savoir s’il vaut mieux utiliser rc.localou cronexécuter votre script, je suppose que c’est davantage une question d’esthétique que de fonctionnalité. cron, en tant que planificateur de tâches, est conçu comme une méthode permettant d’effectuer des opérations de maintenance ou d’entretien sur une machine, telles que 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 (telle que @reboot).

L’utilisation rc.local, par contre, relèverait davantage d’une tâche de configuration système, car rc.local, exécutée par le système init de la machine, elle est généralement responsable de la configuration de la configuration réseau, des services ou des environnements de la machine (mais là encore, elle n’est pas limitée à cette tâche).

Cependant, ces deux points devraient être tempérés par le fait que tous les systèmes init n'offrent pas de rc.localmécanisme et que tous les démons cron n'offrent @rebootpas de balise psuedo.

Points bonus

Comme indiqué précédemment, init.dle répertoire contient les scripts qui contrôlent les services pouvant être démarrés ou arrêtés sur votre système (au moins sur les ordinateurs utilisant un SysVsystème de type init). En fonction de votre système init et de l'objectif de votre script, il peut être raisonnable de convertir votre script en script init pour qu'il soit exécuté de la même manière qu'un service. Ceci, cependant, dépend fortement de votre système init car le cadre entourant la manière dont ces fichiers sont construits peut être très différent.

Dernier mot

Il convient également de noter que les scripts bash se terminent généralement par un suffixe .shplutô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 que soit il a un shebang ( #!/bin/bash) en haut du fichier, ou est appelé en tant que bash /path/to/script.whatever, cela ne devrait pas importer en termes d'exécution du script.

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

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

Outre les différences mentionnées par d'autres utilisateurs ci-dessus, je voudrais souligner le fait que @reboot dépend du démon crond. Vous êtes dépendant de l'ordre dans lequel crond commence. Bien que la plupart des cas, crond commence bien, mais il peut ne pas réussir à démarrer (au moins, j'ai vu des échecs dans certains de mes projets). Lorsque vous écrivez un script init, un échec survient généralement si vous faites quelque chose de mal dans votre script (par exemple, en vous fiant à un service qui démarrera après votre service).

Q2: Lequel 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 du script init pour un démon et vous devez suivre la politique

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

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

Q4: Est-ce la bonne façon d’incorporer un script à exécuter lors du démarrage?

Oui. Habituellement, les rédacteurs d’application / package le font de cette manière.