alibek Posted March 16, 2019 · Report post Есть сервер Dell PowerEdge 2950 под управлением RHEL4. На сервере видимо дефектные часы — за месяц они отстают на десяток минут, за год на часы. На сервере в кроне периодически запускается ntpdate и подводит часы — так что на работающей системе с часами проблем нет. Но при этом часы в BIOS не обновляются и отставание накапливается. И когда сервер перезагружается, то системные часы (до выполнения ntpdate) сильно отстают. Вот здесь вроде бы описывается эта проблема: https://access.redhat.com/solutions/2649 Но без подписки показывается только шапка. Никто с таким не сталкивался, как можно обновить системные часы после ntpdate? P.S. hwclock -s не срабатывает. Share this post Link to post Share on other sites
zwoelf Posted March 16, 2019 · Report post @reboot ntpdate Share this post Link to post Share on other sites
jffulcrum Posted March 16, 2019 · Report post Насколько я помню, с RHEL4 у сервера в принципе было полно проблем совместимости, DELL даже выпускала 200-страничный документ на этот счет. В моем хозяйстве так и не удалось победить некоторые из них, и оба сервера в итоге ушли под FreeBSD. Глюки с часами тоже были в списке проблем. Share this post Link to post Share on other sites
alibek Posted March 16, 2019 · Report post Жаль. Но кстати правду говорят, что правильно заданный вопрос уже содержит в себе половину ответа. Упомянув hwclock я на всякий случай решил еще раз перечитать man. Ключ -s или --hctosys я понимал как: аппаратные часы привести системным (синхронизировать с системными). А оказывается, что это ровно наоборот. А вот ключ -w (значение системных часов присвоить аппаратным) вроде бы сработал, понаблюдаю пару дней. Сам ntpdate аппаратные часы по прежнему не обновляет, но если hwclock будет работать, то этого достаточно. Share this post Link to post Share on other sites
st_re Posted March 16, 2019 · Report post А он при штатном /sbin/shutdown разве ниоткуда не дергается ? Помнится в подобной ситуации прблемы были только при аварийных перезагрузках по питанию (даже не в в4, а еще какаойто не энтерпрайз рхн. 5 чтоли.). после штатного шатдауна или ребута всегда время было +- ОК. Вопрос с hwclock и кроном уже стали после очередного броска питания после дотсаточно долгого аптайма начали изучать. при чем для перового раза сделали просто ntpdate и shutdown и в кмосе было уже все хорошо.. Хотя кончено очень давно было :) А насчет совместимости. РХЕЛ4 с ДЕЛЛ... ух у нас на делах разных было очень не мало, как и 5 и 6 позже. Проблем с бегущими часами в кмосе тоно небыло. (они вобще или есть или нет и от ОС то мало зависят. разве что та всегда на любое изменение системного времени всегда дергает обьновление и там) Share this post Link to post Share on other sites
jffulcrum Posted March 16, 2019 · Report post @alibek Порывшись в закромах памяти, вспомнил, что проблема с таймером была с HPET и был какой-то патч ядра конкретно для RHEL год в 2009-м (нам не помог). Share this post Link to post Share on other sites
alibek Posted March 16, 2019 · Report post 25 минут назад, st_re сказал: А он при штатном /sbin/shutdown разве ниоткуда не дергается ? У меня нештатное было, ИБП разрядился. Но я думаю, что лучше подстраховаться и продублировать его после ntpdate. Share this post Link to post Share on other sites
zhenya` Posted March 16, 2019 · Report post ntpdate хреновый метод для подвода часов. используйте ntpd. Share this post Link to post Share on other sites
alibek Posted March 16, 2019 · Report post На древнем RHEL4 ставить софт? ntpdate вполне достаточно. Расхождения маленькие и проблем не вызывают. К тому же основная проблема была не в системных часах, а аппаратных. Share this post Link to post Share on other sites
zhenya` Posted March 16, 2019 · Report post На eos оси тож опасно сидеть. Share this post Link to post Share on other sites
alibek Posted March 16, 2019 · Report post Ну там риски другие, если ничего не трогать, то ещё долго будет работать. Доступа снаружи нет, сеть изолированная, постороннего софта тоже нет. Собственно за все время работы только однажды пришлось залезать в потроха, когда часовые пояса обновлялись. Share this post Link to post Share on other sites
Ivan_83 Posted March 18, 2019 · Report post В 16.03.2019 в 12:26, jffulcrum сказал: Порывшись в закромах памяти, вспомнил, что проблема с таймером была с HPET и был какой-то патч ядра конкретно для RHEL год в 2009-м (нам не помог). HPET к часам не имеет никакого отношения совсем. Он используется для таймеров, которые используются для переключения задачь и программных таймеров. Часы всегда тикают на отдельной микрухе и отдельном "часовом" кварце на 32768 Гц, у них и питание от батарейки, это единственное для чего она нынче нужна. В 16.03.2019 в 19:11, zhenya` сказал: ntpdate хреновый метод для подвода часов. используйте ntpd. opentpd ещё лучше. В 16.03.2019 в 19:36, alibek сказал: Ну там риски другие, если ничего не трогать, то ещё долго будет работать. Доступа снаружи нет, сеть изолированная, постороннего софта тоже нет. Собственно за все время работы только однажды пришлось залезать в потроха, когда часовые пояса обновлялись. Если это такая проблема - купи туда GPS/Глонасс приёмник и с него забирай точное время и раздавай его в той сетке. Share this post Link to post Share on other sites
snvoronkov Posted March 18, 2019 · Report post 3 минуты назад, Ivan_83 сказал: opentpd ещё лучше. Во времена RHEL4 был в зачаточном состоянии. Не работает толком. Share this post Link to post Share on other sites
jffulcrum Posted March 19, 2019 · Report post @Ivan_83 20 часов назад, Ivan_83 сказал: HPET к часам не имеет никакого отношения совсем. В самой ОС часы после загрузки идут как раз от таймеров, потому как обращения к RTC из защищенного режима - это дорого. Было сложно, но я нашел тот баг: Цитата A bug in timer_interrupt() may have caused the system time to move up to two days or more into the future, or to be delayed for several minutes. This bug only affected Intel 64 and AMD64 systems that have the High Precision Event Timer (HPET) enabled in the BIOS, and could have caused problems for applications that require timing to be accurate. Мне, правда, тогда не помогло, и судят по трекеру, был еще патч в 2011 году на те же грабли, не дождался. Share this post Link to post Share on other sites
Ivan_83 Posted March 19, 2019 · Report post 3 часа назад, jffulcrum сказал: В самой ОС часы после загрузки идут как раз от таймеров, потому как обращения к RTC из защищенного режима - это дорого. Там поди память смаплена и приложения просто читают. Для меня большая загадка как можно так накосячить с HPET чтобы всё стало хуже. Share this post Link to post Share on other sites
