Zegary w systemie Linux

Istnieją dwa typy zegarów daty i czasu:

Zegar sprzętowy: zegar będący niezależnym urządzeniem sprzętowym, ze swoim własnym zasilaniem (baterią, kondensatorem itp.), który działa gdy komputer jest wyłączony, a nawet gdy jest odłączony od zasilania.

W przypadku systemów kompatybilnych z ISA, zegar jest częścią standardu ISA. Program kontrolujący może go odczytać lub ustawić jedynie do pełnej sekundy, ale może wykryć moment przeskoczenia sekundy, więc zegar ten ma praktycznie nieskończoną precyzję.

Zegar ten jest często nazywany: zegarem sprzętowym, zegarem czasu rzeczywistego, RTC (od ang. "real time clock"), zegarem BIOS lub zegarem CMOS. Jądro Linux nazywa go też zegarem trwałym ("persistent clock").

Niektóre systemy inne niż ISA mogą mieć kilka zegarów czasu rzeczywistego, z których tylko jeden ma własne zasilanie. Zewnętrzne układy zegara I2C lub SPI o bardzo niewielkim poborze prądu mogą być stosowane wraz ze swą baterią jako zegar sprzętowy do inicjowania funkcjonalniejszego, wbudowanego zegara czasu rzeczywistego, służącego większości innych celów.

Zegar systemowy: zegar będący częścią jądra Linux, sterowany przerwaniem czasomierza (na komputerze ISA, przerwanie czasomierza jest częścią standardu ISA). Ma znaczenie tylko w trakcie działania systemu Linux na komputerze. Czas systemowy jest liczbą sekund od 00:00:00 1 stycznia 1970 UTC (zwięźlej: liczba sekund od 1969 UTC). Czas systemowy nie jest jednak liczbą całkowitą. Ma praktycznie nieskończoną precyzję.

To czas systemowy jest czasem istotnym. Podstawowym przeznaczeniem zegara sprzętowego jest utrzymywanie czasu, gdy nie działa Linux, dzięki czemu przy rozruchu można z niego zainicjować zegar systemowy. Proszę zauważyć, że w DOS-ie, dla którego zaprojektowano standard ISA, zegar sprzętowy był jedynym zegarem czasu rzeczywistego.

Ważne jest, aby czas systemowy nie miał luk, które mogłyby nastąpić po ustawieniu go w trakcie działania systemu za pomocą programu date(1). W trakcie działania systemu, można jednak zrobić co tylko się chce z zegarem sprzętowym, a przy następnym uruchomieniu Linuksa, system włączy się z czasem dostosowanym z zegara sprzętowego. Uwaga: obecnie nie jest to możliwe na większości systemów, ze względu na wywoływanie hwclock --systohc przy zamykaniu systemu.

Strefa czasowa jądra Linux jest ustawiana przez hwclock. Nie należy jednać dać się zwieść - niemal nic nie zwraca uwagi na strefę czasową jądra. Programy, które wymagają wiedzy o strefie czasowej (może np. chcą wyświetlić czas lokalny użytkownikowi) niemal zawsze korzystają z tradycyjniejszej metody określenia strefy czasowej: używają zmiennej środowiskowej TZ lub pliku /etc/localtime, zgodnie z wytłumaczeniem w podręczniku systemowym tzset(3). Jednakże niektóre programy i peryferyjne części jądra Linux, takie jak systemy plików, mimo to korzystają z wartości strefy czasowej jądra. Przykładem jest system plików vfat. Jeśli wartość strefy czasowej jądra jest nieprawidłowa, system plików vfat zgłosi i ustawi nieprawidłowe znaczniki czasu w plikach. Innym przykładem jest "tryb 11-minutowy" NTP jądra. Jeśli wartość strefy czasowej jądra i/lub zmienna persistent_clock_is_local są nieprawidłowe, zegar sprzętowy zostanie ustawiony nieprawidłowo przez "tryb 11-minutowy". Zob. opis w rozdziale Automatyczna synchronizacja zegara sprzętowego przez jądro poniżej.

