Як правильно налаштувати timezone і NTP на Linux сервері

Для багатьох адміністраторів налаштування часу на сервері здається чимось неважливим, дрібницею, якою можна зайнятися пізніше. Часто її й справді відкладають на потім, але рівно до того моменту, поки резервна копія бази даних «раптом» не отримає дату з майбутнього, SSL-сертифікат не почне вважатися простроченим, а cron не запустить завдання зовсім не тоді, коли від нього цього чекали.

Такі проблеми можуть довго залишатися непомітними. Сервер працює тижнями або місяцями без жодної скарги, а потім одне неправильне налаштування часу тягне за собою помилки в логах, збої моніторингу, дивну поведінку додатків і питання, на які з першого погляду складно знайти відповідь. Особливо важкими можуть бути наслідки в інфраструктурі, де є кілька серверів, контейнери, бази даних і різні сервіси, які постійно обмінюються даними між собою.

Плутанини додає ще й інший момент, що Timezone і NTP часто сприймають як щось одне. Насправді це абсолютно різні механізми, кожен з яких відповідає за свою частину роботи з часом.

У цій статті ми розберемося в цих поняттях, а також навчимося налаштовувати час на своєму Linux-сервері.

 

 

 

 

Різниця між Timezone і NTP

Якщо спростити до однієї фрази, то timezone відповідає за те, як сервер показує час, а NTP - за те, наскільки цей час відповідає дійсності.

Можна уявити собі звичайний настінний годинник. Часовий пояс визначає, що саме буде на циферблаті для конкретного регіону, а NTP періодично перевіряє цей годинник за точним еталоном і коригує його, якщо він починає поспішати або відставати.

У Linux системний час зберігається в UTC. Користувач, додатки та журнали подій вже отримують час з урахуванням обраного часового поясу. Такий підхід позбавляє від безлічі проблем, особливо коли один сервер працює з користувачами з різних країн або знаходиться в дата-центрі за тисячі кілометрів від власника проєкту.

Звідси й з’являються два окремі кроки налаштування.

• Вибрати правильний часовий пояс;
• Налаштувати автоматичну синхронізацію часу через NTP.

 

Пропускати будь-який з них - не дуже хороша ідея, оскільки, наприклад, сервер може показувати правильний місцевий час і при цьому відставати на кілька хвилин. А буває й навпаки, коли годинник йде абсолютно точно, але всі події в логах записуються в чужому часовому поясі. І те, і інше рано чи пізно створює описані вище проблеми.

Тепер, коли ми визначилися з цими поняттями, давайте по черзі розберемося з кожним із них на реальних прикладах.

 

 

 

 

Як перевірити поточний часовий пояс

У більшості сучасних дистрибутивів Linux для роботи з часом використовується systemd. Перевірити поточні налаштування можна однією командою:

timedatectl

 

Серед іншої інформації ви побачите рядок із часовим поясом, наприклад:

Time zone: Europe/Kyiv (EEST, +0300)

 

Якщо сервер показує UTC або інший регіон замість потрібного, то часовий пояс краще виправити відразу, інакше потім доведеться розбиратися, чому записи в логах, завдання cron і повідомлення надходять із дивним часом.

 

Переглянути повний список доступних часових поясів можна так:

timedatectl list-timezones

 

Список досить великий, тому зручніше шукати потрібний регіон через фільтр:

timedatectl list-timezones | grep Kyiv

 

Для зміни часового поясу достатньо виконати таку команду:

timedatectl set-timezone Europe/Kyiv

 

Після виконання цієї команди перезавантаження сервера не потрібно, оскільки новий часовий пояс застосовується одразу, і більшість сервісів починають використовувати його без додаткових дій. Іноді корисно перевірити час ще раз за допомогою timedatectl, просто щоб переконатися, що налаштування дійсно збереглося.

 

 

 

 

Як перевірити поточний час і синхронізацію

Після налаштування часового поясу варто переконатися в тому, що сервер показує правильний час і дійсно синхронізує його із зовнішніми джерелами. Найчастіше саме тут виявляються проблеми, які до цього залишалися непомітними.

Перевірити поточний системний час можна командою:

date

 

Для отримання повної інформації про налаштування часу зручніше використовувати іншу команду:

timedatectl status

 

У виведенні timedatectl є кілька рядків, на які зазвичай звертають увагу в першу чергу:

Time zone
System clock synchronized
NTP service

За ними можна швидко зрозуміти загальну картину, а саме який часовий пояс використовується, чи синхронізований системний годинник і чи запущена взагалі служба NTP.

Іноді трапляється така ситуація, коли сервер показує правильний локальний час, але рядок System clock synchronized має значення no. Це може збити з пантелику адміністратора, адже зовні все здається справним. А насправді годинник вже поступово починає відхилятися від точного часу і через кілька тижнів така дрібниця цілком здатна перетворитися на одну з описаних вище проблем.

 

