vps, dziwne objawy, nag

[palik]

Witam.

Posiadam serwer wirtualny z Debianem 5, który do niedawna działał stabilnie i bez problemu serwował dość sporą stronę www (około 5tys unikalnych wizyt dziennie, około 300 zapytań mysql na sekundę, transfer miesięczny blisko 60GB).

Następnie wydarzyła się awaria dysku hosta, vps został gładko przełączony na zapasowy dysk (po nfs) i działał z kilkukrotnymi zawieszeniami. Składałem to na karb wolnego dostępu do danych.

Następnie do hosta włożono nieco większy nowy dysk i zaczęły się czary, a konkretnie objawy są takie, że serwer działa kilkanaście godzin po czym zaczynają się tworzyć na liście procesów ,,zawieszone'' (nieznikające) procesy p.t.: /USR/SBIN/CRON (zrzut ekrany)

Ponieważ serwer przestawał odpowiadać na żądania http czy ssh, zapuściłem mu w cronie taki banalny wiersz logujący co minutę polecenie:

Kod: Zaznacz cały

uptime

do pliku na dysku, żeby zobaczyć, o której się to dokładnie dzieje,

Okazało się, że 3 dni pod rząd problem występował dokładnie o 5 rano, jakąś minutę po odpaleniu cron.daily.

Dzisiaj będąc podłączonym przez ssh znowu udało mi się zawiesić serwer, około 17:52. Co ciekawe nawiązana sesja ssh nie została przerwana, nie mogłem tylko nawiązać kolejnej.

Co jeszcze ciekawsze, od 17:52 nie był wykonywany ten cominutowy cron, zatem po restarcie serwera zapis w pliku wyglądał tak:

Kod: Zaznacz cały

 17:49:01 up  3:09,  1 user,  load average: 0.48, 0.84, 0.93
 17:50:01 up  3:10,  1 user,  load average: 1.24, 0.96, 0.96
 17:51:01 up  3:11,  1 user,  load average: 1.26, 1.04, 0.99
 17:52:01 up  3:12,  1 user,  load average: 0.70, 0.92, 0.95
 18:43:01 up 0 min,  0 users,  load average: 0.50, 0.15, 0.05
 18:44:01 up 1 min,  0 users,  load average: 0.56, 0.23, 0.08
 18:45:01 up 2 min,  1 user,  load average: 1.82, 0.59, 0.21

Ponadto mysql w tym czasie (co było widać na phpmyadmin w karcie ,,processes'') też łapał procesy śpiące, które nie znikały... (zrzut ekranu)

W trakcie ,,awarii'' próbowałem zrestartować mysql (stop się udał ale start już nie), apache2 (udało się), oraz wykonać:

Kod: Zaznacz cały

/usr/sbin/reboot

bez skutku - pojawiał się komunikat, że serwer się przygotowuje do zamknięcia ale nic poza tym.

Dopiero reset z panelu zarządzania (do którego nie mam niestety dostępu i muszę męczyć admina za każdym razem) pomaga na ten dziwny stan.

Od czego zacząć analizę? Jestem dość miernym użytkownikiem Linuksa, Pooglądałem sobie logi, cron.daily, ale niewiele wywnioskowałem.

Dodam, że w cronie miałem już tylko liczenie webalizera około 2 w nocy i kopię zapasową około 3. Kopia zapasowa wykorzystywała rsynca. Dzisiaj to wszystko powyłączałem i poczekam czy coś będzie się działo?

Może ktoś spotkał się z takim dziwacznym przypadkiem?

Ponieważ bawię się teraz tym serwerem mam pytanie - czy wywołanie polecenia:

Kod: Zaznacz cały

run-parts --report /etc/cron.daily

z wiersza poleceń, na poprawnie działającym systemie, jest z jakiegoś powodu niewskazane?

Patrząc w logi jest to jedno z poleceń, które było wykonane jako ostatnie przed zawieszeniem serwera. Wykonuję je więc ,,na żywo'' i kończy się też zwiechą. Wywaliłem już stamtąd połowę skryptów, zostały tylko sysklogd i sysstat, zaraz sprawdzę co będzie jak je usunę. Siwych włosów mnie ten serwer przysporzy, coś czuję.

[db]

Ponieważ bawię się teraz tym serwerem, mam pytanie - czy wywołanie polecenia:

Kod: Zaznacz cały

run-parts --report /etc/cron.daily

z wiersza poleceń, na poprawnie działającym systemie, jest z jakiegoś powodu niewskazane?

Nie, nie jest niewskazane. Samo uruchamia się codziennie.

Patrząc w logi jest to jedno z poleceń, które było wykonane jako ostatnie przed zawieszeniem serwera. Wykonuję je więc ,,na żywo'' i kończy się też zwiechą. Wywaliłem już stamtąd połowę skryptów, zostały tylko sysklogd i sysstat, zaraz sprawdzę co będzie jak je usunę. Siwych włosów mi ten serwer przysporzy, coś czuję

Sprawdź sobie co się konkretnie dzieje, możesz przez chwilę logować MySQL (wydajność trochę leci), wyklikać vmstat i sprawdzić obciążenie. Trudno cokolwiek wywnioskować bez dostępu do maszyny, logów, informacji.

P.S.
Nie umieszczaj zrzutów ekranu. W terminalu zaznacza się shiftem.

[palik]

Po zmarnowaniu (albo wykorzystaniu) dwóch godzin, namierzyłem, że problem powstaje po uruchomieniu skryptu sysklogd, za każdym razem.

SSH nie pokazuje ani błędu ani zachęty do zalogowania się, a w procesach odkłada się co minutę nowy /USR/SBIN/CRON, bo co minutę mam zapisane w crontab odkładanie do pliku /etc/var/loady jednej linii - wyniku polecenia:

Kod: Zaznacz cały

uptime

, przez co powstaje taki pseudolog:

Kod: Zaznacz cały

 07:40:01 up 1 day,  7:16,  1 user,  load average: 0.41, 0.42, 0.38
 07:41:01 up 1 day,  7:17,  1 user,  load average: 0.79, 0.56, 0.43
 07:42:01 up 1 day,  7:18,  1 user,  load average: 0.85, 0.61, 0.45

Ponieważ okazało się, że log urywa się codziennie rano, zaraz po odpaleniu cron.daily, wyodrębniłem sysklogd próbując uruchamiać cron.daily i usuwając z katalogu kolejne skrypty. Teraz pytanie, czy bez niego da się żyć? Widziałem w Google sporo różnych mało owocnych dyskusji dlaczego akurat tak się dzieje - dyskusje datowane od 1999 roku po dzisiejsze czasy (np tutaj, tutaj)

Poza cron.daily nie znalazłem uruchomienia sysklogd, poczekam 1-2 dni jeśli nie będzie zawieszenia to pewnie będzie ten łobuziak.