hwclock ustawi wartość strefy czasowej jądra wskazaną przez TZ lub /etc/localtime przy użyciu opcji --hctosys lub --systz.

Wartość strefy czasowej jądra składa się tak naprawdę z dwóch części: 1) pola tz_minuteswest wskazującego o jak wiele minut czasu lokalnego (bez uwzględnienia czasu letniego) czas lokalny jest późniejszy od czasu UTC oraz 2) pola tz_dsttime wskazującego stosowany obecnie, lokalnie typ konwencji czasu letniego (DST). To drugie pole nie jest stosowane w Linuksie i zawsze wynosi zero. Zob. też settimeofday(2).

Metody dostępu do zegara sprzętowego

hwclock stosuje różne metody pobierania i ustawiania wartości zegara sprzętowego. Najzwyklejszą jest wykonanie wejścia/wyjścia do pliku specjalnego urządzenia rtc, który powinien być sterowany przez sterownik urządzenia rtc. Ponadto systemy linuksowe korzystające ze szkieletu rtc z udev, mogą obsługiwać wiele zegarów sprzętowych. Może to spowodować konieczność przesłonięcia domyślnego urządzenia rtc, podając inne opcją --rtc.

Ta metoda nie jest jednak zawsze dostępna, ponieważ starsze systemy nie posiadają sterownika rtc. Na tych systemach metoda dostępu do zegara sprzętowego zależy od sprzętu systemowego.

W systemach kompatybilnych z ISA, hwclock może uzyskać bezpośredni dostęp do rejestrów "pamięci CMOS" składających się na zegar, dokonując wejścia/wyjścia na portach 0x70 i 0x71. Dokonuje tego za pomocą faktycznych instrukcji wejścia/wyjścia, zatem wymaga efektywnego identyfikatora superużytkownika. Metodę tę można zastosować podając opcję --directisa.

Jest to kiepski sposób na dostęp do zegara, z tych wszystkich powodów, dla których programy z przestrzeni użytkownika nie są generalnie dopuszczane do wykonywania bezpośredniego wejścia/wyjścia i wyłączania przerwań. hwclock udostępnia go do testowania, rozwiązywania problemów oraz ponieważ może być to jedyna metoda dostępna na systemach ISA nieposiadających działającego sterownika urządzenia rtc.

Funkcja korekcji

Zegar sprzętowy nie jest zwykle zbyt dokładny. Jednak wiele z tej niedokładności jest całkowicie przewidywalna - zyskuje on lub traci tę samą liczbę sekund każdego dnia. Nazywa się to dryfem systematycznym. Funkcja --adjust programu hwclock pozwala stosować korekcje dryfu systematycznego do zegara sprzętowego.

Działa to tak: hwclock utrzymuje plik, /etc/adjtime, zawierający pewne informacje historyczne. Jest on nazywany plikiem adjtime.

Załóżmy, że zaczynamy bez pliku adjtime. Wydajemy polecenie hwclock --set, aby ustawić zegar sprzętowy na faktyczny czas aktualny. hwclock tworzy plik adjtime zapisując w nim czas bieżący, jako ostatni moment kalibracji zegara. Pięć dni później, zegar zyskał 10 sekund, więc wydajemy polecenie hwclock --set --update-drift, aby ustawić go na 10 sekund wstecz. hwclock aktualizuje plik adjtime, wskazując czas bieżący, jako ostatni moment kalibracji zegara i zapisując 2 sekundy na dzień jako dryf systematyczny zegara. Po 24 godzinach wydajemy polecenie hwclock --adjust. hwclock sprawdza plik adjtime i widzi, że zegar zyskuje 2 sekundy na dzień, przy braku korekty oraz że nie był korygowany dokładnie przez dzień. Odejmuje zatem 2 sekundy od zegara sprzętowego. Następnie zapisuje czas bieżący, jako ostatni moment kalibracji zegara. Po kolejnych 24 wydajemy kolejne polecenie hwclock --adjust. hwclock robi to samo: odejmuje 2 sekundy i aktualizuje plik adjtime czasem bieżącym, jako ostatnim momentem kalibracji zegara.

