Voici ce que j'ai fait sur Debian Jessie:
apt-get install cron
backup_crontab
fichier dans /etc/cron.d/
Cependant, la tâche n'est jamais en cours d'exécution.
Voici quelques sorties:
/# crontab -l
no crontab for root
/# cd /etc/cron.d && ls
backup_crontab
/etc/cron.d# cat backup_crontab
0,15,30,45 * * * * /backup.sh >/dev/null 2>&1
Y a-t-il quelque chose à faire pour activer un crontab particulier, ou pour activer le "service" cron en lui-même?
Fichiers dans /etc/cron.d
doit également répertorier le tilisateur sous lequel le travail doit être exécuté.
c'est à dire.
0,15,30,45 * * * * root /backup.sh >/dev/null 2>&1
Vous devez également vous assurer que les autorisations et le propriétaire: groupe sont définis correctement (-rw-r--r--
et appartenant à root:root
)
Une autre chose que j'ai observée est que le fichier dans /etc/cron.d
ne peut pas avoir d'extension. Dans mon cas particulier, j'avais un lien symbolique:
# my-job.crontab
* * * * * root echo "my job is running!" >> /tmp/my-job.log
$: ln -sf /home/me/my-job.crontab /etc/cron.d/
# This did not work -> job would not run
$: ln -sf /home/me/my-job.crontab /etc/cron.d/my-job
# This did work -> job ran fine
La restriction du nom de fichier est documentée sur la page de manuel de la partie d'exécution: http://manpages.ubuntu.com/manpages/xenial/man8/run-parts.8.html , on peut passer un --regex option pour remplacer le format de fichier.
Le comportement cron par défaut est cependant resté sans extensions, voir les commentaires sous: https://bugs.launchpad.net/ubuntu/+source/debianutils/+bug/38022
Je pense que vous manquez probablement une ligne vierge nécessaire à la fin de votre fichier cron. J'ai eu le même problème, mais après avoir vérifié tout ce qui est répertorié ici (autorisations utilisateur, nom de fichier, version cron, etc.), j'ai réalisé que je n'avais pas de saut de ligne après la dernière entrée dans mon /etc/cron.d/own_cron
et cela fait ignorer le fichier entier.
Si vous êtes le seul utilisateur de cet ordinateur, vous pouvez utiliser uniquement crontab -e
. Vous serez invité à sélectionner un éditeur la première fois que vous exécuterez la commande. Ensuite, vous pouvez y ajouter ceci:
0,15,30,45 * * * * /backup.sh >/dev/null 2>&1
Si vous passez à un compte d'utilisateur normal, vous devrez utiliser Sudo crontab -e
pour configurer les scripts que vous souhaitez que leur exécution s'exécute en tant que root
.
crontab -l
affiche uniquement la crontab actuelle, une fois que vous en avez configuré une à l'aide de crontab -e
. Si vous avez un fichier cron dans /etc/cron.d
/, il ne sera pas affiché avec crontab -l
.
Vous devrez également vérifier que votre script est exécutable avec: chmod +x /backup.sh
.
Pour Cron de * bian distros (comme Raspbian), vous devez activer le -l
paramètre du démon Cron. Il est conseillé de le faire en utilisant /etc/default/cron
fichier de configuration, activant le EXTRA_OPTS
.
Tout d'abord, vérifiez le /var/log/syslog
fichier pour erreurs cron.d,
Sudo grep "cron.d" /var/log/syslog |grep -i error
pourrait être utile pour trouver erreurs comme de mauvais noms d'utilisateur ou une mauvaise syntaxe
Si vous n'en avez pas, vérifiez tous les cron.d
entrées dans le même fichier avec
Sudo grep "cron.d" /var/log/syslog
Vérifiez votre version de cron
.
Il semble que si vous utilisez le crond de Dillon, vous n'avez pas besoin de l'utilisateur dans un /etc/cron.d
entrée.
J'ai compris cela après avoir presque retiré mes cheveux restants.
J'ai quelques entrées qui ont été supprimées dans /etc/cron.d
par diverses installations. Après une enquête, j'ai découvert que l'un d'entre eux fonctionnait. Il n'avait pas l'utilisateur. J'ai donc sorti l'utilisateur des autres. Et ils ont commencé à travailler.