cron.daily ne fonctionne pas

19

J'ai créé 3 tâches cron quotidiennes à exécuter.

Voici 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)' me@email.com

chkrootkit.sh

#!/bin/bash
chkrootkit | mail -s "chkrootkit Daily Run (my server)" me@email.com

logwatch.sh

#!/bin/sh
(
logwatch
) | mail -s 'logwatch Daily Log (my server)' me@email.com

J'ai remplacé me@email.com ofcourse par mon email.

Si je lance ce cronjob manuellement, cela fonctionne bien ./nameoffile.sh

Mais cela ne fonctionne pas tous les jours, quelle peut être la cause ou comment puis-je vérifier cela?

— détonation supersonique
source

2

Assurez-vous que les fichiers que vous avez créés dans cron.daily / hebdomadaire / horaire / etc sont exécutables, faites juste un chmod + x /etc/cron.daily/wwhat

— Turgut Kalfaoglu

6

Il existe deux suspects possibles qui empêchent généralement l' cronexécution des travaux.

Le premier est les problèmes d'autorisations, c'est-à-dire qu'un utilisateur peut exécuter le script / la commande mais le démon cron ne peut pas car le travail se trouve dans les mauvais travaux cron de l'utilisateur. Par exemple, l'utilisateur crée un script ou exécute une commande avec des privilèges élevés, c'est-à-dire en utilisant sudo, puis ajoute le script / la commande testé à sa liste de tâches cron ( crontab). Le résultat est que le travail cron de l'utilisateur ne pourra pas s'exécuter car il a besoin de privilèges élevés.

Pour placer un travail cron dans le type crontab de l'utilisateur actuel crontab -e
Pour placer un travail cron dans le type crontab de root sudo crontab -e

La deuxième raison est les chemins, pour être sûr que le script s'exécutera, l'utilisateur doit ajouter le chemin complet au script à exécuter dans crontab. Une autre solution serait d'étendre la variable PATH des utilisateurs root en plaçant la ligne suivante en haut de leur fichier crontab:

PATH=/usr/sbin:/usr/bin:/sbin:/bin

comme le wiki communautaire le mentionne .

Vous voudrez peut-être lire le wiki de la communauté sur cron car il fournit plus de détails sur ce qui précède.

— Stef K
source

Alors, je mets juste le nom de fichier là-dedans?

— sonicboom

Cela signifie en fait qu'il n'y a pas de tâche cron précédente pour root et que vous allez écrire votre premier, puis il vous demande de choisir un éditeur afin de modifier la crontab. Choisissez-en un dans le menu (1.bin / ed, etc.). Choisissez nano c'est facile, faites juste attention aux instructions.

— Stef K

Donc, pour exécuter une fois par jour à 22 heures, je mettrais * 22 * * * test> rkhunter.sh non?

— sonicboom

ah génial! mal l'essayer maintenant!

— sonicboom

À quoi sert le test> rkhunter.sh?

— sonicboom

76

Selon cette réponse, 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 ses pages de manuelman run-parts

— user19366
source

1

C'est la réponse que je cherchais, après divers tests, j'ai réalisé qu'un autre fichier script sans extension sh était exécuté

— Albert Català

5

comme @rharriso l'a dit dans sa réponse. ce n'est pas tant un problème avec ".sh" qu'un problème avec ".". tout fichier avec n'importe quelle extension sera manqué. pour citer directement à partir de man run-parts"les noms doivent être entièrement composés de lettres majuscules et minuscules ASCII, de chiffres ASCII, de traits de soulignement ASCII et de traits d'union ASCII"

— northern-bradley

11

Dans mon système, c'était parce que 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 )

Installez donc anacron ou supprimez le test -x / usr / sbin / anacron

— Natim
source

1

+1 Anacron n'est-il pas installé par défaut? Je m'y serais attendu. Je pense que cela le résoudrait pour moi. Merci.

— lepe

Effectivement, il n'était pas là sur le mien .. FFS, je suis sûr qu'il l'était, car le script était en cours d'exécution il y a quelques mois !: dpkg --get-selections | grep cron.. <swears>

— Grizly

Oui, je ne sais pas non plus ce qui s'est passé car il s'agit d'un package généralement installé au démarrage.

— Natim

10

Ce n'est pas vraiment correct. anacronn'est pas nécessaire; l' ||opérateur des commandes crontab s'exécute run-partsquand anacron n'est PAS installé. Une fois anacroninstallé, il rend ces commandes quotidiennes / hebdomadaires / mensuelles run-partsredondantes.

— TalkLittle

Alors peut-être que c'était parce que les run-parts ne fonctionnaient pas? En tout cas, l'installation d'Anacron l'a corrigé pour moi.

— Natim

10

Je pense que les fichiers avec des extensions sont ignorés.

courir:

 run-parts --test /etc/cron.daily

Si vous ne voyez pas vos scripts répertoriés, supprimez les extensions .sh et réessayez.

— rharriso
source

5

Ajout à 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 exécuter en utilisant chmod +x filename.

— Braiam
source

De quels fichiers s'agit-il? s'agit-il du contenu du dossier /etc/logrotate.d?

— realtebo il y a

4

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 qu'il n'est pas répertorié. Alors lancez:

mv script.sh script

et réessayez. Il devrait être répertorié.

— Elan Kivity
source

Ce problème semble affecter tout exécutable ayant une extension. J'avais un nom de fichier "filename.ca" et il ne le répertorierait pas tant que je ne l'aurais pas renommé aussi "filename"

— kiwicomb123

0

Je ne pouvais pas le faire fonctionner avec anacron, j'ai retiré anacron /etc/crontabet exécuté apt remove --purge anacronet cela fonctionne tout de suite.

Je ne comprends pas pourquoi nous avons besoin de deux planificateurs.

— Patrik Laszlo
source

0

Même situation aujourd'hui ici

J'ai fait

sudo journalctl -u cron -b | grep -i error

et trouvé

cron[815]: Error: bad hour; while reading /etc/crontab
cron[815]: (*system*) ERROR (Syntax error, this crontab file will be ignored)

J'ai découvert que quelqu'un (moi !!!!) a ajouté une ligne commençant par

20 38 ...

et évidemment la 38ème heure n'existe pas!

— realtebo
source