Po zastosowaniu opcji --update-drift wraz z --set lub --systohc, dryf systematyczny jest (ponownie) obliczany poprzez porównanie w pełni wyrównanego pod kątem dryfu czasu zegara sprzętowego oraz nowo ustawianego czasu, z czego wywodzony jest dryf 24-godzinny, w oparciu o znacznik czasowy ostatniej kalibracji w pliku adjtime. Ten zaktualizowany czynnik korekty dryfu jest następnie zapisywany w /etc/adjtime.

Ustawianie zegara sprzętowego jest obarczone niewielkim błędem, więc --adjust nie dokonuje poprawek, które są mniejsze od 1 sekundy. Później, gdy zażąda się ponownego wprowadzenia poprawki, a nagromadzony dryf osiągnie ponad 1 sekundę, --adjust dokona korekty uwzględniającej również wartości sekundy po przecinku.

hwclock --hctosys również stosuje plik danych adjtime do skompensowania wartości odczytanej z zegara sprzętowego, przed zastosowaniem jej do ustawienia zegara systemowego. Nie posiada 1-sekundowego ograniczenia --adjust i od razu skoryguje wartości dryfu poniżej jednej sekundy. Nie zmienia czasu zegara sprzętowego ani pliku adjtime. Może to wyeliminować potrzebę stosowania --adjust, chyba że inny element w systemie wymaga kompensacji zegara sprzętowego.

Plik Adjtime

Choć ze względów historycznych nazwa pliku wskazuje jedynie na kontrolę stosowanych poprawek czasu, plik zawiera również inne informacje używane przez hwclock pomiędzy wywołaniami programu.

Zawartość pliku adjtime, w ASCII, jest następująca:

Wiersz 1: Trzy liczby oddzielone odstępami: 1) dryf systematyczny w sekundach na dzień, dziesiętna liczba zmiennoprzecinkowa; 2) Wynikowa liczba sekund od 1969 UTC ostatniej korekty lub kalibracji, dziesiętna liczba całkowita; 3) zero (ze względu na kompatybilność z clock(8)) jako dziesiętna liczba zmiennoprzecinkowa.

Wiersz 2: Jedna liczba: wynikowa liczba sekund od 1969 UTC ostatniej kalibracji. Zero, jeśli nie zaszła jeszcze kalibracja, albo wiadomo, że poprzednia kalibracja jest nieprzydatna (na przykład, ponieważ od czasu tamtej kalibracji jest jasne, że zegar sprzętowy nie zawiera prawidłowego czasu). Dziesiętna liczba całkowita.

Wiersz 3: "UTC" lub "LOCAL". Wskazuje, czy zegar sprzętowy jest ustawiony na czas uniwersalny (Coordinated Universal Time) czy lokalny. Wartość tę można zawsze przesłonić opcjami wiersza poleceń hwclock.

Plik adjtime używany wcześniej przez clock(8) można stosować z programem hwclock.

Automatyczna synchronizacja zegara sprzętowego przez jądro

Trzeba wiedzieć, że istnieje inny sposób synchronizacji zegara sprzętowego stosowany w niektórych systemach. Jądro Linux posiada tryb, w którym kopiuje czas systemowy do zegara sprzętowego co 11 minut. Tryb ten jest opcją z czasu kompilacji, więc nie wszystkie jądra posiadają tę możliwość. Jest to dobry sposób stosowany, gdy zegar systemowy jest synchronizowany przez zaawansowany mechanizm, taki jak NTP (NTP to sposób synchronizacji czasu systemowego poprzez sieciowy serwer czasu lub zegar radiowy podłączony do systemu. Zob. RFC 1305).

