Moje boje z NTP (Network Time Protokol) w systemie Raspbian (Debian) m.in. na potrzeby Simple Storage Service (S3)

Niedawno pisałem o błędzie „RequestTimeTooSkewed” podczas (automatycznej, na szczęście skrypt to wykrył) próby zamontowania zasobu sieciowego S3 na Raspberry Pi, a przyczyną tego była różnica czasu na serwerze S3 i Raspberry Pi – skorygowałem, i niby wszystko OK. Dziś ponownie dostałem e-mail, że skrypt napotkał błąd – od razu skojarzyłem, że wczoraj była kilku(nasto) minutowa przerwa serwisowa w zasilaniu Raspberry Pi, więc pewnie ponownie czas nie został zsynchronizowany, a więc nie zadziałała prawidłowo usługa NTP.

NTP (Network Time Protokol)

Z racji tego, że Raspberry Pi nie ma zegara czasu rzeczywistego (gdy to potrzebne można dodać odpowiedni moduł RTC i podłączyć po GPIO), to czas jest synchronizowany przez internet, za pomocą protokołu/usługi  NTP.

Wprawdzie wspomaga Malinę jeszcze tzw. „fałszywy zegar sprzętowy” (fake-hwclock), ale sprawdza się to względnie przy restartach – natomiast nic nie da przy wyłączeniu systemy na dłuższy czas (usługa fake-hwclock zapisuje czas do pliku i podczas ponownego startu go odczytuje).

Czas systemowy – podejście pierwsze

Sprawdzanie czasu zacząłem od polecenia:

patryk@rpi01 ~ $ date
Sat 28 Nov 10:02:32 CET 2015

I pewnie nie byłoby to dziwne, gdyby nie to, że w tym momencie była 12:02:32, a więc 2 godziny później niż pokazał serwer/system.

Sprawdziłem ustawienia strefy czasowej:

patryk@rpi01 ~ $ cat /etc/timezone
Europe/Warsaw

Wyglądało OK, ale na wszelki wypadek postanowiłem jeszcze raz ustawić odpowiednią strefę czasową:

sudo dpkg-reconfigure tzdata

Sprawdziłem również ustawienia w pliku konfiguracyjnym NTP (Network Time Protokol):

sudo nano /etc/ntp.conf

Oraz zrestartowałem usługę:

sudo /etc/init.d/ntp restart

A gdy to nie pomogło, zrestartowałem Malinę.

Wymuszenie synchronizacji czasu

Kolejnym krokiem było skorzystanie z narzędzia „ntpdate”, i wymuszenie aktualizacji czasu w systemie (wiem, mogłem ustawić ręcznie, ale chodziło również o test samej usługi NTP):

sudo ntpdate -u tempus1.gum.gov.pl

sudo apt-get install ntpdate

sudo apt-get install ntp

Po tej operacji szybkie sprawdzenie czasu w systemie:

patryk@rpi01 ~ $ date
Sat 28 Nov 12:05:21 CET 2015

Czas OK, więc i zamontowanie zasobu S3 przebiegło bez problemu…

Czas systemowy – podejście drugie

Z racji tego, że nie bardzo miałem czas na jakieś dodatkowe testy/analizy – o całej sprawie zapomniałem, zwłaszcza że przez kolejne dni wyglądało na to, że wszystko działa prawidłowo.

Aż do dzisiejszego poranka, gdy otrzymałem e-mail, o którym wspomniałem w jednym z pierwszych akapitów tego wpisu.

Szybkie sprawdzenie czasu – nawet nie sprawdzałem błędu s3fs, bo w połączeniu z przerwą w zasilaniu byłem praktycznie pewien, że ponownie będzie to problem z czasem – i miałem potwierdzenie:

patryk@rpi01 ~ $ date
Sat 5 Dec 10:02:32 CET 2015

A na zegarze obok 10:24:35, więc różnica dość spora, i zarazem pokrywająca się z około 20-minutową przerwą techniczną.

Status usługi NTP

Tym razem postanowiłem zacząć od sprawdzenia statusu usługi NTP za pomocą polecenia:

timedatectl status

W odpowiedzi otrzymałem m.in. takie informacje:

Local time: Sat 2015-12-05 10:08:38 CET
Universal time: Sat 2015-12-05 09:08:38 UTC
RTC time: n/a
Time zone: Europe/Warsaw (CET, +0100)
NTP enabled: no
NTP synchronized: yes

Co istotne – synchronizacja NTP była aktywna, ale sama usługa nie, a więc postanowiłem tutaj szukać rozwiązania problemu.

Aktywacja NTP

Ponowną (bo kiedyś działała) aktywację usługi NTP przeprowadziłem za pomocą polecenia:

sudo timedatectl set-ntp true

Po czym ponownie sprawdziłem status usługi:

patryk@rpi01 ~ $ timedatectl status
Local time: Sat 2015-12-05 10:32:05 CET
Universal time: Sat 2015-12-05 09:32:05 UTC
RTC time: n/a
Time zone: Europe/Warsaw (CET, +0100)
NTP enabled: yes
NTP synchronized: no

Jak widać tym razem – dla odmiany – usługa NTP jest aktywna, za to nieaktywna jest sama synchronizacja…

Na szczęście to można zmienić za pomocą jednego polecenia, które ustawi nam ponownie już ustawioną strefę czasową:

sudo timedatectl set-timezone Europe/Warsaw

Po tym poleceniu jeszcze raz sprawdzam status usługi NTP:

patryk@rpi01 ~ $ timedatectl status
Local time: Sat 2015-12-05 10:33:21 CET
Universal time: Sat 2015-12-05 09:33:21 UTC
RTC time: n/a
Time zone: Europe/Warsaw (CET, +0100)
NTP enabled: yes
NTP synchronized: yes

Jest dobrze…

Wyłączenie testowe

Ale by i tym razem zbyt pochopnie nie uznać, że wszystko jest OK, postanowiłem testowo wyłączyć Raspberry Pi na kilkanaście minut, i sprawdzić czas w systemie po ponownym uruchomieniu:

patryk@rpi01 ~ $ date
Sat 5 Dec 11:15:52 CET 2015

Na szczęście tym razem czas w systemie zgadzał się z czasem na zegarze obok… :-)