Cronjob ogni 1445 minuti


4

Prima di tutto, scusa il mio cattivo inglese. Sono nuovo di Crontab e stavo pianificando alcuni programmi. Stavo raccogliendo alcuni dati da Internet con Python e ho questo sito Web che quando si raccolgono alcuni dati, è necessario attendere esattamente 24 ore per ottenere la parte successiva dei dati, quindi se il mio cronjob inizia ogni giorno alle 00.00 e ne ha bisogno secondi per eseguire Selenium e raschiare i dati. Il giorno successivo deve correre con alcuni secondi di offset per assicurarsi che il passetto sia attivo 24 ore dal momento in cui ho effettuato la raschiatura e non 24 ore dal momento in cui è iniziato il lavoro. Quindi, c'è un modo per eseguire il lavoro ogni giorno con 5 minuti di ritardo rispetto al giorno prima o devo creare qualcosa nello script Python che dormirà più a lungo ogni giorno.

Ci scusiamo per il lungo post

Risposte:


3

o ho bisogno di creare qualcosa nello script Python che dormirà più a lungo ogni giorno.

Probabilmente il più semplice. cron non può gestire le variabili nel tempo. Il atcomando è molto più flessibile quando è il momento di avviare uno script. È necessario uno script che esegue un

at midnight + 1 minute < {script}

1 è una variabile che aumenti in base al giorno di inizio (il giorno 1 è +1 min, il giorno 2 è +2 min ecc.). Tieni conto che a un certo punto ti imbatterai in problemi: in 60 * 24 = 1440 giorni avresti dovuto correre oltre la mezzanotte successiva. Aggiungi quello script al tuo cron.

C'è anche at -tdove si imposta un orario che lo renderebbe comandi normali in cui non è necessario cron:

at -t 201903300000
at -t 201903310001    
at -t 201903010002
...
at -t 201912310410 

(alle 0:00 del 30.3.2019, 1 minuto dopo le 0:00 del 31.3, 2 minuti dopo le 0:00 del 1.4 ecc.)


La migliore risposta di sempre in tutti i siti StackExchange, grazie mille.
djsony90,

3

Un altro modo possibile per raggiungere il tuo obiettivo è quello di utilizzare systemd unità timer e unità di servizio invece di un cronjob .

File /etc/systemd/system/my-script.timer:

[Unit]
Description=Timer for MyScript

[Timer]
OnBootSec=2min
OnUnitInactiveSec=1day 5min

[Install]
WantedBy=multi-user.target

File /etc/systemd/system/my-script.service:

[Unit]
Description=MyScript

[Service]
Type=oneshot
ExecStart=/path/to/my-script.sh

Quindi eseguire i seguenti comandi:

sudo systemctl daemon-reload
sudo systemctl enable --now my-script.timer

Ciò abiliterà (= avvio automatico all'avvio) l'unità timer e la avvierà subito.

L'unità timer controlla l'unità di servizio, ovvero: avvia l'unità di servizio con lo stesso nome ( my-script) 2 minuti dopo l'avvio del sistema e da quel momento riavvia l'unità di servizio 1 giorno e 5 minuti dopo che l'unità di servizio è diventata inattivo (= si è fermato).

Se il tempo di avvio è più di 2 minuti nel passato, il timer si attiva immediatamente.

Si noti che l'unità di servizio verrà eseguita come utente root . Per cambiarlo, aggiungi l' User=attributo all'unità di servizio:

[Unit]
Description=MyScript

[Service]
Type=oneshot
User=djsony90
ExecStart=/path/to/my-script.sh

Per verificare lo stato, emettere:

systemctl status my-script.{timer,service}
 my-script.timer - Timer for MyScript
   Loaded: loaded (/etc/systemd/system/my-script.timer; enabled; vendor preset: enabled)
   Active: active (waiting) since Sun 2019-03-31 13:47:29 CEST; 19min ago
  Trigger: Mon 2019-04-01 13:52:59 CEST; 23h left

Mar 31 13:47:29 host systemd[1]: Started Timer for MyScript.

 my-script.service - MyScript
   Loaded: loaded (/etc/systemd/system/my-script.service; static; vendor preset: enabled)
   Active: inactive (dead) since Sun 2019-03-31 13:47:59 CEST; 18min ago
  Process: 22833 ExecStart=/home/pduck/my-script.sh (code=exited, status=0/SUCCESS)
 Main PID: 22833 (code=exited, status=0/SUCCESS)

Mar 31 13:47:29 host systemd[1]: Starting MyScript...
Mar 31 13:47:59 host systemd[1]: Started MyScript.

Qui possiamo vedere che l'unità timer è abilitata (il che significa che si avvierà all'avvio) e attualmente in attesa di 19 minuti. L'unità di servizio verrà attivata a Mon 2019-04-01 13:52:59 ca. 23 ore L'unità di servizio è attualmente inattiva. (Il mio script di test my-script.sh, semplicemente fa un sleep 30.) Possiamo anche vedere che l'unità di servizio è inattiva da allora Sun 2019-03-31 13:47:59. L'aggiunta di 1 giorno e 5 minuti fornisce esattamente Mon 2019-04-01 13:52:59qual è il tempo di attivazione dell'unità timer.

Ulteriori letture:


Sai sicuramente cosa stai facendo amico, lo proverò
djsony90

1
@ djsony90 Prego. le unità timer di systemd sono più flessibili delle cronjob, ma - come puoi vedere qui - sono anche più complicate da scrivere. Oltre allo script, sono sempre necessari altri due file: l'unità di servizio che avvia lo script e l'unità timer che avvia l'unità di servizio. Di solito mi attengo ai cronjobs, ma quando si tratta di cose più complicate a volte uso systemd.
PerlDuck,

1
Mi piace anche questo più del vecchio at.
Rinzwind

1
@Rinzwind Oh, grazie mille. Ma come detto: è più complicato. A proposito, invece di un buon vecchio a atvolte uso ad esempio systemd-run --on-active=10m /path/to/executableo addirittura systemd-run --on-calendar=23:30 systemctl isolate poweroff.target. Vedi systemd-run . E sì, devo ammettere che sono un drogato di sistema ;-)
PerlDuck

1

Invece di usare cron, potresti semplicemente eseguire uno script bash persistente che dorme per un giorno e dieci secondi dopo ogni volta che invoca il tuo programma:

#/bin/bash

while true
do
    ### invoke your program here ###
    sleep 1d 10s
done
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.