Jeśli jądro skompilowano z opcją "trybu 11-minutowego", to będzie on aktywny gdy dyscyplina zegara jądra jest w stanie zsynchronizowanym. Wówczas bit 6 (bit ustawiany maską 0x0040) zmiennej jądra time_status jest usuwany. Ta wartość jest widoczna jako wiersz "statusu" poleceń adjtimex --print lub ntptime.

Do uzyskania stanu synchronizacji dyscypliny zegara jądra, a więc włączenia "trybu 11-minutowego" wymagany jest wpływ zewnętrzny, taki jak demon NTP. Jego wyłączenie nastąpi poprzez uruchomienie czegokolwiek ustawiającego zegar systemowy w sposób tradycyjny, w tym hwclock --hctosys. Jednak jeśli demon NTP wciąż działa, włączy on "tryb 11-minutowy" przy następnej synchronizacji zegara systemowego.

Gdy dany system działa z włączonym "trybem 11-minutowym", może zajść potrzeba umieszczenia --hctosys lub --systz w skrypcie startowym, szczególnie jeśli zegar sprzętowy skonfigurowano do działania w lokalnej skali czasowej. O ile jądro nie zostanie poinformowane o stosowanej skali czasowej zegara sprzętowego, może go zaśmiecić nieprawidłową. Jądro domyślnie stosuje UTC.

Aplikowane jest pierwsze polecenie z przestrzeni użytkownika informujące jądro o stosowanej skali czasowej zegara sprzętowego. Dzieje się to poprzez zmienną jądra persistent_clock_is_local. Jeśli --hctosys lub --systz będą pierwsze, ustawią tę zmienną zgodnie z plikiem adjtime lub odpowiednim argumentem z wiersza poleceń. Proszę zauważyć, że gdy przy stosowaniu tej funkcji skala czasowa zegara sprzętowego ulegnie zmianie, do poinformowania o tym jądra konieczne jest ponowne uruchomienie komputera.

W "trybie 11-minutowym" NTP nie należy stosować hwclock --adjust.

Wartość stulecia zegara sprzętowego ISA

Istnieje pewnego typu standard, definiujący bajt 50 pamięci CMOS na komputerze ISA jako wskazujący na stulecie. hwclock nie stosuje, ani nie ustawia tego bajtu, ponieważ niektóre komputery nie definiują go w ten sposób, a nie jest to tak naprawdę konieczne, jako że same lata stulecia powinny wystarczyć do określenia bieżącego stulecia.

Jeśli istnieje dobre zastosowanie bajtu stulecia CMOS, opiekun hwclock prosi o kontakt; wówczas może pojawić się odpowiednia opcja.

Proszę zauważyć, że ten rozdział ma znaczenie tylko przy metodzie bezpośredniego dostępu do zegara sprzętowego przez ISA ("direct ISA"). ACPI zapewnia standardowy sposób na dostęp do wartości stulecia, gdy jest to obsługiwane przez sprzęt.

Utrzymywanie czasu bez zewnętrznej synchronizacji

Niniejszy opis ma zastosowanie przy spełnieniu następujących warunków:

Niezależnie od tego, czy zapewniany jest dokładny czas dzięki demonowi NTP, sensowne jest, aby sam system utrzymywał w miarę dokładny czas wraz z datą.

Pierwszym krokiem jest zrozumienie całości zagadnienia. Istnieją dwa zupełnie oddzielne urządzenia sprzętowe działające w swoim własnym tempie i dryfujące od "prawidłowego" czasu w różny sposób. Metody oraz oprogramowanie do korekty dryfu są oddzielnego do każdego z nich. Jednak większość systemów jest skonfigurowana tak, aby wymieniać wartości pomiędzy tymi dwoma zegarami przy uruchamianiu i zamykaniu systemu. W ten sposób odchyłki czasowe każdego urządzenia są transferowane tam i z powrotem pomiędzy nimi. Jeśli spróbuje się skonfigurować korekcję dryfu tylko jednego z zegarów, dryf drugiego zostanie naddany na drugi.

