Exécuter un script Bash au démarrage Linux

a marqué ce sujet comme résolu.

Bonjour, je souhaite exécuter un script Bash au démarrage de ma Raspberry ce script permet de lancer un programme Python. Je sais, normalement, effectuer cette tâche seulement cette fois ci, cela ne fonctionne pas. J’ai essayé avec crontab, init.d et rc.local mais aucun ne fonctionne.

Merci pour votre aide ! ;)

+0 -0

Hello, tu as tenté quoi avec crontab exactement ? As-tu une erreur dans les logs ?

viki53

J’ai ajouté la ligne @reboot /chemin/script.sh, les logs me signalent quelque chose comme "no MTA detected…" (je ne sais plus exactement). J’ai fais quelques recherches la dessus, j’ai essayé d’installer Postfix, j’ai aussi essayé de faire sans MTA mais cela ne fonctionne pas non plus.

+0 -0

Quelques questions me viennent à l’esprit :

  1. Quelle version de quelle implémentation de crontab utilises-tu ? Ou, si c’est celle par défaut de ta distribution, quelle distribution utilises-tu et dans quelle version ?
  2. Es-tu bien dans la crontab système ? (voir la documentation de l’implémentation utilisée —d’où la question précédente— mais habituellement /etc/crontab et éventuellement d’autres fichiers liés par exemple dans /etc/cron/)
    • Si oui, il manque le compte qui doit exécuter le script (la ligne devrait ressembler à @reboot user /chemin/script.sh…)
    • Si non, il faut voir dans la documentation de ton implémentation ce qui est autorisé ; en général @reboot n’est possible que dans une table système…
  3. Es-ce que /chemin/script.sh est bien accessible au compte qui va lancer le script ? Et est-ce que le fichier est exécutable ? (crontab ne lit pas les fichiers, ça lance des commandes…)

Pour le MTA, c’est parce-que crontab essaie de notifier qu’il y a une erreur. Si ton système n’est pas configuré pour envoyer des mails, il faut configurer la délivrance locale, et dans ce cas tu devrais avoir un fichier ou dossier local des messages qui est consultable en ligne de commande en lançant mailx… (ou en utilisant un pager comme less sur le fichier.)

+2 -0

Quelques questions me viennent à l’esprit :

  1. Quelle version de quelle implémentation de crontab utilises-tu ? Ou, si c’est celle par défaut de ta distribution, quelle distribution utilises-tu et dans quelle version ?
  2. Es-tu bien dans la crontab système ? (voir la documentation de l’implémentation utilisée —d’où la question précédente— mais habituellement /etc/crontab et éventuellement d’autres fichiers liés par exemple dans /etc/cron/)
    • Si oui, il manque le compte qui doit exécuter le script (la ligne devrait ressembler à @reboot user /chemin/script.sh…)
    • Si non, il faut voir dans la documentation de ton implémentation ce qui est autorisé ; en général @reboot n’est possible que dans une table système…
  3. Es-ce que /chemin/script.sh est bien accessible au compte qui va lancer le script ? Et est-ce que le fichier est exécutable ? (crontab ne lit pas les fichiers, ça lance des commandes…)

Pour le MTA, c’est parce-que crontab essaie de notifier qu’il y a une erreur. Si ton système n’est pas configuré pour envoyer des mails, il faut configurer la délivrance locale, et dans ce cas tu devrais avoir un fichier ou dossier local des messages qui est consultable en ligne de commande en lançant mailx… (ou en utilisant un pager comme less sur le fichier.)

Gil Cot

Je suis sur Debian 11, c’est celle par défaut. Le script est bien exécutable. Lorsque je tape crontab -e, j’arrive dans /tmp/crontab.VdE0y2/crontab.

+0 -0

Par défaut, c’est une vixie-cron twicked for Debian. (j’avais lu que ça allait peut-être devenir cronie après Buster mais je ne sais pas où ça en est et si ce n’est pas systemd-cron qui est par défaut…) De mémoire (mais je suis pas sûr), contrairement au vixie-cron original, ça supporte @reboot.

