launchd notifica sull'uscita anomala

Question

launchd notifica sull'uscita anomala

#1 da (1 voti)

2

Ho un plist di lavoro launchd che esegue un semplice script di shell che richiama rdiff-backup per eseguire il backup di una directory remota su SSH sul mio computer. Il lavoro viene eseguito ogni ora e funziona bene.

Tranne l'altro giorno c'è stata un'interruzione dell'alimentazione * e il lavoro di backup rdiff è stato interrotto. La prossima volta che launchd ha eseguito lo script, rdiff-backup ha avuto esito negativo e ha registrato il suo errore nel percorso specificato nel plist. launchd, notando il codice di uscita anomalo, ha smesso di provare a eseguire lo script.

E non ne avevo idea per sei giorni.

Ovviamente non voglio una notifica del codice di uscita ogni tempo in cui termina lo script. Cosa posso fare per essere avvisato solo di uscite anomale?

(*) la batteria del mio UPS ha superato l'autotest quando è stata richiamata, ma in realtà non ha la capacità di alimentare anche un carico minimo per più di 3 secondi.

notifications launchd schedule

posta samh 10.02.2015 - 20:58

fonte

1 risposta

Leggi altre domande sui tag notifications launchd schedule

Come cambiare il modello di contatto predefinito È una cattiva idea compilare Samba dal sorgente per Mac?

score 1 · Accepted Answer

L'approccio tradizionale, ad es. con cron jobs, è quello di convogliare l'errore standard a un programma come mail che è abbastanza intelligente da non inviarti posta vuota. La differenza con launchd, come hai scoperto, è che il meccanismo per reindirizzare l'errore standard sta dando un StandardErrorPath per il quale scrivere, il che non è così conveniente a questo scopo che termina la tua voce crontab con | mail … .

La mia solita soluzione è di avere uno script wrapper che controlli StandardErrorPath e avvisami se c'è un problema. Questo può essere parte dello stesso lavoro di avvio, quindi il controllo avviene prima della prossima esecuzione pianificata, oppure puoi avere un lavoro separato che gestisce solo i log degli errori (magari usando una chiave QueueDirectories ).

Penso che potresti anche, ad esempio, utilizzare una named pipe come StandardErrorPath del tuo lavoro, ma non l'ho mai provato.