Якщо ваш сервер фізичний, виділений або ваша віртуальна машина має доступ до апаратного годинника хост-машини, то їхній стан можна переглянути окремо командою:

hwclock --show

 

Апаратний годинник (RTC або Real-Time Clock) - це окремий таймер на материнській платі, який продовжує працювати навіть після вимкнення системи. Під час завантаження Linux отримує початковий час саме з RTC, а потім вже синхронізує його через NTP.

Варто пам'ятати, що комп'ютерний годинник не є абсолютно точним. Будь-який апаратний таймер рано чи пізно починає поступово відхилятися від еталонного часу. Іноді мова йде про частки секунди на добу, а іноді й про кілька секунд або хвилин на місяць.

Найчастіше для VPS це питання не є актуальним, оскільки апаратний годинник прихований за шаром гіпервізора, однак на виділених серверах і домашніх серверах неправильний апаратний годинник іноді стає причиною збоїв.

 

 

 

 

Як працює NTP

За точність часу на сервері відповідає NTP (Network Time Protocol).

 

Цей протокол періодично порівнює локальний годинник з еталонними джерелами точного часу в Інтернеті та за необхідності коригує його.

Джерелами можуть бути спеціалізовані сервери в університетах, дата-центрах, наукових організаціях або публічних пулах часу. Сервер звертається до них через певні інтервали, обчислює розбіжність і вносить поправки.

Цікаво, що сучасні NTP-клієнти зазвичай не переносять час стрибком на кілька секунд вперед або назад. Такий підхід міг би спричинити проблеми у додатках, базах даних та різних сервісах. Натомість система плавно прискорює або уповільнює хід годинника доти, доки розбіжність не зникне.

Для більшості проектів підходять публічні джерела часу, наприклад:

pool.ntp.org
0.pool.ntp.org
1.pool.ntp.org
2.pool.ntp.org

 

Також часто використовують і альтернативні сервери від популярних компаній Google або CloudFlare:

time.google.com
time.cloudflare.com

 

Існують сервіси, де можна підібрати для себе сервер точного часу за країнами та континентами.

Втім, у більшості сучасних дистрибутивів список серверів уже налаштований за замовчуванням, а його ручна зміна зазвичай потрібна лише в корпоративних мережах або специфічних інфраструктурах.

Що стосується самого NTP-клієнта, то сьогодні найчастіше зустрічаються два варіанти: systemd-timesyncd та chrony.

systemd-timesyncd входить до складу systemd, практично не вимагає налаштування і добре підходить для звичайних VPS, адже синхронізація часу працює за замовчуванням після встановлення ОС, як то кажуть - «з коробки».

Chronyвважається більш функціональним рішенням, оскільки він швидше виходить на точний час після запуску, краще переносить нестабільні мережеві з'єднання, вміє працювати в ролі власного NTP-сервера та надає більше можливостей для налаштування. Тому його часто використовують на навантажених серверах, у віртуалізованих середовищах та складних інфраструктурах.

Для нашого випадку зі звичайним VPS різниця між цими інструментами рідко буває помітна неозброєним оком. Тому якщо ваш сервер обслуговує простий сайт, інтернет-магазин, корпоративну пошту або кілька простих контейнерів, то цілком достатньо стандартного systemd-timesyncd. А ось коли потрібна максимально точна синхронізація або йдеться про велику кількість серверів, тоді частіше вибирають Chrony.

 

 

 

 

Встановлення Chrony та перевірка синхронізації

Оскільки ми пишемо вичерпну статтю на тему налаштування часу та його синхронізації в системах Linux, то давайте для повноти картини швидко пробіжимося по тому, як встановити та використовувати Chrony на сервері Linux.

В Ubuntu та Debian встановлення виглядає так:

apt update
apt install chrony -y

 

У AlmaLinux, Rocky Linux та CentOS:

dnf install chrony -y

 

Після встановлення службу потрібно запустити та додати до автозавантаження:

systemctl enable --now chronyd

 

Через кілька секунд можна перевірити стан синхронізації:

chronyc tracking

 

У виведеній інформації буде вказано, з яким джерелом часу працює сервер, наскільки великі відхилення та чи синхронізований годинник на даний момент.

 

Для діагностики знадобляться ще кілька команд.

Список використовуваних серверів часу:

chronyc sources

 

Детальна статистика по кожному джерелу:

chronyc sourcestats

 

Загальна інформація про стан синхронізації:

chronyc tracking

Ці команди часто допомагають швидше, ніж перегляд логів. Особливо коли потрібно зрозуміти, чи отримує сервер актуальний час, яке джерело обрано як основне і чи немає помітної розбіжності з еталонним годинником. Знову ж таки, на VPS таке трапляється рідко, але після міграції віртуальної машини, проблем із мережею або тривалого простою перевірка зайвою точно не буде.

 

 

 

 

Як Docker працює з часом

Окремо варто поговорити про налаштування часу в такій великій частині інфраструктурних рішень, як Docker, адже з ним у багатьох виникає плутанина. Усередині контейнера дійсно є своє відображення часу, але власного годинника у нього немає.