L’autre point : la commande crontab -e va te faire éditer la table pour l’utilisateur qui l’a lancé. Le chemin, dans /tmp/ va varier et la table finale sauvegardée sera normalement dans /var/spool/cron/crontabs/ (ne pas éditer directement, la commande dédiée passe par un fichier temporaire pour de bonnes raisons.) :) À vérifier si les tables utilisateurs supportent @reboot (de mémoire non.)
Par contre, les tables systèmes vont être dans /etc/cron.d/ qu’il faut éditer manuellement après avoir créé le fichier qui va bien (il ne faut pas toucher aux qui sont créés et modifiés par les applis) : par exemple /etc/cron.d/localhost. Il n’y a pas de commande pour manipuler les tables systèmes, et il faut faire très attention en les éditant (pas de droit à l’erreur on va dire) : ici il faut bien spécifier le compte qui va exécuter la tâche, donc la forme @reboot login /chemin/script.sh

+0 -0

Par défaut, c’est une vixie-cron twicked for Debian. (j’avais lu que ça allait peut-être devenir cronie après Buster mais je ne sais pas où ça en est et si ce n’est pas systemd-cron qui est par défaut…) De mémoire (mais je suis pas sûr), contrairement au vixie-cron original, ça supporte @reboot.

L’autre point : la commande crontab -e va te faire éditer la table pour l’utilisateur qui l’a lancé. Le chemin, dans /tmp/ va varier et la table finale sauvegardée sera normalement dans /var/spool/cron/crontabs/ (ne pas éditer directement, la commande dédiée passe par un fichier temporaire pour de bonnes raisons.) :) À vérifier si les tables utilisateurs supportent @reboot (de mémoire non.)
Par contre, les tables systèmes vont être dans /etc/cron.d/ qu’il faut éditer manuellement après avoir créé le fichier qui va bien (il ne faut pas toucher aux qui sont créés et modifiés par les applis) : par exemple /etc/cron.d/localhost. Il n’y a pas de commande pour manipuler les tables systèmes, et il faut faire très attention en les éditant (pas de droit à l’erreur on va dire) : ici il faut bien spécifier le compte qui va exécuter la tâche, donc la forme @reboot login /chemin/script.sh

Gil Cot

Pour ma part, je suis le seul utilisateur de ma machine, je ne sais pas si c’est forcément utile du coup de spécifier un utilisateur ? J’avais fait la même manipulation sur une Raspberry Pi 3B (de mémoire) et cela fonctionnait parfaitement sans avoir à rajouter quoi que ce soit, mais s’il faut passer par là je le ferai c’est pas grand chose.

+0 -0

C’est juste que je n’ai pas de quoi vérifier sous la main ; mais si @reboot marche en mode utilisateur ça ne changera en effet pas ta problématique.

Je croyais l’avoir mentionné mais je viens de voir que non. Il faut que ton script fonctionne en mode non interactif… Quand tu le testes dans ta session, tu es en mode interactif or ce ne sera pas le cas pour cron. Du coup, tes alias par exemple ne seront pas reconnus et (pernicieux) certaines commandes ne seront pas trouvées car les répertoires de recherche des commandes ne sont pas les mêmes. Il y aussi (rare et plus pernicieux) le cas des commandes qui ne fonctionnent que en mode interactif ou alors en spécifiant l’option qui va bien.

+0 -0

C’est juste que je n’ai pas de quoi vérifier sous la main ; mais si @reboot marche en mode utilisateur ça ne changera en effet pas ta problématique.

Je croyais l’avoir mentionné mais je viens de voir que non. Il faut que ton script fonctionne en mode non interactif… Quand tu le testes dans ta session, tu es en mode interactif or ce ne sera pas le cas pour cron. Du coup, tes alias par exemple ne seront pas reconnus et (pernicieux) certaines commandes ne seront pas trouvées car les répertoires de recherche des commandes ne sont pas les mêmes. Il y aussi (rare et plus pernicieux) le cas des commandes qui ne fonctionnent que en mode interactif ou alors en spécifiant l’option qui va bien.

Gil Cot

Bonjour, désolé pour cette réponse tardive.

Ce que je n’arrive pas a comprendre c’est que j’ai déjà effectué ce genre de commande sur d’autres raspberry de même version avec les mêmes paramètres et cela marchait bien sans encombres. Je souhaite simplement lancer mon script au démarrage de la raspberry… Autrement si vous avez d’autres manières de faire je suis aussi preneur. Tant que le résultat est le même, le chemin importe peu.

Merci ! :)

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte