Piping dell'output di wget su / dev / null in cron


39

Sto eseguendo il seguente comando ogni 5 minuti nel mio crontab per mantenere vivo Phusion Passenger.

*/5 * * * * wget mysite.com > /dev/null 2>&1

Quando eseguo questo, esegue un wget sul sito URL instrada STDOUT / STDERR a / dev / null. Quando eseguo questo da una riga di comando funziona bene e non produce un file index.html nella mia directory home.

Quando viene eseguito da cron, crea un nuovo file index.html ogni cinque minuti, lasciandomi con una tonnellata di file indice che non voglio.

La mia sintassi non è corretta per l'esecuzione del processo cron? Da una riga di comando funziona senza problemi ma da cron genera un file index.html nella mia directory home.

Sono sicuro che sto facendo un semplice errore, lo apprezzerei se qualcuno potesse dare una mano.


1
Un'altra domanda è perché questo non sta creando un file quando lo si esegue dalla riga di comando a mano. Per quanto ne so dalla documentazione, l'unica differenza tra l'esecuzione wgetda un terminale e altrimenti è se viene visualizzata una barra di avanzamento.
Barmar,

Risposte:


62

Potresti farlo in questo modo:

*/5 * * * * wget -O /dev/null -o /dev/null example.com

Qui -Oinvia il file scaricato /dev/nulle -oregistra /dev/nullinvece di stderr. In questo modo il reindirizzamento non è affatto necessario.


2
Grazie, questo è più diretto del reindirizzamento a STDERR / STDOUT. Lo apprezzo.
nulltek,

17

Devi effettivamente scaricare i contenuti o semplicemente ricevere 200 OK? Se devi solo fare in modo che il server elabori la richiesta, perché non usare semplicemente l' --spiderargomento?


È una buona idea. Ho davvero bisogno solo della risposta 200 OK.
nulltek,

Speravo che qualcuno imparziale lo segnalasse, ma ... quale soluzione hai usato? La mia risposta è davvero il modo corretto per farlo :)
Nacht - Reinstate Monica il

10

Vorrei usare quanto segue:

/5 * * * * wget -O - mysite.com > /dev/null 2>&1

L' -O -opzione assicura che il contenuto recuperato sia inviato a stdout.


4
Si noti che foo > /dev/null 2>&1è scritto in modo più conciso come foo &> /dev/null.
amalloy,

3
@amalloy Solo in bash. In sh, che di solito è quello che usa cron, il reindirizzamento e commerciale non funziona.
Soviero,

5

Dici che hai solo bisogno della risposta "200 OK" in un commento.

Ciò consente una soluzione con alcuni vantaggi aggiuntivi rispetto a quelli di
wget -O /dev/null -o /dev/null example.com. L'idea non è di scartare l'output in qualche modo, ma di non creare alcun output.

Il fatto che sia necessaria solo la risposta significa che i dati scaricati nel file locale index.html non devono essere scaricati in primo luogo.
Nel protocollo HTTP, il comando 'GET' viene utilizzato per scaricare un documento . Per accedere a un documento in un modo che fa tutto tranne che in realtà il download del documento, c'è un comando speciale 'HEAD'.
Quando si utilizza 'GET' per questa attività, il documento viene scaricato e scartato localmente. L'uso di "HEAD" fa esattamente ciò di cui hai bisogno, in primo luogo non trasferisce il documento. Restituirà sempre lo stesso codice risultato di "GET", per definizione.

La sintassi per utilizzare il metodo HEADcon wgetè un po 'strano: abbiamo bisogno di utilizzare l'opzione --spider. In questo contesto, fa solo quello che vogliamo: accedi all'URL con "HEAD" anziché "GET".
Possiamo usare l'opzione -q(quiet) per wgetnon produrre dettagli su ciò che fa.

Combinando ciò, wgetnon verrà emesso nulla su stderr, né verrà salvato un documento.

wget -q --spider 'http://example.com/'

Il codice di uscita ci dice se la richiesta ha avuto esito positivo o meno:

$ wget -q --spider 'http://example.com/'
$ echo $?
0
$ wget -q --spider 'http://example.com/nonexisting'
$ echo $?                                          
8

Per un comando crontab, il fatto che in entrambi i casi non sia presente alcun output significa che è possibile utilizzare nuovamente l'output come indicazione di errori.

Il comando di esempio verrà modificato in questo:

*/5 * * * * wget -q --spider mysite.com

Questo ha gli stessi vantaggi di wget -O /dev/null -o /dev/null example.com. Il vantaggio aggiuntivo è che l'output del registro e l'output del documento non vengono generati, anziché generati e scartati localmente. O ovviamente la grande differenza sta nell'evitare di scaricare e quindi scartare il documento index.html.


Mi piace anche questo approccio. Apprezzo il tuo feedback e la tua risposta.
nulltek,

3

per mantenere vivo il passeggero Phusion.

Possa la tua domanda riguardare questo, la pagina web dice:

Un web server e un application server veloci e affidabili per

Ciò non dovrebbe richiedere script keepalive.

Altrimenti la soluzione di Kasperd è perfetta.


Grazie per il feedback, anche se non è molto costruttivo. I server delle applicazioni falliscono, sebbene di solito non sia colpa del contenitore.
Felix Frank,

1
Sono d'accordo che non dovrebbe richiedere alcun cronjobs per mantenerlo in vita. Ma è stata una soluzione rapida mentre cerco Nginx / Passenger tuning. Stavo davvero cercando il modo migliore per eseguire l'output su / dev / null. Ho avuto un guasto o un arresto del passeggero per 2 minuti in un momento in cui non c'è carico, quindi richiedere l'URL mantiene il passeggero acceso per ora.
nulltek,

1
Sarebbe bene capire che cosa viene tenuto in vita dai wgetcomandi. In molte situazioni la necessità di mantenere messaggi vivi è un sintomo di un difetto di progettazione sottostante che dovrebbe essere risolto. Ma anche se tutti questi sono risolti, ci saranno ancora alcuni casi in cui un messaggio keep alive è la soluzione giusta. Anche se i messaggi keep alive non sono necessari, il processo cron potrebbe comunque essere una parte utile di un'impostazione di monitoraggio.
Kasperd,

Sarebbe meglio come commento che come risposta.
Moopet,
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.