Tester un travail hebdomadaire cron [fermé]

J'ai un #!/bin/bashfichier dans le répertoire cron.week.

Existe-t-il un moyen de tester si cela fonctionne? Je ne peux pas attendre 1 semaine

Je suis sur Debian 6 avec root

Faites ce que fait cron, exécutez ce qui suit root:

run-parts -v /etc/cron.weekly

... ou le suivant si vous recevez l'erreur "Pas un répertoire: -v":

run-parts /etc/cron.weekly -v

L'option -vimprime les noms de script avant leur exécution.

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

Le "comment puis-je tester un travail cron?" La question est étroitement liée à "comment puis-je tester des scripts qui s'exécutent dans des contextes non interactifs lancés par d'autres programmes?" Dans cron, le déclencheur est une condition temporelle, mais beaucoup d'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 quelque chose d'inattendu et provoquent des ruptures jusqu'à ce que les bogues soient triés. (Voir aussi: https://stackoverflow.com/a/17805088/237059 )

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

L'une de mes techniques préférées consiste à utiliser un script que j'ai écrit appelé « crontest ». Il lance la commande cible dans une session d'écran GNU depuis cron, de sorte que vous pouvez vous attacher avec un terminal séparé pour voir ce qui se passe, interagir avec le script, même utiliser un débogueur.

Pour configurer cela, vous devez utiliser "toutes les étoiles" dans votre entrée crontab et spécifier crontest comme première commande sur la ligne de commande, par exemple:

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

Alors maintenant, cron exécutera votre commande toutes les minutes, mais crontest s'assurera qu'une seule instance s'exécute à la fois. Si l'exécution de la commande prend du temps, vous pouvez effectuer un "screen -x" pour l'attacher et la regarder s'exécuter. Si la commande est un script, vous pouvez placer une commande "lecture" en haut pour la faire s'arrêter et attendre la fin de la pièce jointe à l'écran (appuyez sur Entrée après la pièce jointe)

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 dérangé avec des choses dans cron qui n'étaient pas instantanément compatibles, j'ai trouvé que l'approche suivante était agréable 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 regarder dans le /tmp/cron_debug_log.logfichier pour comprendre ce qui se passe.

Ce n'est pas exactement le "job de pompier" que vous recherchez peut-être, 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 verrouillage, puis définirais le travail cron pour qu'il s'exécute toutes les minutes. (utilisez crontab -e et * * * * * / path / to / job) De cette façon, vous pouvez continuer à éditer les fichiers et chaque minute ils seront testés. De plus, vous pouvez arrêter le cronjob en touchant simplement le fichier de verrouillage.

    #!/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 cron.hourly, d'attendre la prochaine exécution de tâches cron horaires, puis de le supprimer? 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.

Aucune de ces réponses ne correspondait à 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 paramètres actuels, puis les ai modifiés dans une minute. Lorsque j'ai corrigé un autre bug, je l'ai juste modifié à nouveau dans une minute. Et quand j'ai fini, je viens de réinitialiser les paramètres à leur niveau antérieur.

Exemple: Il est 16h34 en ce moment, alors j'ai mis 35 16 * * *, pour qu'il fonctionne à 16h35.

Cela a fonctionné comme un charme, et le plus que j'ai jamais dû 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 crons hebdomadaires, et je ne voulais pas que le travail s'exécute toutes les minutes. Il me faut quelques minutes pour résoudre les problèmes avant de pouvoir le tester à nouveau. J'espère que cela aide quelqu'un.

En plus de cela, vous pouvez également utiliser:

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

pour envelopper votre cron pour vous envoyer un e-mail en cas de succès ou d'échec.

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 minute ou 5 minutes)
2. Modifiez le script shell qui doit être exécuté à l'aide de cron pour imprimer la sortie dans un fichier (par exemple: echo "Working fine" >>
   output.txt)
3. Vérifiez le fichier output.txt à l'aide de la commande: tail -f output.txt, qui imprimera les derniers ajouts dans ce fichier, et vous pourrez ainsi suivre l'exécution du script

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

Pour ce faire, il est plus facile d'utiliser deux terminaux.

exécuter le travail:

#./jobname.sh

aller à:

#/var/log and run 

exécutez 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 le regarder en temps réel.

Voici un exemple de tâche cron simple. Exécution d'une mise à jour yum ...

#!/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 répartition:

La première commande mettra à jour yum lui-même et la prochaine appliquera les mises à jour 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 de 0 à 10). 0 signifie imprimer uniquement les erreurs critiques dont vous devez être informé.

-d 0: définit le niveau de débogage sur 0 - augmente ou diminue la quantité de choses imprimées. (plage: 0 - 10).

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

Après avoir créé le travail 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 cela aide, Dorlack

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

les fichiers de ce crontabs/répertoire doivent être exécutables par le propriétaire - octal700

source: man cronet NNRooths »

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

Il existe un bouton «Enregistrer et exécuter maintenant» dans l'interface Web «Système> Cron Jobs planifiés> Modifier le Cron Job».

Il affiche la sortie de la commande et correspond exactement à ce dont j'avais besoin.