Probar un trabajo cron semanal

Usaría un archivo de bloqueo y luego configuraría el trabajo cron para que se ejecute cada minuto. (utilice crontab -e y * * * * * /ruta/al/trabajo) De esa manera puede seguir editando los archivos y cada minuto se probarán. Además, puede detener el cronjob con solo tocar el archivo de bloqueo.

    #!/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

Después de jugar con algunas cosas en cron que no eran compatibles instantáneamente, descubrí que el siguiente enfoque era bueno para la depuración:

crontab -e

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

Esto ejecutará la tarea una vez por minuto y simplemente puede buscar en el /tmp/cron_debug_log.log archivo para averiguar qué está pasando.

No es exactamente el "trabajo de fuego" que podría estar buscando, pero esto me ayudó mucho al depurar un script que no funcionó en cron al principio.

Un poco más allá del alcance de su pregunta... pero esto es lo que hago.

El "¿cómo pruebo un trabajo cron?" La pregunta está estrechamente relacionada con "¿cómo pruebo scripts que se ejecutan en contextos no interactivos iniciados por otros programas?" En cron, el desencadenante es una condición de tiempo, pero muchas otras instalaciones * nix lanzan scripts o fragmentos de scripts de formas no interactivas y, a menudo, las condiciones en las que se ejecutan esos scripts contienen algo inesperado y causan interrupciones hasta que se solucionan los errores. (Véase también:https://stackoverflow.com/a/17805088/237059 )

Es útil tener un enfoque general para este problema.

Una de mis técnicas favoritas es usar un script que escribí llamado 'crontest'. Ejecuta el comando de destino dentro de una sesión de pantalla GNU desde cron, de modo que puede conectarse con un terminal separado para ver qué está pasando, interactuar con el script e incluso usar un depurador.

Para configurar esto, usaría "todas las estrellas" en su entrada crontab y especificaría crontest como el primer comando en la línea de comando, por ejemplo:

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

Así que ahora cron ejecutará su comando cada minuto, pero crontest se asegurará de que solo se ejecute una instancia a la vez. Si el comando tarda en ejecutarse, puede hacer una "pantalla -x" para adjuntar y ver cómo se ejecuta. Si el comando es una secuencia de comandos, puede colocar un comando de "lectura" en la parte superior para detenerlo y esperar a que se complete el archivo adjunto de pantalla (presione Intro después de adjuntar)

Si su comando es un script bash, puede hacer esto en su lugar:

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

Ahora, si adjunta con "pantalla -x", se enfrentará a una sesión de bashdb interactiva y podrá recorrer el código, examinar 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="[email protected]"
screenBin=$(which screen 2>/dev/null)

function errExit {
    echo "[-err-] [email protected]" | tee -a $crontestLog >&2
}

function log {
    echo "[-stat-] [email protected]" >> $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="[email protected]"
                return 0
                ;;
            *)
                innerArgs="[email protected]"
                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 "[email protected]"

    log "crontest starting at $(date)"
    log "Raw command line: [email protected]"
    log "Inner args: [email protected]"
    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

Simplemente haga lo que hace cron, ejecute lo siguiente como root :

run-parts -v /etc/cron.weekly

... o el siguiente si recibe el error "No es un directorio:-v":

run-parts /etc/cron.weekly -v

Opción -v imprime los nombres de los scripts antes de que se ejecuten.