За замовчуванням контейнер використовує системний час хостової машини, тому якщо на сервері неправильно налаштований часовий пояс або не працює синхронізація через NTP, ті ж проблеми з’являться і всередині контейнерів.

Перевірити поточний час можна безпосередньо:

docker exec -it container_name date

 

Зазвичай результат збігатиметься з часом на хості. Винятки трапляються рідко і пов'язані, в основному, зі специфічними налаштуваннями контейнера або підміною файлів часової зони.

Через це спроби виправити час усередині окремого контейнера найчастіше не мають сенсу, і причину варто шукати на рівні самого сервера. Достатньо налаштувати timezone та NTP на хостовій системі, після чого зміни автоматично торкнуться всіх контейнерів.

Особливо це актуально у великих мікросервісних інфраструктурах, де працює безліч контейнерів, кожен з яких відповідає за свою ділянку роботи. Один контейнер записує логи, інший обробляє черги, третій працює з базою даних. І якщо час між ними розходиться хоча б на кілька хвилин, то пошук причин помилок швидко перетворюється на справжній кошмар. А коли мова йде про CI/CD, кластери Docker або системи моніторингу, то правильний час стає вже не просто зручністю, а технічною необхідністю.

 

 

 

 

Підіб'ємо підсумки

Отже, налаштування часу на Linux-сервері зазвичай займає кілька хвилин, тому ні в якому разі не варто нехтувати цим під час первинного налаштування сервера. Проблема в тому, що якщо цього не зробити, то наслідки помилок можуть проявитися через тижні або навіть місяці, коли зв'язок між причиною та симптомами вже не буде очевидним, що призведе до тривалої локалізації причини проблем та її усунення.

Однією з найпоширеніших помилок у роботі з часом є спроба виправити неточний час на сервері простою зміною часового поясу.

 

Логіка начебто зрозуміла: сервер показує неправильний час, отже, потрібно змінити часовий пояс. Але насправді часовий пояс впливає лише на відображення часу. Тому, якщо системний годинник випереджає або відстає, налаштування часового поясу нічого не виправить.

Ще одна поширена помилка - це налаштування декількох NTP-клієнтів на одному сервері. Це може статися після оновлень, міграцій або експериментів адміністратора, коли одночасно запускаються, наприклад, chronyd, ntpd та systemd-timesyncd. Кожен із них намагається керувати часом за своїми правилами. А в результаті синхронізація може бути нестабільною, що найчастіше виявляється у стрибках часу.

Трапляється й простіша помилка. Або навіть не помилка, а недбалість, коли NTP-клієнт встановлюють, службу запускають, а перевірити статус синхронізації забувають або не вважають за необхідне це робити. А потім з'ясовується, що сервер так і не зміг підключитися до джерел часу через проблеми з мережею, брандмауером або неправильною конфігурацією.

Тому завжди після основного налаштування корисно витратити ще хвилину на фінальну перевірку:

• обрано правильний часовий пояс;
• працює автоматична синхронізація часу;
• у виведенні timedatectl відображається System clock synchronized: yes;
• апаратний годинник (якщо він використовується) показує правильний час;
• системний час відповідає реальному часу.

 

Власне, на цьому й усе.

 

 

 

 

Часті запитання

Чи потрібно використовувати UTC на сервері?

Для міжнародних проєктів UTC часто зручніше, а для невеликих серверів можна використовувати й локальний часовий пояс.

 

Що краще для VPS - Chrony чи systemd-timesyncd?

Для більшості VPS достатньо systemd-timesyncd. Ну а якщо потрібна більш точна синхронізація та розширена діагностика, тоді обирають Chrony.

 

Чи може неправильний час спричинити проблеми з SSL-сертифікатами?

Так. При серйозній розбіжності часу сертифікат може визначатися як недійсний або прострочений.

 

Чи потрібно встановлювати NTP всередині Docker-контейнерів?

Зазвичай ні, оскільки контейнери використовують час хост-системи.

 

Як часто сервер синхронізує час через NTP?

Автоматично та регулярно. Точна періодичність залежить від використовуваного NTP-клієнта.

 

Що буде, якщо NTP-сервери тимчасово недоступні?

Сервер продовжить використовувати поточний час, а після відновлення з'єднання синхронізація поновиться автоматично.

 

 

 

 

Висновок

Налаштування часу на сервері займає буквально кілька хвилин, але зате воно здатне позбавити вас від тривалого пошуку помилок у майбутньому.

Правильний timezone допомагає нормально читати логи та розуміти, коли саме відбулася та чи інша подія. А NTP стежить за точністю системного часу. Якщо все налаштовано коректно, тоді завдання cron запускаються вчасно, SSL-сертифікати працюють без сюрпризів, а журнали подій не перетворюються на головоломку.

Тому після встановлення Linux-сервера час краще налаштувати відразу. Це така ж базова процедура, як налаштування SSH-доступу, брандмауера або резервного копіювання.