Les travaux cron.daily ne fonctionnent pas
J'ai créé 3 tâches journalières à exécuter.
Ci-dessous sont les trois qui sont placés dans etc/cron.daily
rkhunter.sh
#!/bin/sh
(
rkhunter --versioncheck
rkhunter --update
rkhunter --cronjob --report-warnings-only
) | mail -s 'rkhunter Daily Run (my server)' [email protected]
chkrootkit.sh
#!/bin/bash
chkrootkit | mail -s "chkrootkit Daily Run (my server)" [email protected]
logwatch.sh
#!/bin/sh
(
logwatch
) | mail -s 'logwatch Daily Log (my server)' [email protected]
J'ai remplacé [email protected] ofcourse par mon email.
Si j'exécute ce travail manuellement, cela fonctionne correctement. ./nameoffile.sh
Mais cela ne fonctionne pas tous les jours, quelle peut en être la cause ou comment puis-je vérifier cela?
Deux suspects possibles empêchent généralement l'exécution des travaux cron.
Le premier concerne les problèmes d'autorisations, c'est-à-dire qu'un utilisateur peut exécuter le script/la commande, mais le démon cron ne le peut pas, car le travail se trouve dans les travaux cron de l'utilisateur incorrect. Par exemple, l'utilisateur crée un script ou exécute une commande avec des privilèges élevés, à l'aide de Sudo, puis ajoute le script/la commande testé à sa liste de tâches cron (crontab). Il en résulte que le travail périodique de l'utilisateur ne pourra pas être exécuté car il nécessite des privilèges élevés.
- Pour placer un travail cron dans le type de crontab de l'utilisateur actuel,
crontab -e - Pour placer un travail cron dans le fichier crontab de la racine,
Sudo crontab -e
La deuxième raison est les chemins, afin de s'assurer que le script s'exécutera, l'utilisateur doit ajouter le chemin complet du script à exécuter dans la crontab. Une autre solution consisterait à développer la variable PATH des utilisateurs racine en plaçant la ligne suivante en haut de leur fichier crontab:
PATH=/usr/sbin:/usr/bin:/sbin:/bin
en tant que wiki de la communauté mentions .
Vous voudrez peut-être lire le wiki de la communauté à propos de cron car il fournit des détails supplémentaires sur ce qui précède.
Selon la réponse de this , le problème réside dans l'extension .sh. Supprimez cela (par exemple, renommez votre fichier de rkhunter.sh en rkhunter.
Pour confirmer, exécutez la commande suivante run-parts --test /etc/cron.daily
Si votre script (rkhunter) est inclus dans les résultats, tout va bien. Pour plus d'informations sur la commande run-parts, lisez les pages de manuel correspondantes. man run-parts
Dans mon système, c'était parce que l'anacron n'était pas installé.
grep run-parts /etc/crontab
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
Donc, soit installer anacron ou supprimer le test -x/usr/sbin/anacron
Je pense que les fichiers avec des extensions sont ignorés.
courir:
run-parts --test /etc/cron.daily
Si vos scripts ne figurent pas dans la liste, supprimez les extensions .sh et réessayez.
En ajoutant à la réponse de Stef, vous devez également vous assurer qu’ils ont le bit exécutable:
$ ls -l
-rwxr-xr-x 1 root root 268 Jun 1 08:06 00logwatch
-rwxr-xr-x 1 root root 311 May 22 2012 0anacron
-rwxr-xr-x 1 root root 15007 Jun 6 14:08 apt
Vous devriez pouvoir les utiliser avec chmod +x filename.
Renommez votre fichier pour ne pas avoir l'extension .sh
Pour vérifier que c'est bien le problème, essayez
Sudo run-parts --list /etc/cron.daily
vous verrez que ce n'est pas répertorié. Alors courez:
mv script.sh script
et essayez de lister à nouveau. Il devrait être répertorié.
Je ne pouvais pas le faire fonctionner avec anacron, j'ai supprimé anacron de /etc/crontab et exécuté apt remove --purge anacron et tout fonctionne immédiatement.
Je ne comprends pas pourquoi nous avons besoin de deux planificateurs.