Przesyłanie danych wyjściowych wget do / dev / null w cron


38

Uruchamiam następujące polecenie co 5 minut na moim crontabie, aby utrzymać Phusion Passenger przy życiu.

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

Kiedy go uruchomię, wykonuje on wget na adresie URL trasy STDOUT / STDERR do / dev / null. Kiedy uruchamiam to z wiersza poleceń, działa dobrze i nie tworzy pliku index.html w moim katalogu domowym.

Kiedy uruchamia się z crona, tworzy nowy plik index.html co pięć minut, pozostawiając mi mnóstwo plików indeksu, których nie chcę.

Czy moja składnia jest niepoprawna do uruchomienia zadania cron? Z wiersza poleceń działa bez problemu, ale z crona generuje plik index.html w moim katalogu domowym.

Jestem pewien, że popełniam prosty błąd, doceniłbym go, gdyby ktoś mógł pomóc.


1
Kolejne pytanie dotyczy tego, dlaczego nie tworzy się pliku po uruchomieniu go ręcznie z wiersza poleceń. O ile mogę stwierdzić na podstawie dokumentacji, jedyną różnicą między uruchamianiem wgetz terminala a innymi kwestiami jest to, czy wyświetlany jest pasek postępu.
Barmar

Odpowiedzi:


61

Możesz to zrobić w następujący sposób:

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

Tutaj -Owysyła pobrany plik /dev/nulli -ologuje się do /dev/nullzamiast stderr. W ten sposób przekierowanie nie jest wcale potrzebne.


1
Dzięki, jest to bardziej bezpośrednie niż przekierowanie do STDERR / STDOUT. Doceniam to.
nulltek

17

Czy musisz pobrać zawartość, czy po prostu otrzymać 200 OK? Jeśli musisz tylko poprosić serwer o przetworzenie żądania, dlaczego po prostu nie użyjesz --spiderargumentu?


To dobra myśl. Naprawdę potrzebuję tylko odpowiedzi 200 OK.
nulltek

Miałem nadzieję, że ktoś bezstronny zwróci na to uwagę, ale ... jakiego rozwiązania użyłeś? Moja odpowiedź jest naprawdę prawidłowym sposobem, aby to zrobić :)
Nacht - Przywróć Monikę

10

Użyłbym następujących:

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

Ta -O -opcja zapewnia, że ​​pobrana zawartość jest wysyłana na standardowe wyjście.


4
Zauważ, że foo > /dev/null 2>&1jest bardziej zwięźle napisane jako foo &> /dev/null.
amalloy

3
@amalloy Tylko w bash. W sh, co zwykle używa cron, ampersand przekierowanie nie działa.
Soviero

5

Mówisz, że potrzebujesz tylko odpowiedzi „200 OK” w komentarzu.

Pozwala to na rozwiązanie z pewnymi dodatkowymi zaletami w stosunku do
wget -O /dev/null -o /dev/null example.com. Chodzi o to, aby nie odrzucać wyników w jakikolwiek sposób, ale nie tworzyć żadnych wyników.

To, że potrzebujesz tylko odpowiedzi, oznacza, że ​​dane pobrane do lokalnego pliku index.html nie muszą być pobierane w pierwszej kolejności.
W protokole HTTP do pobrania dokumentu służy polecenie „GET” . Aby uzyskać dostęp do dokumentu w sposób, który robi wszystko oprócz faktycznego pobrania dokumentu, istnieje specjalne polecenie „HEAD”.
Podczas korzystania z polecenia „GET” do tego zadania dokument jest pobierany i odrzucany lokalnie. Używanie „HEAD” robi dokładnie to, czego potrzebujesz, nie przenosi dokumentu w pierwszej kolejności. Zawsze zwróci ten sam kod wyniku, co z definicji „GET”.

Składnia użyć metody HEADze wgetto trochę dziwne: musimy użyć opcji --spider. W tym kontekście robi to, co chcemy - uzyskuje się dostęp do adresu URL za pomocą „HEAD” zamiast „GET”.
Możemy użyć opcji -q(ciche), aby wgetnie wyświetlać szczegółowych informacji o tym, co robi.

Łącząc to, wgetnie wyprowadzi niczego do stderr ani nie zapisze dokumentu.

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

Kod wyjścia informuje nas, czy żądanie powiodło się, czy nie:

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

W przypadku polecenia in crontabfakt, że w obu przypadkach nie ma danych wyjściowych, oznacza, że ​​możesz ponownie użyć braku danych jako wskaźnika błędów.

Twoje przykładowe polecenie zostanie zmienione na:

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

Ma to takie same zalety jak wget -O /dev/null -o /dev/null example.com. Dodatkową zaletą jest to, że dane wyjściowe dziennika i dokumentu nie są generowane, zamiast generowane i odrzucane lokalnie. Lub oczywiście wielka różnica jest unikanie pobrać, a następnie odrzucić dokument index.html.


Lubię to podejście. Doceniam twoją opinię i odpowiedź.
nulltek

3

aby utrzymać przy życiu Pasażera Phusion.

Niech twoje pytanie powinno dotyczyć tego, strona mówi:

Szybki i niezawodny serwer WWW i serwer aplikacji dla

Nie powinno to wymagać żadnych skryptów podtrzymujących działanie.

W przeciwnym razie rozwiązanie kasperda jest idealne.


Dzięki za opinie, choć nie jest to zbyt konstruktywne. Serwery aplikacji zawodzą - chociaż zwykle nie jest to wina kontenera.
Felix Frank,

1
Zgadzam się, że nie powinno wymagać żadnych cronjobs, aby utrzymać go przy życiu. Ale to było szybkie rozwiązanie, gdy badam tuning Nginx / Passenger. Naprawdę szukałem najlepszego sposobu na wyjście do / dev / null. Miałem błąd pasażera lub zawiesiłem się na 2 minuty w czasie, gdy nie ma ładunku, więc żądanie adresu URL powoduje, że pasażer jest na razie zwolniony.
nulltek

1
Dobrze byłoby zrozumieć, co wgetprzykazania utrzymują przy życiu . W wielu sytuacjach potrzeba utrzymywania żywych komunikatów jest objawem podstawowej wady projektowej, którą należy naprawić. Ale nawet jeśli wszystkie zostaną naprawione, nadal pozostanie kilka przypadków, w których komunikat utrzymania przy życiu jest właściwym rozwiązaniem. Nawet jeśli komunikaty podtrzymywania aktywności nie są potrzebne, zadanie cron może nadal być użyteczną częścią konfiguracji monitorowania.
kasperd

Byłoby to lepsze jako komentarz niż odpowiedź.
moopet
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.