Comment tester un cron hebdomadaire?

Faites simplement ce que fait cron, lancez ce qui suit en tant que root :

 run-parts -v /etc/cron.weekly 

ou

 run-parts /etc/cron.weekly -v 

Si vous recevez l’erreur “Not a directory: -v”.

-v imprime les noms de script avant leur exécution.

Un peu au-delà de la scope de votre question … mais voici ce que je fais.

Le “comment puis-je tester un travail cron?” La question est étroitement liée à “comment tester des scripts exécutés dans des contextes non interactifs lancés par d’autres programmes?” Dans cron, le déclencheur est une condition temporelle, mais de nombreuses autres fonctionnalités * nix lancent des scripts ou des fragments de script de manière non interactive, et souvent les conditions dans lesquelles ces scripts s’exécutent contiennent des éléments inattendus.

Une approche générale de ce problème est utile.

Une de mes techniques préférées est d’utiliser un script que j’ai écrit appelé « crontest ». Il lance la commande target dans une session d’écran GNU à partir de cron, afin que vous puissiez attacher un terminal distinct pour voir ce qui se passe, interagir avec le script, et même utiliser un débogueur.

Pour configurer cela, vous utiliseriez “all stars” dans votre entrée crontab et spécifiez crontest comme première commande sur la ligne de commande, par exemple:

 * * * * * crontest /command/to/be/tested --param1 --param2 

Donc, maintenant, cron exécutera votre commande toutes les minutes, mais crontest s’assurera qu’une seule instance s’exécute à la fois. Si la commande prend du temps pour s’exécuter, vous pouvez faire un “screen -x” pour l’attacher et le regarder s’exécuter. Si la commande est un script, vous pouvez placer une commande “read” en haut pour la faire arrêter et attendre que la pièce jointe à l’écran se termine (appuyez sur Entrée après avoir attaché)

Si votre commande est un script bash, vous pouvez le faire à la place:

 * * * * * crontest --bashdb /command/to/be/tested --param1 --param2 

Maintenant, si vous attachez avec “screen -x”, vous serez confronté à une session bashdb interactive, et vous pourrez parcourir le code, examiner les variables, etc.

 #!/bin/bash # crontest # See https://github.com/Stabledog/crontest for canonical source. # Test wrapper for cron tasks. The suggested use is: # # 1. When adding your cron job, use all 5 stars to make it run every minute # 2. Wrap the command in crontest # # # Example: # # $ crontab -e # * * * * * /usr/local/bin/crontest $HOME/bin/my-new-script --myparams # # Now, cron will run your job every minute, but crontest will only allow one # instance to run at a time. # # crontest always wraps the command in "screen -d -m" if possible, so you can # use "screen -x" to attach and interact with the job. # # If --bashdb is used, the command line will be passed to bashdb. Thus you # can attach with "screen -x" and debug the remaining command in context. # # NOTES: # - crontest can be used in other contexts, it doesn't have to be a cron job. # Any place where commands are invoked without an interactive terminal and # may need to be debugged. # # - crontest writes its own stuff to /tmp/crontest.log # # - If GNU screen isn't available, neither is --bashdb # crontestLog=/tmp/crontest.log lockfile=$(if [[ -d /var/lock ]]; then echo /var/lock/crontest.lock; else echo /tmp/crontest.lock; fi ) useBashdb=false useScreen=$( if which screen &>/dev/null; then echo true; else echo false; fi ) innerArgs="$@" screenBin=$(which screen 2>/dev/null) function errExit { echo "[-err-] $@" | tee -a $crontestLog >&2 } function log { echo "[-stat-] $@" >> $crontestLog } function parseArgs { while [[ ! -z $1 ]]; do case $1 in --bashdb) if ! $useScreen; then errExit "--bashdb invalid in crontest because GNU screen not installed" fi if ! which bashdb &>/dev/null; then errExit "--bashdb invalid in crontest: no bashdb on the PATH" fi useBashdb=true ;; --) shift innerArgs="$@" return 0 ;; *) innerArgs="$@" return 0 ;; esac shift done } if [[ -z $sourceMe ]]; then # Lock the lockfile (no, we do not wish to follow the standard # advice of wrapping this in a subshell!) exec 9>$lockfile flock -n 9 || exit 1 # Zap any old log data: [[ -f $crontestLog ]] && rm -f $crontestLog parseArgs "$@" log "crontest starting at $(date)" log "Raw command line: $@" log "Inner args: $@" log "screenBin: $screenBin" log "useBashdb: $( if $useBashdb; then echo YES; else echo no; fi )" log "useScreen: $( if $useScreen; then echo YES; else echo no; fi )" # Were building a command line. cmdline="" # If screen is available, put the task inside a pseudo-terminal # owned by screen. That allows the developer to do a "screen -x" to # interact with the running command: if $useScreen; then cmdline="$screenBin -D -m " fi # If bashdb is installed and --bashdb is specified on the command line, # pass the command to bashdb. This allows the developer to do a "screen -x" to # interactively debug a bash shell script: if $useBashdb; then cmdline="$cmdline $(which bashdb) " fi # Finally, append the target command and params: cmdline="$cmdline $innerArgs" log "cmdline: $cmdline" # And run the whole schlock: $cmdline res=$? log "Command result: $res" echo "[-result-] $(if [[ $res -eq 0 ]]; then echo ok; else echo fail; fi)" >> $crontestLog # Release the lock: 9<&- fi 

