Esistono schemi stabiliti per l'installazione di un kill o di un interruttore on / off per i lavori cron utente?

Abbiamo build longish che in genere pianifichiamo i nostri lavori cron, ma a volte dobbiamo rieseguire una build durante un periodo di tempo non standard e possiamo imbatterci in conflitti con processi cron che in genere sono sicuri da eseguire in quei momenti.

Abbiamo più account che eseguono sia build che cron job, quindi non possiamo sospendere il servizio crontab per l'intero computer e riavviarlo in seguito.

Mi chiedevo se qualcuno avesse un modello o un'implementazione. Immagino che funzioni così

L'utente crea un file: ~ / block-crontab
utente esegue build Il lavoro cron cerca quel file nella directory home dell'utente e se è presente salta tutti i lavori cron. Altrimenti esegue i lavori. Al termine della compilazione, l'utente rimuove ~ / block-crontab

Funzionerebbe? Immagino che dovrei modificare lo script cron in qualche modo. Mi chiedo soprattutto se esiste un approccio migliore / standard a questo problema?

Grazie.

Piuttosto che scherzare crond, consiglio vivamente di implementare una forma (anche semplice) di blocco all'interno degli script di compilazione. Ad esempio, toccare e verificare la presenza di un file in/var/run/ : se lo script trova qualcosa, un altro processo sta costruendo il progetto. È ovviamente necessario rimuovere il file di blocco al termine.

Come notato da @GnP nei commenti, puoi anche usare l' flockutilità per gestire in modo semi-automatico i tuoi lockfile.

Se non si fa / non si può fare affidamento su alcun meccanismo di blocco, emettere semplicemente a service crond stopper arrestare il crondsistema.

Tendo ad avvolgere tutti i comandi a esecuzione prolungata in uno schermo e ottenere cron ad avviare la schermata solo se non ce n'è già uno in esecuzione.

Quindi la seguente riga in crontab

*/2 * * * *  /bin/bash /path/to/LongRunningScript.bash

... si trasforma in qualcosa del genere:

*/2 * * * *  /usr/bin/screen -S MyUniqueName -Q select . || /usr/bin/screen -dmS MyUniqueName /bin/bash /path/to/LongRunningScript.bash

Mi piace perché ti dà anche la possibilità di collegarti a uno script in esecuzione e controllarne l'output / lo stato.

Nel tuo scenario, potresti ottenere cronun'altra schermata prima di eseguire una build, ad esempio

0 3 * * *  /usr/bin/screen -S ManualBuild -Q select . || /usr/bin/screen -dmS AutomatedBuild /bin/bash /path/to/BuildScripts.bash
10 3 * * *  /usr/bin/screen -S ManualBuild -Q select . || /usr/bin/screen -dmS OtherAutomatedBuild /bin/bash /path/to/OtherBuildScripts.bash

Quando esegui una compilazione manuale, passa a una screenprima prima di eseguire lo script (commenta se hai bisogno di suggerimenti su come connetterti / disconnettiti screen. È un'utilità utile: dai un'occhiata se non hai ancora iniziato a usarlo)

Digita screen -S ManualBuild, premi [enter]ed esegui qualsiasi comando tu voglia eseguire.

Nota: se si utilizza l'esempio fornito, è possibile confondere cronse si dispone di più di una sessione dello schermo con un nome di "ManualBuild" in esecuzione.