comment puis-je faire en sorte que cron exécute un travail maintenant, pour tester / déboguer? sans changer l'horaire!

135

J'ai un travail cron qui est programmé pour s'exécuter tous les jours, mis à part le changement d'horaire, existe-t-il un autre moyen d'effectuer un test de la commande maintenant pour voir si cela fonctionne comme prévu?

cron debugging Ali
la source
Je ne comprends pas votre question? Pourquoi ne pas simplement exécuter la commande?
Favadi
21
Je sais que la commande marche quand elle est entrée dans le shell (mon shell), mais je veux savoir si ça marche quand cronelle est exécutée, cela pourrait être affecté par ENV ou des choses spécifiques au shell ( ~extension) ou des droits de propriété et de permission ou ...
Ali
2
Alors, pourquoi ne pas créer un nouveau travail cron exécuté chaque minute avec la même commande?
Favadi
13
C'est exactement ce que j'ai fini par faire, mais je me suis demandé s'il y avait un moyen de dire à cron que vous voulez un test sur le travail n ° 7! Bien sûr, d'autres ont déjà eu ce problème / demande / souhait avant!
Ali
4
Très tard sur les lieux ici à travers Google mais il y avait tout faux dans la réponse de favadi. Il était clair qu'il souhaitait le tester à partir de cron et sans modifier la crontab spécifiquement pour cela. Un peu pire que si quelqu'un vous disait ce que vous voulez, c'est faux quand ils n'ont pas essayé de comprendre le cas d'utilisation.
HörmannHH

Réponses:

32

Autant que je sache, il n’ya aucun moyen de le faire directement, car cron a un objectif particulier: exécuter des commandes de planification à un moment donné. La meilleure chose à faire est donc de créer manuellement une entrée de crontab ou d'écrire un script qui supprime et réinitialise l'environnement.

Ulrich Dangel
la source
57

Vous pouvez forcer la crontab à s'exécuter avec la commande suivante:

run-parts /etc/cron.daily
Vadim Sluzky
la source
9
... en supposant que le travail cron de l'OP (demandé il y a 3 ans) est dans cron.daily par opposition à une crontab individuelle.
Jeff Schaller
18
Cependant, cela ne simule pas complètement l'environnement de l'utilisateur cron. Il est donc fort probable que vous ayez encore des bogues, car une fois que vous exécutez votre script en tant que tâche cron, votre variable PATH et d'autres envvars peuvent être différents de l'utilisateur que vous utilisiez run-parts /etc/cron.daily. Je lutte contre ce bogue en ce moment, car mon script s'exécutera correctement run-partsmais échouera lorsqu'il sera exécuté sous l'utilisateur cron.
ArtHare
42

Vous pouvez simuler l'environnement utilisateur cron comme expliqué dans "Exécution manuelle et immédiate d'un travail cron" . Cela vous permettra de tester que le travail fonctionne lorsqu'il sera exécuté en tant qu'utilisateur cron.

Extrait du lien:

Étape 1 : Je mets cette ligne temporairement dans la crontab de l'utilisateur:

* * * * *   /usr/bin/env > /home/username/tmp/cron-env

puis l'a sorti une fois que le fichier a été écrit.

Étape 2 : Je me suis fait un petit script bash en run-as-cron contenant:

#!/bin/bash
/usr/bin/env -i $(cat /home/username/tmp/cron-env) "$@"

Alors, en tant qu'utilisateur en question, j'ai pu

run-as-cron /the/problematic/script --with arguments --and parameters
Michael Barton
la source
Astuce utile. Bien sûr, cela ne vous aidera pas si vous avez un signe de pourcentage dans votre commande.
basic6
0

J'ai trouvé une solution qui semble être un peu meilleure pour mes besoins (commandes affichées pour CentOS / RHEL-like, mais qui devraient être adaptables pratiquement n'importe où).

Cela nécessite libfaketime- vous pouvez le construire vous-même à partir des sources à l' adresse https://github.com/wolfcw/libfaketime ou simplement utiliser l'un des nombreux packages de https://pkgs.org/download/libfaketime .

  1. Arrêtez le service crond - service crond stop
  2. Déterminez quand votre service doit être exécuté par - https://crontab.guru est très utile pour cela.
  3. Exécutez crond en mode de premier plan via l' faketimeoutil libfaketime (il vous permet de simuler l'appel système pour les recherches de temps pour tous les processus enfants).
    1. Je n'exécuterais pas ceci sur un serveur de production
    2. faketime '2019-10-17 07:59:50' /usr/sbin/crond -n -x test,sch
[root@user-crontesting-dvc-01 ~]# faketime '2019-10-17 07:59:50' /usr/sbin/crond -n -x sch
debug flags enabled: sch
[4841] cron started
log_it: (CRON 4841) INFO (Syslog will be used instead of sendmail.)
log_it: (CRON 4841) INFO (RANDOM_DELAY will be scaled with factor 34% if used.)
log_it: (CRON 4841) INFO (running with inotify support)
[4841] GMToff=0
log_it: (CRON 4841) INFO (@reboot jobs will be run at computer's startup.)
[4841] Target time=1571299200, sec-to-wait=11
user [root:0:0:...] cmd="/usr/libexec/myexc/crontesting.cron > /dev/null 2> &1"
[4841] Target time=1571299260, sec-to-wait=60
log_it: (root 4844) CMD (/usr/libexec/myexc/crontesting.cron > /dev/null 2> &1)
log_it: (root 4843) CMDOUT (/bin/bash: -c: line 0: syntax error near unexpected token `&')
log_it: (root 4843) CMDOUT (/bin/bash: -c: line 0: `/usr/libexec/myexc/crontesting.cron > /dev/null 2> &1')
Javanix
la source