Après avoir joué avec certaines choses dans cron qui n’étaient pas immédiatement compatibles, j’ai trouvé que l’approche suivante était intéressante pour le débogage:

 crontab -e * * * * * /path/to/prog var1 var2 &>>/tmp/cron_debug_log.log 

Cela exécutera la tâche une fois par minute et vous pouvez simplement chercher dans le fichier /tmp/cron_debug_log.log pour déterminer ce qui se passe.

Ce n’est pas exactement le “job de feu” que vous recherchez, mais cela m’a beaucoup aidé lors du débogage d’un script qui ne fonctionnait pas dans cron au début.

J’utiliserais un fichier de locking, puis définirais le travail cron pour qu’il s’exécute chaque minute. (utilisez crontab -e et * * * * * / path / to / job) De cette façon, vous pouvez simplement continuer à éditer les fichiers et chaque minute ils seront testés. De plus, vous pouvez arrêter le travail cron en touchant simplement le fichier de locking.

  #!/bin/sh if [ -e /tmp/cronlock ] then echo "cronjob locked" exit 1 fi touch /tmp/cronlock <...do your regular cron here ....> rm -f /tmp/cronlock 

Qu’en est-il de le mettre dans cron.hourly , en attendant la prochaine exécution des tâches cron toutes les heures, puis en le supprimant? Cela l’exécuterait une fois dans l’heure, et dans l’environnement cron. Vous pouvez également exécuter ./your_script , mais cela n’aura pas le même environnement que sous cron.

En dehors de cela, vous pouvez également utiliser:

http://pypi.python.org/pypi/cronwrap

pour boucler votre cron afin de vous envoyer un email en cas de succès ou d’échec.

Aucune de ces réponses ne correspond à ma situation spécifique, à savoir que je voulais exécuter une tâche cron spécifique, une seule fois, et l’exécuter immédiatement.

Je suis sur un serveur Ubuntu et j’utilise cPanel pour configurer mes tâches cron.

J’ai simplement noté mes parameters actuels, puis je les ai modifiés pour qu’ils soient dans une minute. Quand j’ai corrigé un autre bug, je l’ai juste édité à nouveau dans une minute. Et quand tout a été terminé, je réinitialise les parameters à leur état antérieur.

Exemple: Il est 16h34 en ce moment, donc j’ai mis 35 16 * * *, pour que ça tourne à 16h35.

Cela fonctionnait comme un charme, et le plus que je devais attendre était un peu moins d’une minute.

Je pensais que c’était une meilleure option que certaines des autres réponses parce que je ne voulais pas exécuter tous mes entretiens hebdomadaires, et je ne voulais pas que le travail soit exécuté toutes les minutes. Il me faut quelques minutes pour régler les problèmes avant que je sois prêt à le tester à nouveau. Espérons que cela aide quelqu’un.

Je teste normalement en exécutant le travail que j’ai créé comme ceci:

Il est plus facile d’utiliser deux terminaux pour cela.

exécuter le travail:

 #./jobname.sh 

aller à:

 #/var/log and run 

exécuter ce qui suit:

 #tailf /var/log/cron 

Cela me permet de voir la mise à jour des journaux cron en temps réel. Vous pouvez également consulter le journal après l’avoir exécuté, je préfère regarder en temps réel.

Voici un exemple de travail cron simple. Lancer une mise à jour …

 #!/bin/bash YUM=/usr/bin/yum $YUM -y -R 120 -d 0 -e 0 update yum $YUM -y -R 10 -e 0 -d 0 update 

Voici la ventilation:

La première commande mettra à jour miam elle-même et ensuite appliquera les mises à jour du système.

-R 120: définit la durée maximale pendant laquelle yum attendra avant d’exécuter une commande

-e 0: définit le niveau d’erreur sur 0 (plage 0 – 10). 0 signifie imprimer uniquement les erreurs critiques à propos desquelles vous devez être informé.

-d 0: définit le niveau de débogage sur 0 – augmente ou diminue le nombre d’éléments imprimés. (plage: 0 – 10).

-y: suppose que oui; supposons que la réponse à toute question qui serait posée est oui

Après avoir créé la tâche cron, j’ai exécuté la commande ci-dessous pour rendre mon travail exécutable.

 #chmod +x /etc/cron.daily/jobname.sh 

J’espère que ça aide, Dorlack

La solution que j’utilise est la suivante:

1. Modifiez crontab (utilisez la commande: crontab -e) pour exécuter le travail aussi souvent que nécessaire (toutes les 1 ou 5 minutes)
2. Modifiez le script shell qui doit être exécuté en utilisant cron pour imprimer la sortie dans un fichier (ex: echo “fonctionne bien” >>
   output.txt)
3. Vérifiez le fichier output.txt en utilisant la commande: tail -f output.txt, qui imprimera les derniers ajouts dans ce fichier, et vous pourrez ainsi suivre l’exécution du script

 sudo run-parts --test /var/spool/cron/crontabs/ 

fichiers dans lesquels crontabs/ répertoire doit être exécutable par le propriétaire – octal 700

source: man cron et NNRooth

J’utilise Webmin parce que c’est un bijou de productivité pour quelqu’un qui trouve l’administration de la ligne de commande un peu intimidante et impénétrable.

Il y a un bouton “Enregistrer et exécuter maintenant” dans l’interface Web “Système> Travaux périodiques planifiés> Modifier le travail périodique”.

Il affiche la sortie de la commande et est exactement ce dont j’avais besoin.