alibek Опубликовано 16 марта, 2019 · Жалоба Есть сервер Dell PowerEdge 2950 под управлением RHEL4. На сервере видимо дефектные часы — за месяц они отстают на десяток минут, за год на часы. На сервере в кроне периодически запускается ntpdate и подводит часы — так что на работающей системе с часами проблем нет. Но при этом часы в BIOS не обновляются и отставание накапливается. И когда сервер перезагружается, то системные часы (до выполнения ntpdate) сильно отстают. Вот здесь вроде бы описывается эта проблема: https://access.redhat.com/solutions/2649 Но без подписки показывается только шапка. Никто с таким не сталкивался, как можно обновить системные часы после ntpdate? P.S. hwclock -s не срабатывает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zwoelf Опубликовано 16 марта, 2019 · Жалоба @reboot ntpdate Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 16 марта, 2019 · Жалоба Насколько я помню, с RHEL4 у сервера в принципе было полно проблем совместимости, DELL даже выпускала 200-страничный документ на этот счет. В моем хозяйстве так и не удалось победить некоторые из них, и оба сервера в итоге ушли под FreeBSD. Глюки с часами тоже были в списке проблем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 16 марта, 2019 · Жалоба Жаль. Но кстати правду говорят, что правильно заданный вопрос уже содержит в себе половину ответа. Упомянув hwclock я на всякий случай решил еще раз перечитать man. Ключ -s или --hctosys я понимал как: аппаратные часы привести системным (синхронизировать с системными). А оказывается, что это ровно наоборот. А вот ключ -w (значение системных часов присвоить аппаратным) вроде бы сработал, понаблюдаю пару дней. Сам ntpdate аппаратные часы по прежнему не обновляет, но если hwclock будет работать, то этого достаточно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 16 марта, 2019 · Жалоба А он при штатном /sbin/shutdown разве ниоткуда не дергается ? Помнится в подобной ситуации прблемы были только при аварийных перезагрузках по питанию (даже не в в4, а еще какаойто не энтерпрайз рхн. 5 чтоли.). после штатного шатдауна или ребута всегда время было +- ОК. Вопрос с hwclock и кроном уже стали после очередного броска питания после дотсаточно долгого аптайма начали изучать. при чем для перового раза сделали просто ntpdate и shutdown и в кмосе было уже все хорошо.. Хотя кончено очень давно было :) А насчет совместимости. РХЕЛ4 с ДЕЛЛ... ух у нас на делах разных было очень не мало, как и 5 и 6 позже. Проблем с бегущими часами в кмосе тоно небыло. (они вобще или есть или нет и от ОС то мало зависят. разве что та всегда на любое изменение системного времени всегда дергает обьновление и там) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 16 марта, 2019 · Жалоба @alibek Порывшись в закромах памяти, вспомнил, что проблема с таймером была с HPET и был какой-то патч ядра конкретно для RHEL год в 2009-м (нам не помог). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 16 марта, 2019 · Жалоба 25 минут назад, st_re сказал: А он при штатном /sbin/shutdown разве ниоткуда не дергается ? У меня нештатное было, ИБП разрядился. Но я думаю, что лучше подстраховаться и продублировать его после ntpdate. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zhenya` Опубликовано 16 марта, 2019 · Жалоба ntpdate хреновый метод для подвода часов. используйте ntpd. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 16 марта, 2019 · Жалоба На древнем RHEL4 ставить софт? ntpdate вполне достаточно. Расхождения маленькие и проблем не вызывают. К тому же основная проблема была не в системных часах, а аппаратных. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zhenya` Опубликовано 16 марта, 2019 · Жалоба На eos оси тож опасно сидеть. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 16 марта, 2019 · Жалоба Ну там риски другие, если ничего не трогать, то ещё долго будет работать. Доступа снаружи нет, сеть изолированная, постороннего софта тоже нет. Собственно за все время работы только однажды пришлось залезать в потроха, когда часовые пояса обновлялись. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 18 марта, 2019 · Жалоба В 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/Глонасс приёмник и с него забирай точное время и раздавай его в той сетке. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snvoronkov Опубликовано 18 марта, 2019 · Жалоба 3 минуты назад, Ivan_83 сказал: opentpd ещё лучше. Во времена RHEL4 был в зачаточном состоянии. Не работает толком. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 19 марта, 2019 · Жалоба @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 году на те же грабли, не дождался. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 19 марта, 2019 · Жалоба 3 часа назад, jffulcrum сказал: В самой ОС часы после загрузки идут как раз от таймеров, потому как обращения к RTC из защищенного режима - это дорого. Там поди память смаплена и приложения просто читают. Для меня большая загадка как можно так накосячить с HPET чтобы всё стало хуже. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...