Test een wekelijkse cron job

Ik heb een #!/bin/bashbestand in cron.week directory.

Is er een manier om te testen of het werkt? Kan niet wachten 1 week

Ik gebruik Debian 6 met root

Antwoord 1, autoriteit 100%

Doe gewoon wat cron doet, voer het volgende uit als root:

run-parts -v /etc/cron.weekly

… of de volgende als u de foutmelding “Not a directory: -v” krijgt:

run-parts /etc/cron.weekly -v

Optie -vdrukt de scriptnamen af voordat ze worden uitgevoerd.

Antwoord 2, autoriteit 39%

Een klein beetje buiten het bestek van je vraag… maar dit is wat ik doe.

De “hoe test ik een cron job?” vraag is nauw verbonden met “hoe test ik scripts die worden uitgevoerd in niet-interactieve contexten die door andere programma’s zijn gestart?” In cron is de trigger een tijdsvoorwaarde, maar veel andere *nix-faciliteiten starten scripts of scriptfragmenten op niet-interactieve manieren, en vaak bevatten de omstandigheden waarin die scripts worden uitgevoerd iets onverwachts en veroorzaken ze breuk totdat de bugs zijn opgelost. (Zie ook: https://stackoverflow.com/a/17805088/237059)

Een algemene benadering van dit probleem is handig om te hebben.

Een van mijn favoriete technieken is om een script te gebruiken dat ik heb geschreven met de naam ‘crontest‘. Het start het doelcommando binnen een GNU-schermsessie vanuit cron, zodat je met een aparte terminal kunt koppelen om te zien wat er aan de hand is, interactie met het script, zelfs een debugger gebruiken.

Om dit in te stellen, gebruikt u “alle sterren” in uw crontab-item en specificeert u crontest als het eerste commando op de opdrachtregel, bijvoorbeeld:

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

Dus nu zal cron je commando elke minuut uitvoeren, maar crontest zorgt ervoor dat er maar één instantie tegelijk wordt uitgevoerd. Als de opdracht tijd nodig heeft om uit te voeren, kunt u een “screen -x” doen om deze toe te voegen en te zien hoe deze wordt uitgevoerd. Als de opdracht een script is, kun je bovenaan een “lees”-opdracht plaatsen om het te laten stoppen en te wachten tot de schermbijlage is voltooid (druk op enter na het bijvoegen)

Als uw opdracht een bash-script is, kunt u dit in plaats daarvan doen:

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

Als je nu koppelt met “screen -x”, krijg je een interactieve bashdb-sessie te zien en kun je door de code stappen, variabelen onderzoeken, enz.

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

Antwoord 3, autoriteit 20%

Na wat geknoeid te hebben met wat dingen in cron die niet meteen compatibel waren, ontdekte ik dat de volgende aanpak leuk was om te debuggen:

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

Hiermee wordt de taak één keer per minuut uitgevoerd en u kunt gewoon in het bestand /tmp/cron_debug_log.logkijken om erachter te komen wat er aan de hand is.

Het is niet bepaald de “vuurwerk” waar je naar op zoek bent, maar dit heeft me enorm geholpen bij het debuggen van een script dat in eerste instantie niet werkte in cron.

Antwoord 4, autoriteit 10%

Ik zou een vergrendelingsbestand gebruiken en vervolgens de cron-taak zo instellen dat deze elke minuut wordt uitgevoerd. (gebruik crontab -e en * * * * * /path/to/job) Op die manier kun je de bestanden gewoon blijven bewerken en elke minuut worden ze getest. Bovendien kun je de cronjob stoppen door het vergrendelingsbestand aan te raken.

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

Antwoord 5, Autoriteit 2%

Hoe zit het met het plaatsen van het in cron.hourly, WACHTEN tot de volgende run van Jobs van het Uurly Cron en vervolgens het verwijderen? Dat zou het een keer binnen een uur lopen, en in de Cron-omgeving. U kunt ook ./your_script, maar dat heeft niet dezelfde omgeving als onder Cron.

Antwoord 6, Autoriteit 2%

Afgezien daarvan kunt u ook gebruiken:

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

Om uw cron af te ronden om u een e-mail te sturen bij succes of falen.

Antwoord 7, Autoriteit 2%

Geen van deze antwoorden bij mijn specifieke situatie, wat was dat ik één specifieke cron-taak wilde uitvoeren, maar één keer, en voer het onmiddellijk uit.

Ik sta op een Ubuntu-server en ik gebruik CPANEL om mijn cron-taken in te stellen.

Ik heb gewoon mijn huidige instellingen opgeschreven en bewerkte ze vervolgens één minuut van nu. Toen ik nog een bug had opgelost, heb ik het net opnieuw op één minuut gewerkt. En toen ik helemaal klaar was, stel ik de instellingen terug naar hoe ze eerder waren.

Voorbeeld: het is nu om 16:34 uur, dus ik zet 35 16 * * *, om te rennen om 16:35.

Het werkte als een charme, en het meest dat ik ooit moest wachten, was iets minder dan een minuut.

Ik dacht dat dit een betere optie was dan sommige van de andere antwoorden omdat ik niet al mijn wekelijkse crons wilde rennen, en ik wilde niet dat de baan elke minuut draait. Het kost me een paar minuten om te repareren wat de problemen waren voordat ik klaar ben om het opnieuw te testen. Hopelijk helpt dit iemand.

Antwoord 8

De oplossing die ik gebruik is als volgt:

1. Crontab bewerken (gebruik commando: crontab -e) om de taak zo vaak te laten uitvoeren
   indien nodig (elke 1 minuut of 5 minuten)
2. Wijzig het Shell-script dat moet worden uitgevoerd met behulp van Cron om de uitvoer in een bestand af te drukken (bijvoorbeeld: ECHO “Fijn” & GT; & GT;
   output.txt)
3. Controleer het bestand Output.txt met behulp van de opdracht: Tail -F-output.txt, die de nieuwste toevoegingen in dit bestand afdrukt en dus kunt u de uitvoering van het script volgen

Antwoord 9

Ik test normaal door de taak te gebruiken die ik zo is gemaakt:

Het is gemakkelijker om twee terminals te gebruiken om dit te doen.

Werk uitvoeren:

#./jobname.sh

Ga naar:

#/var/log and run 

Voer het volgende uit:

#tailf /var/log/cron

Hierdoor kan ik de Cron-logs-update in realtime zien. U kunt het logboek ook bekijken nadat u het hebt uitgevoerd, ik liever in realtime kijk.

Hier is een voorbeeld van een eenvoudige cron-taak. Een yum-update uitvoeren …

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

Hier is de uitsplitsing:

Eerste opdracht wordt yum zelf bijgewerkt en vervolgens Systeemupdates toepassen.

-R 120: Stelt de maximale hoeveelheid tijd in staat om te wachten voordat u een opdracht

uitvoert

-E 0: Stelt het foutniveau in op 0 (bereik 0 – 10). 0 betekent alleen kritieke fouten afdrukken waarover u verteld moet worden.

-D 0: Stelt het debuggeniveau in op 0 – draait omhoog of omlaag de hoeveelheid dingen die zijn afgedrukt. (Bereik: 0 – 10).

-y: aannemen Ja; Neem aan dat het antwoord op elke vraag die zou worden gesteld, ja

Nadat ik de Cron-taak heb gebouwd, liep ik de onderstaande opdracht om mijn functie-uitvoerbaar bestand te maken.

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

Ik hoop dat dit helpt,
Dorlack

Antwoord 10

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

Bestanden in dat crontabs/Directory moet uitvoerbaar zijn door eigenaar – octal 700

Bron: man cronEN NNRooth‘S

Antwoord 11

Ik gebruik Webmin omdat het een productiviteit edelsteen is voor iemand die opdrachtregeladministratie een beetje ontmoedigend vindt en ondoordringbaar.

Er is een knop “Opslaan en uitvoeren” in het “Systeem & GT; Geplande Cron Jobs & GT; Edit Cron Job” Web Interface.

Het geeft de uitvoer van de opdracht weer en is precies wat ik nodig had.