Comment tester la tâche cron ?

Question

J’ai placé un `` fichier dans le répertoire cron.week.

Il existe un moyen de tester si cela fonctionne ? Impossible d’attendre 1 semaine

Je suis sur debian 6 avec racine

Answer 1

Juste faire ce que cron fait :

ou

Si vous recevez le « pas un répertoire : - v » erreur.

``imprime les noms de script avant elles sont exécutées.

Answer 2

Un tout petit peu au-delà de la portée de votre question... mais voici ce que je fais.

"Comment puis-je tester une tâche cron?" la question est étroitement liée à "comment puis-je tester les scripts qui s'exécutent en mode non interactif contextes lancé par d'autres programmes?" Dans cron, le déclencheur est un peu de temps condition, mais beaucoup d'autres *nix installations de lancement des scripts ou des fragments de script non interactif moyens, et souvent les conditions dans lesquelles ces scripts s'exécutent contenir quelque chose d'inattendu et de provoquer des ruptures jusqu'à ce que les bugs sont triés.

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

L'un de mes préférés des techniques consiste à utiliser un script que j'ai écrit appelé"crontest'. Il se lance sur la cible de commande à l'intérieur d'un GNU écran de session à partir de l'intérieur de cron, de sorte que vous pouvez attacher avec un terminal pour voir ce qui se passe, d'interagir avec le script, même l'utilisation d'un débogueur.

Pour cela, vous devez utiliser "all stars" dans votre entrée crontab, et spécifier crontest que la première commande sur la ligne de commande, par exemple:

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

Alors maintenant, cron exécute votre commande à chaque minute, mais crontest veillera à ce qu'une seule instance s'exécute à un moment. Si la commande prend du temps pour s'exécuter, vous pouvez faire un "- x" pour attacher et de le regarder courir. Si la commande est un script, vous pouvez mettre un "lire" commande en haut pour le faire arrêter et attendre que l'écran d'attachement à compléter (appuyez sur entrée après la fixation)

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

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

Maintenant, si vous vous attachez à l'écran "- x", vous serez confronté à un interactive bashdb session, et vous pouvez parcourir le code, d'examiner les variables, etc.

#!/bin/bash

# crontest
#
# 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

Answer 3

Après embêter avec des trucs en cron qui n’était pas instantanément compatible, j’ai trouvé que l’approche suivante était agréable pour le débogage :

Cela exécutera la tâche une fois par minute, et vous pouvez simplement regarder dans le `` fichier de comprendre ce qui se passe.

Ce n’est pas exactement le « travail de feu », pour que vous cherchez peut-être, mais cela m’a beaucoup aidé lors du débogage d’un script qui n’a pas fonctionné dans cron dans un premier temps.

Answer 4

J’utilise un fichier de verrouillage et puis définissez la tâche cron pour exécuter chaque minute. (utiliser crontab -e et ***** /path/to/job) De cette façon vous pouvez juste garder modifier les fichiers et chaque minute qu’ils vont être testés. En outre, vous pouvez arrêter la tâche cron en touchant simplement le fichier de verrouillage.

Answer 5

Qu’en est-il de le mettre en , attendre la prochaine exécution de tâches cron toutes les heures, puis retirer ? Qu’il irait une fois moins d’une heure et dans l’environnement de cron. Vous pouvez également exécuter , mais cela n’aura pas le même environnement que dans le cadre de cron.