Problemu przy konfiguracji korekty dryfu zegara systemowego można uniknąć po prostu nie wyłączając komputera. To oraz fakt że cała precyzja hwclock (w tym obliczanie czynników korekty dryfu) opiera się na poprawności chodu zegara systemowego, oznacza że najpierw należy skonfigurować zegar systemowy.

Dryf zegara systemowego koryguje się opcjami --tick i --frequency polecenia adjtimex(8). Opcje te działają łącznie: tick jest zgrubną korektą, a frequency zapewnia dokładne dopasowanie (systemy nieposiadające pakietu adjtimex mogą w zamian stosować ntptime -f cz-na-mln).

Niektóre dystrybucje Linuksa próbują automatycznie obliczyć dryf zegara systemowego stosując operację compare (porównania) adjtimex. Próba korekty jednego dryfującego zegara, korzystając z drugiego dryfującego zegara jako punktu odniesienia, przypomina psa próbującego złapać swój ogon. Może się co prawda skończyć sukcesem, ale będzie to poprzedzone dużym nakładem pracy i wieloma frustracjami. Taka automatyzacja może dać pewną poprawę względem braku konfiguracji, lecz nie należy spodziewać się optymalnych wyników. Lepszym sposobem ręcznej konfiguracji byłaby opcja --log programu adjtimex.

Bardziej efektywne może być proste śledzenie dryfu zegara systemowego za pomocą sntp lub date -Ins i precyzyjnego zegarka, a następnie ręczne obliczenie poprawki.

Po ustawieniu wartości tick i frequency, należy testować i poprawiać korekty, do momentu osiągnięcia dobrego chodu zegara systemowego. Więcej informacji i przykładów ilustrujących ręczne obliczanie dryfu znajduje się w podręczniku adjtimex(2).

Po poprawnym skonfigurowania zegara systemowego należy przejść do zegara sprzętowego.

Jako reguła, zimny dryf będzie zwykle działał najlepiej. Powinno mieć to do zastosowanie w przypadku komputerów działających 24/7, których czas wyłączenia zwykle ogranicza się do ponownego uruchomienia komputera. W takim przypadku czynnik korekty dryfu nie robi dużej różnicy. Jednak w rzadkich sytuacjach, gdy taki komputer jest wyłączany na dłuższy czas, zimny dryf powinien dać lepsze efekty.

Kroki służące do obliczenia zimnego dryfu:

1

2

3

4

5

6

Uwaga: jeśli krok 6 używa --systohc, to tuż wcześniej konieczne jest ustawienie prawidłowego czasu zegara systemowego (krok 6a).

Kalkulacja czynnika korekty dryfu przez hwclock jest zwykle dobrym początkiem, lecz uzyskanie optymalnych wyników zwykle będzie wymagało dostosowania, przez bezpośrednią edycję pliku /etc/adjtime. Należy kontynuować sprawdzanie i poprawianie czynnika korekty do momentu, gdy zegar sprzętowy będzie poprawnie skorygowany przy uruchomienia komputera. Aby to sprawdzić, należy najpierw upewnić się, że czas systemowy jest poprawny przed wyłączeniem, a następnie użyć sntp lub date -Ins wraz z precyzyjnym zegarkiem, natychmiast po rozruchu.

Czas lokalny (LOCAL) czy UTC

Utrzymywanie zegara sprzętowego w lokalnej skali czasu powoduje niespójności związane z czasem letnim:

Zegar sprzętowy w systemach kompatybilnych z ISA utrzymuje jedynie datę i czas, nie posiada pojęcia strefy czasowej ani czasu letniego. Z tego względu, gdy przekaże się hwclock, że działa on w czasie lokalnym, przyjmuje że jest to "poprawny" czas lokalny i nie stosuje dostosowań wobec odczytywanego z niego czasu.

Linux obsługuje zmiany czasu letniego w sposób przezroczysty tylko, gdy zegar sprzętowy jest utrzymywany w skali czasowej UTC. Jest to łatwe dla administratorów systemu, ponieważ hwclock i tak używa czasu lokalnego w swoim wyjściu oraz jako argumentu do opcji --date.

