linux - tareas - ¿Cómo probar un trabajo cron semanal?

instalar crontab ubuntu

Question

Tengo un archivo #!/bin/bash en el directorio cron.week.

¿Hay alguna manera de probar si funciona? No puedo esperar 1 semana

Estoy en Debian 6 con root

Answer 1

¿Qué hay de ponerlo en cron.hourly , esperar hasta la próxima ejecución de trabajos cron por hora, y luego eliminarlo? Eso lo ejecutaría una vez en una hora, y en el entorno cron. También puede ejecutar ./your_script , pero eso no tendrá el mismo entorno que bajo cron.

Answer 2

Aparte de eso también puedes usar:

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

para envolver su cron para enviarle un correo electrónico en caso de éxito o fracaso.

Answer 3

Después de jugar con algunas cosas en cron que no eran compatibles al instante, 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 archivo /tmp/cron_debug_log.log para averiguar qué está sucediendo.

No es exactamente el "trabajo de fuego" lo que estás buscando, pero esto me ayudó mucho al depurar un script que no funcionaba en cron al principio.

Answer 4

Estoy usando Webmin porque es una gema de productividad para alguien que encuentra la administración de línea de comandos un poco desalentadora e impenetrable.

Hay un botón "Guardar y ejecutar ahora" en la interfaz web "Sistema> Tareas programadas> Editar tarea".

Muestra la salida del comando y es exactamente lo que necesitaba.

Answer 5

La solución que estoy usando es la siguiente:

1. Edite crontab (use el comando: crontab -e) para ejecutar el trabajo con la frecuencia que sea necesaria (cada 1 minuto o 5 minutos)
2. Modifique el script de shell que se debe ejecutar usando cron para imprimir la salida en algún archivo (por ejemplo: echo "Working fine" >>
   output.txt)
3. Verifique el archivo output.txt usando el comando: tail -f output.txt, que imprimirá las últimas adiciones en este archivo, y así podrá hacer un seguimiento de la ejecución del script

Answer 6

Ninguna de estas respuestas se ajusta a mi situación específica, por lo que quería ejecutar una tarea cron específica, solo una vez, y ejecutarla de inmediato.

Estoy en un servidor Ubuntu, y uso cPanel para configurar mis trabajos cron.

Simplemente escribí mi configuración actual, y luego los edité en un minuto a partir de ahora. Cuando solucioné otro error, lo edité nuevamente en un minuto a partir de ahora. Y cuando terminé, restablecí la configuración tal como estaba antes.

Ejemplo: son las 4:34 pm en este momento, así que puse 35 16 * * * para que se ejecute a las 16:35.

Funcionó a la perfección, y lo máximo que tuve que esperar fue un poco menos de un minuto.

Pensé que esta era una opción mejor que algunas de las otras respuestas porque no quería ejecutar todas mis cuentas semanales, y no quería que el trabajo se ejecutara cada minuto. Me toma unos minutos solucionar los problemas antes de que esté listo para probarlo de nuevo. Esperemos que esto ayude a alguien.

Answer 7

Normalmente pruebo ejecutando el trabajo que he creado de esta manera:

Es más fácil usar dos terminales para hacer esto.

ejecutar trabajo

#./jobname.sh

ir:

#/var/log and run 

Ejecuta lo siguiente:

#tailf /var/log/cron

Esto me permite ver la actualización de los registros cron en tiempo real. También puede revisar el registro después de ejecutarlo, prefiero verlo en tiempo real.

Aquí hay un ejemplo de un simple trabajo cron. Ejecutando una actualización de 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

Aquí está el desglose:

El primer comando actualizará yum y el siguiente aplicará las actualizaciones del sistema.

-R 120: establece la cantidad máxima de tiempo que yum esperará antes de ejecutar un comando

-e 0: establece el nivel de error en 0 (rango 0 - 10). 0 significa imprimir solo los errores críticos sobre los que se le debe informar.

-d 0: establece el nivel de depuración en 0; aumenta o disminuye la cantidad de elementos que se imprimen. (rango: 0 - 10).

-y: Supongamos que sí; Supongamos que la respuesta a cualquier pregunta que se haga es sí.

Después de crear el trabajo cron, ejecuté el siguiente comando para hacer que mi trabajo sea ejecutable.

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

Espero que esto ayude, Dorlack

Answer 8

Solo haz lo que hace cron, ejecuta 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 script antes de que se ejecuten.

Answer 9

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

El "¿cómo puedo probar un trabajo cron?" La pregunta está estrechamente relacionada con "¿Cómo pruebo los 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 de * nix lanzan scripts o fragmentos de scripts de forma no interactiva, y con frecuencia las condiciones en las que se ejecutan esos scripts contienen algo inesperado y se rompen hasta que se solucionan los errores.

Es útil tener un enfoque general de 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 de GNU desde cron, para que pueda adjuntar con un terminal separado para ver qué está sucediendo, interactuar con el script, incluso usar un depurador.

Para configurar esto, usaría "todas las estrellas" en su entrada de crontab, y especificará 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 adjuntarlo y verlo ejecutarse. 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 la pantalla (presione intro después de adjuntar)

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

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

Ahora, si adjunta con "screen -x", se enfrentará a una sesión de bashdb interactiva, y puede recorrer el código, examinar las 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

Answer 10

Usaría un archivo de bloqueo y luego configuraría la tarea cron para que se ejecutara cada minuto. (use crontab -e y * * * * * / path / to / job) De esa manera, puede seguir editando los archivos y cada minuto se probarán. Además, puede detener el cronjob simplemente tocando 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

Answer 11

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

los archivos en ese directorio crontabs/ deben ser ejecutables por el propietario - octal 700

fuente: man cron y NNRooth ''s