come posso fare in modo che cron esegua un lavoro in questo momento, per test / debugging? senza cambiare il programma!

135

Ho un lavoro cron che è programmato per essere eseguito tutti i giorni, oltre a cambiare la pianificazione, c'è un altro modo per eseguire un test del comando in questo momento per vedere se funziona come previsto?

cron debugging

— Ali
fonte

Non capisco la tua domanda? Perché non semplicemente eseguire il comando?

— Favadi,

21

So che il comando funziona quando lo inserisci nella shell (la mia shell), ma voglio sapere se funziona quando lo cronesegue, potrebbe essere influenzato da ENV o roba specifica della shell ( ~espansione) o proprietà e roba di autorizzazione o ...

— Ali,

2

Quindi perché non creare un nuovo cron job eseguito ogni minuto con lo stesso comando?

— Favadi,

13

Questo è esattamente quello che ho finito per fare, ma mi chiedevo se c'è un modo per dire a cron che vuoi eseguire un test sul lavoro n. 7! Sicuramente altri hanno già avuto questo problema / richiesta / desiderio!

— Ali,

4

Molto tardi sulla scena qui tramite Google, ma c'era qualcosa di sbagliato nella risposta di Favadi. Era chiaro che voleva provarlo da cron e senza modificare specificamente il crontab per farlo. Molto peggio di qualcuno che ti dice che cosa vuoi è sbagliato quando non hanno provato a capire il caso d'uso.

— HörmannHH,

32

Per quanto ne so non c'è modo di farlo direttamente poiché cron ha uno scopo speciale: eseguire i programmi di pianificazione in un momento specifico. Quindi la cosa migliore è creare manualmente una voce crontab o scrivere uno script che rimuova e ripristini l'ambiente.

— Ulrich Dangel
fonte

57

È possibile forzare l'esecuzione di crontab con il seguente comando:

run-parts /etc/cron.daily

— Vadim Sluzky
fonte

9

... partendo dal presupposto che il cron job dell'OP (richiesto 3 anni fa) è in cron.daily al contrario di un crontab individuale.

— Jeff Schaller

18

Questo, tuttavia, non simula completamente l'ambiente dell'utente cron, quindi è molto probabile che tu abbia ancora dei bug perché una volta eseguito lo script come un vero lavoro cron il tuo PATH e altri avvocati potrebbero essere diversi dall'utente che hai fatto run-parts /etc/cron.daily. Sto combattendo questo bug in questo momento, poiché il mio script funzionerà bene run-partsma fallisce quando effettivamente viene eseguito sotto l'utente cron.

— ArtHare,

42

È possibile simulare l'ambiente utente cron come spiegato in "Esecuzione manuale e immediata di un processo cron" . Ciò consentirà di testare il lavoro eseguito quando verrà eseguito come utente cron.

Estratto dal link:

Passaggio 1 : inserisco temporaneamente questa riga nel crontab dell'utente:

* * * * *   /usr/bin/env > /home/username/tmp/cron-env

poi l'ha tolto una volta che il file è stato scritto.

Step 2 : Mi sono fatto un piccolo script bash run-as-cron contenente:

#!/bin/bash
/usr/bin/env -i $(cat /home/username/tmp/cron-env) "$@"

Quindi, come utente in questione, sono stato in grado di farlo

run-as-cron /the/problematic/script --with arguments --and parameters

— Michael Barton
fonte

Trucco utile. Ovviamente, ciò non sarà d'aiuto se hai un segno di percentuale nel tuo comando.

— basic6,

0

Ho trovato una soluzione che sembra essere un po 'migliore per i miei scopi (comandi mostrati per CentOS / RHEL-like, ma dovrebbe essere adattabile praticamente ovunque).

Ciò richiede libfaketime: puoi crearlo tu stesso da sorgente su https://github.com/wolfcw/libfaketime o semplicemente usare uno dei tanti pacchetti di https://pkgs.org/download/libfaketime .

Interrompere il servizio di assistenza - service crond stop
Scopri quando il tuo servizio dovrebbe essere gestito da - https://crontab.guru è abbastanza utile per questo.
Esegui crond in modalità primo piano tramite lo faketimestrumento libfaketime (ti consente di falsificare la syscall per ricerche temporali per qualsiasi processo figlio).
1. Non lo farei su un server di produzione
2. faketime '2019-10-17 07:59:50' /usr/sbin/crond -n -x test,sch

[root@user-crontesting-dvc-01 ~]# faketime '2019-10-17 07:59:50' /usr/sbin/crond -n -x sch
debug flags enabled: sch
[4841] cron started
log_it: (CRON 4841) INFO (Syslog will be used instead of sendmail.)
log_it: (CRON 4841) INFO (RANDOM_DELAY will be scaled with factor 34% if used.)
log_it: (CRON 4841) INFO (running with inotify support)
[4841] GMToff=0
log_it: (CRON 4841) INFO (@reboot jobs will be run at computer's startup.)
[4841] Target time=1571299200, sec-to-wait=11
user [root:0:0:...] cmd="/usr/libexec/myexc/crontesting.cron > /dev/null 2> &1"
[4841] Target time=1571299260, sec-to-wait=60
log_it: (root 4844) CMD (/usr/libexec/myexc/crontesting.cron > /dev/null 2> &1)
log_it: (root 4843) CMDOUT (/bin/bash: -c: line 0: syntax error near unexpected token `&')
log_it: (root 4843) CMDOUT (/bin/bash: -c: line 0: `/usr/libexec/myexc/crontesting.cron > /dev/null 2> &1')

— javanix
fonte