Par défaut, avec la plupart des démons cron que j'ai vus, il n'y a tout simplement aucun moyen de dire à cron de s'exécuter ici et maintenant. Si vous utilisez anacron, il est possible, je pense, d'exécuter une instance séparée en avant-plan.
Si vos scripts ne s'exécutent pas correctement, alors vous ne tenez pas compte du fait que
- le script est exécuté sous un utilisateur particulier
- cron a un environnement restreint (la manifestation la plus évidente de ceci est un chemin différent).
De crontab(5) :
Plusieurs variables d'environnement sont définies automatiquement par le démon cron(8) daemon. Shell est défini comme /bin/sh, et LOGNAME et HOME sont définis à partir de la ligne /etc/passwd de l'utilisateur de la crontab. propriétaire. PATH est défini à "/usr/bin:/bin". HOME, Shell, et PATH peuvent être remplacés par des paramètres dans la crontab ; LOGNAME est l'utilisateur à partir duquel la tâche travail s'exécute, et ne peut pas être être modifié.
En général, PATH est le plus gros problème, donc vous devez :
- Définissez explicitement le PATH dans le script, pendant le test, à /usr/bin:/bin. Vous pouvez le faire dans bash avec export PATH="/usr/bin:/bin"
- Définissez explicitement le PATH approprié que vous souhaitez en haut de la crontab, par exemple PATH="/usr/bin:/bin:/usr/local/bin:/usr/sbin:/sbin".
Si vous devez exécuter le script en tant qu'autre utilisateur sans script (par exemple www-data), utilisez sudo :
sudo -u www-data /path/to/crontab-script.sh
La première chose à tester avant tout cela, bien sûr, est que votre script fait effectivement ce qu'il est censé faire à partir de la ligne de commande. Si vous ne pouvez pas l'exécuter depuis la ligne de commande, il ne fonctionnera évidemment pas depuis avec cron.
0 votes
(désolé, je ne peux pas ajouter de commentaire) 0 30 16 20 * ? * même si vous exécutez le job comme ça, l'idée est de fournir une sortie script pour voir ce qui ne va pas à moins que le job n'écrive dans un log, c'est quuiet inutile.