Pourquoi mon crontab ne s'est-il pas déclenché?

J'avais l'habitude crontab -ed'ajouter la ligne suivante à mon crontab:

* * * * * echo hi >> /home/myusername/test

Pourtant, je ne vois pas que le fichier de test est écrit. Est-ce un problème d'autorisation ou crontab ne fonctionne-t-il pas correctement?

Je vois que le processus cron est en cours d'exécution. Comment puis-je déboguer cela?

Edit - Ask Ubuntu a une belle question sur crontab , malheureusement cela ne m'aide toujours pas.

Edit 2 - Hmm, il semble que mon fichier de test ait 214 lignes, ce qui signifie que pour les 214 dernières minutes, il a été écrit à chaque minute. Je ne sais pas quel était le problème, mais il est évident qu'il a disparu.

Il y a des implémentations de cron(pas toutes, et je ne me souviens pas laquelle, mais j'en ai rencontré une sous Linux) qui vérifient les fichiers crontab mis à jour chaque minute à la minute, et ne considèrent pas les nouvelles entrées jusqu'à la minute suivante . Par conséquent, un crontab peut prendre jusqu'à deux minutes pour se déclencher pour la première fois. C'est peut-être ce que vous avez observé.

Avez-vous ajouté une ligne vide après votre cronjob ?

J'ai eu le même problème - un crontab de travail s'est soudainement arrêté après avoir ajouté une nouvelle entrée à la fin. Il s'est avéré que j'avais oublié de mettre une nouvelle ligne après cette dernière ligne.

J'ai découvert en lançant la commande

cat /var/log/syslog | grep crontab

et la sortie a montré le problème:

Jul  2 08:16:01 shiva cron[1254]: (*system*) RELOAD (/etc/crontab)
Jul  2 08:16:01 shiva cron[1254]: (*system*) ERROR (Missing newline before EOF, this crontab file will be ignored)

L'ajout de la nouvelle ligne et l'enregistrement ont résolu le problème.

Cela semble fixe. La prochaine fois, essayez également de connecter le STDERR. Les éléments suivants ne se connecteront qu'à STDOUT, pas à STDERR:

* * * * * echo hi >> /home/myusername/test

Essayez de vous assurer qu'il existe également une clause explicite pour STDERR. Sinon, STDERR peut être envoyé par e-mail à l'utilisateur (en supposant que l'e-mail fonctionne) ou ne peut aller nulle part, selon la configuration de Cron.

* * * * * echo hi >> /home/myusername/test 2> /home/myusername/test.stderr

Ma préférence est d'envoyer la sortie cronjob à syslog. De cette façon, je profite de toute infrastructure syslog existante (syslog centralisés, Splunk, rotation des journaux déjà prise en charge, il est facile de comparer les messages dans / var / log / messages & / var / log / cronjob, etc.), et je ne le suis pas spammer les administrateurs système (moi) avec des e-mails inutiles.

* * * * * echo hi >> /home/myusername/test 2>&1 | /usr/bin/logger -t mycronjob

Pour moi, le problème était que le script n'était pas exécutable. J'avais une configuration crontab -e comme celle-ci

* * * * * /bin/my-script.sh

Et le fichier myscript n'était pas exécutable donc j'ai couru

chmod +x my-script.sh

Immédiatement, j'ai commencé à voir la sortie comme prévu.

Votre ligne cron fonctionne bien sur mon ordinateur lorsque je passe myusernaeà phunehehe. Il existe plusieurs façons de découvrir ce qui ne va pas avec votre système.

Cron envoie généralement des messages à l'utilisateur en cas de problème. Si vous voyez le message "Vous avez du courrier", utilisez un client de messagerie pour vérifier votre boîte de réception . Ou, vérifiez dans votre répertoire personnel, il peut y avoir un fichier nommé dead.letterlà-bas.

Vous pouvez vérifier les /var/log/entrées relatives à cron. Sur mon ordinateur, le fichier journal est à /var/log/cron/current(nécessite un accès root).

Si vous avez un accès root, vous pouvez arrêter le démon cron et le démarrer en mode débogage. Par exemple, j'utiliserais (changer fcronle nom de votre démon):

killall fcron
fcron --foreground --debug

Très probablement, lorsque cron échoue, il génère un e-mail à l'ID utilisateur du travail cron sur cet ordinateur. Si aucun MTA ne fonctionne sur votre ordinateur ou si vous ne lisez pas ou ne transférez pas ce courrier ailleurs, vous ne verrez pas ce message, même si le MTA fonctionne.

Un bon moyen d'obtenir les erreurs de votre crontab par courrier est de faire ressembler votre crontab à ceci:

MAILTO="myemail@example.com"
* * * * * echo hi >> /home/myusernae/test

De toute évidence, utilisez votre adresse e-mail plutôt que myemail@example.com. Cela indique à cron d'envoyer des erreurs à votre adresse e-mail plutôt qu'au compte local. En particulier, cela est utile si vous avez une crontab racine (ou un fragment crontab dans /etc/cron.d) que vous souhaitez simplement vous envoyer une sortie, vous pouvez éviter de spammer la boîte aux lettres de la racine ou l'adresse de transfert de la racine.

Je suppose que l'une des raisons peut être que le répertoire / home / est crypté et que lorsque l'utilisateur est déconnecté, cron ne peut rien faire dans ce répertoire.

voir: https://stackoverflow.com/a/40354269/1279002