web-dev-qa-db-fra.com

Crontab ne fonctionnant jamais dans /etc/cron.d

Voici ce que j'ai fait sur Debian Jessie:

  • installez cron via apt-get install cron
  • mettre un 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?

34
Jivan

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)

53
Stephen Harris

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

11
rodrigo-silveira

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.

6
slac1024

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.

2
clk

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.

2
touchwood
  1. 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

  2. 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

1
Philippe Gachoud

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.

1
James Nelson