Проблемы настройки ntpd
Пять дней красноглазия за настройками сервера прошли незаметно. Генту блистал. Не было ни одного пакета, который бы просто поставился и заработал как в презренных виндах - все, абсолютно все приходилось допиливать, вычитывать, искать документацию, находя что-то от 2004г. и пытаясь применить на современные реалии. Ну, на то это и Генту - слабые не выживают еще на этапе установки системы. Но вот квест был почти завершен. Оставалась малость - настроить ntpd. Ничто не предвещало беды, ntpd выглядел безобидным и неопасным. Немного насторожила надпись, что время сдвинулось на какое-то многозначное число секунд, но date показал правильную дату.
На следующий день сервер загрузился и радостно выдал, что теперь он неизвестный хост, что рутовый раздел - readonly, а остальных разделов нет и в помине. "Бонусный квест", - догадался я.
Вооруженный самой передовой техникой гугления, быстро нашел команду mount -o remount,rw / и начал выбивать дурь из заартачившейся машинки.
Все, абсолютно все выглядело нормальным. fsck не нашел ошибок на рутовом разделе. Все вручную отлично запускалось и пристойно отрабатывало. Перезагрузка и .... и снова readonly.
Я не буду приводить тут весь путь - он описан у многих психологов, скажем так, что пройдя все стадии типа отрицания, гнева, торга, депрессии и принятия, я нашел причину поломки: паскудный ntpd сдвинул реальное время на сентябрь (!), хотя отображался март (!!). Все разделы получили записи в сентябре, fsck нашел их неприемлемыми и поправил, кроме /dev/sdb. Почему-то система посчитала ниже своего достоинства уведомить меня о проблемах с /dev/sdb или поправить все самостоятельно, а просто прекращала ремаунт. Увидеть ошибку оказалось возможным лишь вручную запустив /etc/init.d/root start. Но оставим это на черной, как черная дыра, совести разработчиков.
Собственно вопрос: при каких условиях ntpd может выкинуть такой странный фокус?
Конфиг у него практически дефолтный, отрабатывало все нормально. Даже сейчас, запустив его я получил:
# ntpd -q -g
ntpd: time set +0.145754s
Кто-нибудь сталкивался с подобным?
- Для комментирования войдите или зарегистрируйтесь
е было ни одного пакета,
это у Вас карма такая ( скорее всего из-за экономии мышления )
BIOS time == ntpd time ?
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
желательно увидеть конфиги
желательно увидеть конфиги собственно ntpd, а также всякие hwclock и все, относящееся к таймзоне. ntpq -p тоже не помешает.
# date Fri Apr 12 17:25:40
# date
Fri Apr 12 17:25:40 MSK 2013
# ntpq -p
ntpq: read: Connection refused
/etc/timezone
# ls -la /etc/localtime /usr/share/zoneinfo/Europe/Moscow
-rw-r--r-- 1 root root 1464 Apr 2 17:42 /etc/localtime
-rw-r--r-- 2 root root 1464 Mar 21 06:55 /usr/share/zoneinfo/Europe/Moscow
/etc/conf.d/hwclock
/etc/conf.d/ntpd
/etc/conf.d/ntp-client
(IP выбран через netselect -s 3 0.gentoo.pool.ntp.org)
1. The net-misc/ntpd comes
1. The net-misc/ntpd comes with a set of options and tools useful to perform a quick and dirty clock synchronization.
такую синхронизацию можно и нужно избегать — особенно в плане перевода часов «назад». некоторые службы могут умирать при этом.
2. Туда же: Warning: Folks used to ntpdate command and to the ntp-client service should read the official document about its deprecation.
3.
clock="local"— имеется дуалбут с windows?4. Рекомендуется использовать ntpd в качестве постоянно запущенного демона. Он будет переводить время (по необходимости) постепенно.
5. Множество полезного по всем этим вопросам можно почерпнуть тут
Спасибо за развернутый ответ.
Спасибо за развернутый ответ. Как раз по вики я его и ставил. Оттуда же и взял команду ntpd -q -g
Дуалбута с виндой нет, local остался потому как выставлено время было в local, а не в UTC. Стоит переставить в UTC?
На сервере - однозначно!На
На сервере - однозначно!
На десктопе в отсутствие дуала с Виндами - тоже...
Меньше проблем будет.
.
У меня dualboot, и стоит UTC, все нормально. Оффтопу можно в реестре сказать, чтобы он работал с UTC. Хотя есть мнение, что это может привести к каким-то проблемам, никаких проблем на самом деле вроде бы нет.
"реальное время на сентябрь
"реальное время на сентябрь (!), хотя отображался март (!!)". ntpd тут и рядом не стоял. Он устанавливает время от начала Unix-эпохи, тобишь число секунд от первого января 1970 года. Если число секунд от первого января 1970 года "реально" соответствует сентябрю, а "отображался" март, это значит, что в вашем zoneinfo было прописано смещение на -многомного часов.
Поскольку формат zoneinfo такого не позволяет в принципе, т.е. ошибка исключена (и если бы даже нет - то о такой ошибке уже бы весь интернет жужжал), то у меня есть только три варианта:
1. Происки инопланетян.
2. Происки иллюминатов.
3. Происки американцев.
Я голосую за третий вариант.
Есть четвертый вариант:
Есть четвертый вариант: Кровавоглазый бог линуксов ненавидит презренных разработчиков (в лице меня) за их многолетний снобизм по отношению к сисадминам и заставляет каждое элементарное действие отвоевывать с боем.
Если серьезно, то думаю, что я ухитрился найти какой-то особо кривой сервер синхронизации.
Цитата: Если серьезно, то
На мой взгляд тут достаточно достоверный список ntp серверов.
Зачем вообще использовать IP в этой ситуации не проще ли использовать доменное имя?
Не надо бояться, что жизнь закончится - надо бояться, что она не начнется!
netselect вернул IP,
netselect вернул IP, использование его описано в хендбуке и в конфигурационном файле ntpd, так что тут я просто сделал все по инструкции. Возможно стоило оставить просто 0.gentoo.pool.ntp.org
Мой сервер находится в пуле
Мой сервер находится в пуле pool.ntp.org, в зоне ru (ru.pool.ntp.org). При обращении к домену ru.pool.ntp.org при определенных условиях выпадает IP моего сервера. Мой сервер находится в домене ru.pool.ntp.org до тех пор пока время выдаваемое им не превышает заданной погрешности. Время выдаваемое моим сервером постоянно проверяется корневым сервером pool.ntp.org и в случае большой погрешности или недоступности, IP адрес моего сервера исключается из домена ru.pool.ntp.org. Более того каждый сервер пула имеет рейтинг (score) который опять же определяется по по результатам опроса корневым сервером pool.ntp.org, все серверы чей рейтинг меньше 10 не допускаются в соответствующий домен, машины с большим рейтингом чаще отвечают на запросы времени клиентов. Я думаю что по аналогичной схеме работают и другие пулы точного времени.
К чему я все это говорю... netselect выдал Вам IP адрес сервера с валидным временем именно в ДАННЫЙ момент, через 15 минут этот сервер может начать выдавать левое время, его удалят из домена, а вы так и будете получать левое время, потому что обращаетесь к конкретному IP. Именно такая ситуация и могла с вами произойти.
С каких это пор разработчики просто делают все по инструкции не задумываясь!?! Мне казалось, что разработчику - религия не позволяет делать все просто по инструкции.
Не надо бояться, что жизнь закончится - надо бояться, что она не начнется!
> Именно такая ситуация и
Ясно. Вернусь к пулу, похоже, что это надежнее.
В тех местах, где есть смысл - да. Мне нетрудно написать даже сложный конфиг к iptables - там есть хоть какая-то минимальная и простенькая логика в обработке данных. Я сам правлю кривые sh-скрипты из кривых рецептов. Но разбираться в процессе установки какой-нибудь примитивной службы с опцией типа ENABLE_XPEH_TAM_LIB8573841="om4nmd729+" - не стану. Сделаю по хендбуку/рецепту, а при наличии свободного времени - прочитаю подробнее и переконфигурирую. Иначе бы я застрял еще на чтении описания всех 3800 опций ядра, 400 ключей use, пары сотен нужных пакетов (в рамках использованных ключей хотя бы).
Если нужна надежность, то
Если нужна надежность, то лучше использовать несколько пулов, например:
Более 7 не рекомендуется, менее 4 тоже... Стоит отметить, что в приведенном выше примере могут попадаться серверы с разным значением stratum.
Если нужна точность, то GPS
Не надо бояться, что жизнь закончится - надо бояться, что она не начнется!