Systemy POSIX, takie jak Linux, zaprojektowano do działania z zegarem sprzętowym utrzymywanym w skali czasowej UTC. Celem zegara sprzętowego jest inicjowanie zegara systemowego, więc utrzymywanie tego pierwszego w UTC ma sens.

Linux stara się jednak radzić sobie z sytuacją, gdy zegar sprzętowy jest utrzymywany w lokalnej skali czasowej. Taki przypadek występuje głównie przy równoległym rozruchu ze starszymi wersjami MS Windows. Od Windowsa 7, klucz rejestru RealTimeIsUniversal ma działać prawidłowo, dzięki czemu zegar sprzętowy może być utrzymywany w UTC.

POSIX czy poprawność""

Dyskusja o konfiguracji daty i czasu byłaby niekompletna bez wspomnienia o strefach czasowych, opisanych głównie w podręczniku tzset(3). Obszarem, który wygląda na nieudokumentowany jest "poprawny" katalog bazy danych stref czasowych, czasem zwany tz lub zoneinfo.

Występują dwie oddzielne bazy danych w systemie zoneinfo: posix i "poprawna". "Poprawna" ("right", obecnie nazywana zoneinfo-leaps) uwzględnia sekundy przestępne, natomiast baza posix - nie. Aby używać "poprawnej" bazy danych, zegar systemowy musi być ustawiony na (UTC + sekundy przestępne), co jest odpowiednikiem (TAI - 10). Pozwala to na obliczanie dokładnej liczby sekund pomiędzy dwoma datami, które przechodzą przez epokę sekundy przestępnej. Zegar systemowy jest następnie konwertowany na prawidłowy czas cywilny, w tym UTC, poprzez stosowanie "poprawnych" plików stref czasowych, odejmując sekundy przestępne. Uwaga: ta konfiguracja jest uważana za eksperymentalną i znane są pewne problemy.

Do skonfigurowania systemu w celu stosowania wybranej bazy danych, wszystkie pliki zlokalizowane z jej katalogu należy skopiować do katalogu /usr/share/zoneinfo. Pliki nie są nigdy stosowane bezpośrednio z podkatalogów posix lub "right" np. TZ='right/Europe/Dublin'. Było to niegdyś tak często praktykowane, że projekt macierzysty przebudował systemowe drzewo plików, przesuwając podkatalogi posix i "right" poza katalog zoneinfo, do katalogów równoległych:

/usr/share/zoneinfo, /usr/share/zoneinfo-posix, /usr/share/zoneinfo-leaps

Niestety, niektóre dystrybucje Linuksa stosują na nowo stary układ plików w swych pakietach. Problem administratorów systemu w sięganiu do "poprawnego" podkatalogu wciąż zatem istnieje. W ten sposób systemowa strefa czasowa jest konfigurowana z uwzględnieniem sekund przestępnych, podczas gdy baza danych zoneinfo wciąż je wyłącza. Następnie gdy zegar światowy potrzebuje pliku strefy czasowej South_Pole albo agent poczty elektronicznej lub hwclock wymaga pliku strefy czasowej UTC, pobierają ją z katalogu /usr/share/zoneinfo , tak jak powinno się to odbywać. Pliki te jednak nie uwzględniają sekund przestępnych, ale zegar systemowy je uwzględnia, co powoduje nieprawidłowe przeliczanie czasu.

Próba mieszania i dopasowywania plików z tych oddzielnych baz danych nie powiedzie się, ponieważ każda wymaga, aby zegar systemowy korzystał z odmiennej skali czasowej. Baza danych zoneinfo musi być skonfigurowana, aby korzystać albo z bazy posix albo z "poprawnej" bazy, zgodnie z powyższym opisem, albo poprzez przypisanie ścieżki do bazy danych do zmiennej środowiskowej TZDIR.