В полночь с 30 июня на 1 июля с целью синхронизации с астрономическим временем Земли эталонные мировые атомарные часы были приостановлены на одну секунду. иными словами в последней минуте оказалось 61 секунда, а на некоторых часах можно было наблюдать волшебное время "23:59:60". Подобный шаг привёл к непредвиденному коллапсу многих приложений и сервисов. Проблема была вызвана зацикливанием из-за неготовности обработать появление лишней секунды, в большинстве систем, на которых проявилась проблема, была настроена синхронизация точного времени по NTP.
В итоге, испытывали проблемы с работой некоторые сайты (в том числе (http://www.buzzfeed.com/summeranne/y2k-20-how-a-second-broug...) Reddit, LinkedIn и Mozilla), наблюдалось (https://bugzilla.mozilla.org/show_bug.cgi?id=769972) массовое зависание серверных приложений (в основном приложения работающие в Java VM, такие как Hadoop и Cassandra), начинала (http://blog.mozilla.org/it/2012/06/30/mysql-and-the-leap-sec.../) съедать все процессорные ресурсы СУБД MySQL, отключились VPN-туннели на базе OpеnVPN, зависали (http://serverfault.com/questions/403732/anyone-else-experien...) Linux-серверы с вручную собранным ядром.
В большинстве случаев администраторы были вынуждены перезапустить зависшие серверы. Тем не менее, для стабилизации некоторых приложений достаточно было вручную выставить корректное время через команду "date `date +"%m%d%H%M%C%y.%S"`" для некоторых систем мог дополнительное потребоваться останов ntpd на время выполнения данной команды и перезапуск пожирающих CPU приложений. Интересно, что в системе отслеживания ошибок Red Hat информация о возможной проблеме была опубликована (https://bugzilla.redhat.com/show_bug.cgi?id=479765) ещё в 2009 году и исправлена (http://rhn.redhat.com/errata/RHSA-2009-1243.html) в RHEL 5.4 (дополнительно было опубликовано уведомление (https://access.redhat.com/knowledge/articles/15145), что RHEL не подвержен проблеме). В марте в ядре Linux была выявлена и исправлена (https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2....) проблема с зависанием при появлении лишней секунды на некоторых системах с таймером высокого разрешения.
При этом, добавление лишней секунды для синхронизации времени с периодом вращения земли производится не в первый раз, прошлое прибавление состоялось 31 декабря 2008 года и обошлось без глобальных проблем. В прошлом году внимание к проблеме также пыталась поднять (http://googleblog.blogspot.com/2011/09/time-technology-and-l...) компания Google, поделившись своим методом ухода от проблемы - разбиение лишней секунды на большой интервал корректировки, с прибавлением каждый раз по миллисекунде.URL: http://www.wired.com/wiredenterprise/2012/07/leap-second-bug.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=34234
Не было печали - время поменяли.
На серверах под 40 нагрузка прыгнула. Без перезагрузки пофиксить можно
http://blog.vpsville.ru/blog/pro/47.html
Мой рутер на OpenWRT отлично пережил это. NTP включен, время синхронизируется. Что не так было с теми серверами? Видно какие-то левые патчи использовали при сборке системы. Ванильное ядро отлично переносит такие непредвиденные ситуации.
> какие-то левые патчинапример Java?
> Что не так было с теми серверами?у тебя на роутере стоит дебиан?
>> Что не так было с теми серверами?
> у тебя на роутере стоит дебиан?у меня стоит дебиан и ntpd, ничего не висло.
>> Что не так было с теми серверами?
> у тебя на роутере стоит дебиан?OpenWRT
> Мой рутер на OpenWRT отлично пережил это. NTP включен, время синхронизируется. Что
> не так было с теми серверами? Видно какие-то левые патчи использовали
> при сборке системы. Ванильное ядро отлично переносит такие непредвиденные ситуации.колом встал sles 11 + oracle jdk 6u33 + jboss 6.1
сплошной левак
Хм... заюзать man of middle и выдать неправильный формат даты и все, конец света обеспечен.
> man of middleЭто брат Славы КПСС, что ли? :)
Поймал на одном умеренно старом альте (5.1/branch с "неродным" ядром -- проверял ovz#1880, помнится), на t6/branch и Server 4.0 не наблюдается.
"31 июня, лунный день"... )))
Бдлжать, у меня повисли 2 сервачка, там mysql+гребанная java+openfire :(
Lenny + MySQL + Openfire = полет нормальный.
Фрибсд проблеме не подвержена.
> Фрибсд проблеме не подвержена.не гони - я с ней "чудно" провел выходные...
Ну, не знаю... У меня Фряхи с Джавой, Мускулем и OpenVPN даже не заметили лишней секунды. Хотя судя по новости должны были три раза рухнуть с треском. Видимо, у тебя были проблемы не с ОС, а с приложением каким-нибудь.
> Ну, не знаю... У меня Фряхи с Джавой, Мускулем и OpenVPN даже
> не заметили лишней секунды. Хотя судя по новости должны были три
> раза рухнуть с треском. Видимо, у тебя были проблемы не с
> ОС, а с приложением каким-нибудь.Значит, у вас просто синхронизация времени не настроена. Поэтому про лишнюю секунду они просто не в курсе.
> Значит, у вас просто синхронизация времени не настроена. Поэтому про лишнюю секунду
> они просто не в курсе.meson:/# ntpdc -p
remote local st poll reach delay offset disp
=======================================================================
*s01.ru.it2go.eu aaa.bbb.ccc.ddd 2 512 377 0.00308 -0.000211 0.11493
=webhost2.mitht. aaa.bbb.ccc.ddd 2 512 377 0.06589 -0.013095 0.09659
=ground.corbina. aaa.bbb.ccc.ddd 2 512 377 0.00288 -0.000652 0.10597
=gw-sovam.gamma. aaa.bbb.ccc.ddd 2 512 377 0.04759 -0.022310 0.08604
=ns.mipt.ru aaa.bbb.ccc.ddd 2 512 377 0.00238 0.000054 0.10603
=dl120g7.naviteh aaa.bbb.ccc.ddd 2 512 336 0.03073 0.000332 0.10858
=cello.corbina.n aaa.bbb.ccc.ddd 2 512 377 0.00281 -0.001764 0.09143
> Фрибсд проблеме не подвержена.Подвержена, еще как.
У меня из 150-ти серверов ни один не повис, везде openntpd.
> У меня из 150-ти серверов ни один не повис, везде openntpd.У нас из 200 линуксовых серверов с ntpd не повис ни один. Однако, в новости написано, что Linux вполне себе подвержен. Т.е. "а вот у нас" - это не показатель.
>> Мде, на че только линуксоиды не идут лишь бы свой линукс отбелить, а другие системы обосpать.
> Линуксоиды лишь передразнивают фряшников, зело преуспевших в этом деле.ох... как же мы любим стрелки метать. ну почитайте вы коменты в новостях о линухе и фре, в новостях лунухов обычно происходит стандартная дискуссия о предмете новости, в новости о фре набегает куча линуксойдов и начинает орать что фря не нужна, и вот такие люди еще учат пальцем в носу ковыряться. Вы лучше сходите вот сюда: https://www.opennet.ru/opennews/art.shtml?num=34217 и объясните, что там с 2.6.32 происходит, это еще покруче данных глюков времени в линухе.
> сюда: https://www.opennet.ru/opennews/art.shtml?num=34217 и объясните, что там с 2.6.32
> происходит, это еще покруче данных глюков времени в линухе.Сразу после того как вы объясните что за фигня происходит с фрибсд 6-й версии :). Нет, если кто хочет некрофилить - он в своем праве. Ну и пусть некрофилит.
>> Фрибсд проблеме не подвержена.
> Подвержена, еще как.Конкретный случай в студию - или буду считать, что врёте не краснея.
А ещё - сделайте RTFS. Внимательно.
> Конкретный случай в студию - или буду считать, что врёте не краснея.Бзди не настолько распространены на серверах, чтобы стать героями подобных новостей :)
>> Конкретный случай в студию - или буду считать, что врёте не краснея.
> Бзди не настолько распространены на серверах, чтобы стать героями подобных новостей :)Ваш слив засчитан.
>> Конкретный случай в студию - или буду считать, что врёте не краснея.
> Бзди не настолько распространены на серверах, чтобы стать героями подобных новостей :)Из 20 примерно серверо под Free покинул ровно при переходе времени покинул один ( Freebsd + freeradius + Mysql ), 2 его собрата остались живы ( все сервера синрохянтся по ntpd, правда покинул 7.4, два других - 8.x )
> Из 20 примерно серверо под Free покинул ровно при
> переходе времени покинул один ( Freebsd + freeradius + MysqlПолучается что там баг тоже есть? Ну значит прав тот оратор про новости.
Чистая правда. 17 серверов с кучей сервисов - никаких проблем не было.
> Фрибсд проблеме не подвержена.хз, у меня на 8.2 amd64 p9 никаких проблем не было
Ну когда, когда программисты перестануть считать что в сутках всегда 24 часа, в минуте 60 секунд и минута не может длиться больше часа?
Ну когда уже люди придумают нормальную, желательно десятичную или, там,16-ричную, шкалу времени без таких сюрпризов... Я думал, что хотя бы на UTC можно положиться, что оно не ориентируется на астрономическое время в отличие от GMT, ан нет...
это невозможно и всё из-за особенностей вращения Земли. Секунды то подгоняют под "солнечное" время
Есть шкала времени TAI, привязанная только к атомным часам. Никаких скачков в этой шкале нет. UTC основана на TAI и всегда отличается от TAI на целое число секунд. Во многих технических приложениях TAI была бы удобнее, но увы — применяют эту дурацкую неравномерную UTC, которая корректируется под астрономическое время.
UTC то как раз равномерна. Но периодически "скачет" за UT1.
> Ну когда уже люди придумают нормальную, желательно десятичнуюОбратитесь к авторам месяца термидора. Вот только выверты их мозгов похуже будут.
Ну когда уже люди начнут измерять временные интервалы, оперируя вызовом gettimeofday() ?-)На него точно можно положиться. "Time went backwards" -- внештатная ситуация, отображаемая ядром в логах. А вот какие-то там сутки/часы/минуты -- это всё не для компьютеров.
> На него точно можно положиться. "Time went backwards" -- внештатная ситуация,Фига себе - время по NTP синкать уже стало нештатным?
Ну когда уже люди придумают механизм компенсации замедления вращения Земли, без таких сюрпризов!
Здесь была глупость.
Это всё скайнет-провокатор, за 2000 мстит!
> Это всё скайнет-провокатор, за 2000 мстит!Это он втихушку обкатывает варианты конца света. Кажется нашел довольно удачный вариант :)
даа. Тут один человек весь день жалуется что у него часы назад в винде идут. Да, зависания нет, правильного времени тоже нет)) Виндовс7 надежные технологии
Вся ява на серверах поплыла... Очень много съедается именно Soft IRQ
jboss на шапке нормально пережил
Красиво... Ну хоть ядерного апокалипсеца не случилось.
А чего это они в июне время корректируют? Для этого же всегда февраль использовался...
> А чего это они в июне время корректируют? Для этого же всегда
> февраль использовался...захотелось чего-то новенького:)
> Для этого же всегда февраль использовался...Это как?
Гуглить по ключевым словам "високосный", "год", "февраль", "29 дней"
Сейчас не про високосный день речь идёт, а о високосной секунде. Иногда её в год ни разу не добавляют, а иногда по два раза. Если потребуется, то и по три и по четыре раза в год будет високосная секунда. Она никак не поддаётся прогнозированию и добавляется по факту, когда астрономические наблюдения выявят расхождение между атомными часами и астрономическими.
Не чаще двух раз в год ее могут добавлять: в последний день полугодия ( правда могут и не одну секунду, но это крайне маловероятно).
> Гуглить по ключевым словам "високосный", "год", "февраль", "29 дней"Это другая коррекция времени //Кэп :)
> А чего это они в июне время корректируют? Для этого же всегда
> февраль использовался...Никогда для leap second не использовался февраль.
Чаще всего декабрь, иногда июнь.
> О зависании Linux-серверов в основном сообщают пользователи систем с
> необновлённым ванильным ядром, собранным вручную, а также пользователи штатных
> пакетов с Linux ядрами 2.6.32, 3.1 и 3.2 из состава Debian GNU/Linux.Бедные некрофилы...
Зато редхату пиар :)
нет, скорее антипиар дебиану
> нет, скорее антипиар дебиануМеньше будут понтоваться стабильностью некромансии, вполне заслуженно. Если кто пытается быть святее папы римского - логично что он при удобном случае наступает на грабли.
У нас уместнее с Гундяевым сравнивать :) А на счет "святости" Пап - это к Л. Таксилю :)
> нет, скорее антипиар дебиануОшибку пофиксили и там, и там. Разница была в основном в культуре админов. В частности, их отношении к обновлениям.
> Ошибку пофиксили и там, и там.Ее поправили в менее допотопном ядре. Но поскольку с ним кой-кто все никак не может выкатить релиз... система по дефолту - с граблями. Вообще, не комильфо что в релизе лежит система с такими багами.
бугага, ну надо ж так жидко )))я считаю что все должны были быть в курсе о возможности периодической смены времени на некоторое значение, должна была быть ПРЕДУСМОТРЕНА возможность корректной спонтанной смены времени на уровне ядра, процессы могли быть на секунду штатно приостановлены
все можно было оттестировать в виртуальной машине
это вообще-то говоря серьезный баг и не иначе, где обновление разосланное всем за неделю?
а отнимать ты как секунду будешь жидкий бугагашешка ?
Ниразу ещё не отнимали.
> Ниразу ещё не отнимали.ЛПП: ntp вполне может скрутить время хоть на минуту назад если часы спешат.
Еслиб твоя наркоманская святость читала новость с лева на право, и с верху-вниз, то б она увидела, что проблему пофиксили до этой траблы, на серверах стояли старые ядра.
> Еслиб твоя наркоманская святость читала новость с лева на право, и с
> верху-вниз, то б она увидела, что проблему пофиксили до этой траблы,
> на серверах стояли старые ядра.Там не в ядрах дело было. А именно в приложениях/сервсах. Писали о пожирании процессорного времени сервисам ntpd. Никак не могли переварить 61-ю секунду...
> смены времени на некоторое значение, должна была быть ПРЕДУСМОТРЕНА возможность корректной
> спонтанной смены времени на уровне ядра,А если мне NTP время на полгода пофиксит после сбоя системных часов - у меня процессы полгода должны висеть? Не, спасибо, себе такое счастье оставьте :)
>> смены времени на некоторое значение, должна была быть ПРЕДУСМОТРЕНА возможность корректной
>> спонтанной смены времени на уровне ядра,
> А если мне NTP время на полгода пофиксит после сбоя системных часов
> - у меня процессы полгода должны висеть? Не, спасибо, себе такое
> счастье оставьте :)дело в 61-й секунде. может, правильнее было 51-ю продублировать?
Debian stable, почти все обновления стоят, NTP, ведро 2.6.32-5-686, mysql из репов. Полёт нормальный.
# dmesg | grep "leap second";Если этого нет, значит ты одмин лоКалХоста.
[1253631.905150] Clock: inserting leap second 23:59:60 UTCядро 3.2 из дебиана, никаких зависаний нет, крутится там в том числе и жабка.
> ядро 3.2 из дебианаБэкпортовое чтоли?
> # dmesg | grep "leap second";
> Если этого нет, значит ты одмин лоКалХоста.# dmesg| grep leap
[3672177.907314] Clock: inserting leap second 23:59:60 UTC
# uname -r
2.6.32-5-486
А может просто демон NTP не используется? :) Мне просто хватает синхронизации клиентом каждые пол часа. И не на 0-й минуте, да :) На всякий случай...
А почему раньше не зависали? Часы на секунду раз в неск лет переводят.
Зависали в 2008, но не у всех.
а у меня все работает !
"Не думай о секундах с высока..." (с)
свысока
Спасибо, добрый Анонимус.
> начинала съедать все процессорные ресурсы СУБД MySQLбгг.. вот этому гогну то какая пичаль до лишней секунды. Цивилизация клоунов.
> бгг.. вот этому гогну то какая пичаль до лишней секунды. Цивилизация клоунов.Судя по вашему коменту - натурально, клоунов :(
Интересно, как крон это воспринимает?
Допустим, у меня по крону задание в "0 0 * * *" (00:00).
Как крон отнесется к переводу часов на секунду вперед в 23:59:59?
Вдруг он 23:59:60 посчитает, как 00:00 и два раза подряд запустит одно и то же задание.Может быть, лучше переводить не в 23:59:59 последнего числа, а первого числа в 12:30:59?
А то ожидается, что поменяется минута, поменяется час, поменяются сутки, поменяется месяц...
А этого не происходит.
Потому что ещё не 2012.07.01 00:00:00, а все ещё 2012.06.30 23:59:60.
> Может быть, лучшеНикогда не ставь задач любым планировщикам на границах разделения, даже свидания не назначай.
Юзай простые числа, а лучше Фибоначчи - компьютеры и люди их ненавидят. :)
яростно плюсую за изложение основ
На самом деле все даже проще.Если ты хочешь сломать программу - выйди за общепринятые границы. Сделать вместо 59 секунды максимум 60-ю? Отличная идея. Аналогично - если у вас в сутках по 25 часов, хреново будет вашим программам :)
>> Может быть, лучше
> Никогда не ставь задач любым планировщикам на границах разделения, даже свидания не
> назначай.
> Юзай простые числа, а лучше Фибоначчи - компьютеры и люди их ненавидят.
> :)Если вы с такой уверенностью это пишите, как общеизвестные истины, что же операторы эталонных часов так лоханулись?
>>> Может быть, лучше
>> Никогда не ставь задач любым планировщикам на границах разделения, даже свидания не
>> назначай.
>> Юзай простые числа, а лучше Фибоначчи - компьютеры и люди их ненавидят.
>> :)
> Если вы с такой уверенностью это пишите, как общеизвестные истины, что же
> операторы эталонных часов так лоханулись?К алгоритмам это не имеет отоношения, это психология.
Ну вот удобно человекам запоминать и оперировать цифрами с нулём на конеце.Коллапсы можно видеть каждый день на месте свиданий в ваших городах.
В 20:00, м. Охотный ряд, тусует 100-200 человеков, в 20:15 - всех сдуло.
В 9:00 утра, все как по свистку выходят из дома, бесит аж... :)
Ну вот не понимаю..., крыша чтоль съедет в 8:57 иль в 9:03 выйдти.Чуть сложнее ситуация, событие (B) в 21:00, но до этого должно произойти (А),
межу А и В максимум 35 минут, то есть событие (А) можно назначить на 20:25.Угадайте с трех раз на какое время назначут событие А в реальности? :)
Думаю ответа будет два, 20:15 и 20:00, при этом все забыли условие - (максимум 35 минут)---
А ещё у людей есть какой-то дибильный закон притяжения.
Туеву хучу раз наблюдал катаясь на велосипеде, иль в
каких-то похожих ситуациях.Ситуация: Дорога в парке, метра 2 шириной, идет парочка,
я еду сзади, где-то метров 50 до них, спереди, тоже. кто-то идёт или едет...
И обязательно все три объекта встретятся в одной точке - рядом с этой парочкой.
Такая же фигня с 4-мя объектами - двумя медленными двигающиеся навстречу друг-другу
и два встречных быстрых объекта. Всё в одну кучу.Романтический дибилизм, - в кино, да и в жизни тоже, - двое влюблённых бегут
навстречу друг другу, торможение практически до нуля начинается метров за 5
до точки перечсечения! Спрашивается, накуя, если тормозной путь всего метр,
могли бы ещё метра 4 пробежать :) Не, ну как вариант - встретиться по касательной,
что при взаимодействии получился векторый ротор.
> К алгоритмам это не имеет отоношения, это психология.
> Ну вот удобно человекам запоминать и оперировать цифрами с нулём на конеце.Ну да, но потом должен включаться мозг.
А в вопросах атомных часов мозг должен включиться три раза.
Даже бекапы в 00:00 стараются не делать, понимая интуитивно (или на больном опыте).
> Думаю ответа будет два, 20:15 и 20:00, при этом все забыли условие
> - (максимум 35 минут)Вы забыли 20:30 =)
20:45 - тоже вариант ("поторопимся, успеем")> и два встречных быстрых объекта. Всё в одну кучу.
Тоже постоянно встречаю.
Но тут следует иметь в виду, что один раз разбежаться удобнее, чем сначала пропустить тех, потом объехать этих.
Сделать все в одну транзакцию, или тот же NCQ )
гЫ :)
[16072496.895773] Clock: inserting leap second 23:59:60 UTCТак мужуки,... судя по этому патчу https://bugzilla.redhat.com/attachment.cgi?id=330223&action=...
это есть часть исправления. Выше приведен dmesg из Debian 6.0.5 (2.6.32-5-amd64)
Откуда заключаю, что этот фикс в ядре присутствует.
> это есть часть исправления. Выше приведен dmesg из Debian 6.0.5 (2.6.32-5-amd64)
> Откуда заключаю, что этот фикс в ядре присутствует.Видимо, исправление пришло в ходе послерелизного обновления. А некоторые "админы" такими обновлениями принципиально пренебрегают ("там же только исправления безопасности, ну кто нас ломать будет").
Давайте будем откровенными, в новости неправильно подана информация, в результате таких словесных пассов очернён ntp.
Правильнее было бы назвать вещи своими именами: global timers в java, mysql и пр. фигурантах не имеют собственной системы контроля временных тиков и соответственно подвержены уязвимостям через банальное изменение времени.
> в результате таких словесных пассов очернён ntp.1. NTP должон был отловить 61 секунду и повторить запрос или лучше забить до следующей синхронизации.
2. Если NTP не отловил - glibc должно офигеть от 61 секунды, проигнорировать и вернуть нужный код.
3. Ядро - по аналогии с glibc.
4. Если дошло до BIOS (RTC), то там ничего не возвращают, а просто игнорируют.
1. ntp просто синхронизирует время, и честно вставил одну секунду и заметь, не 61, а ещё одну 59, что есть даже в твоём логе.
2. glibc всё равно какое время в системе и как криво и как часто оно меняется, иначе бы любая наколенка работающая со временем имела проблемы при его изменении
3. тоже самое что 2
4. в железе вообще "человеческое время" не играет никакой роли.Вот тут вменяемое приложение вообще не должно было прореагировать, потому что свои таймеры на каждую внутреннюю функцию должны использоваться. Что-то типа:
нормальная программа: mainloop(timer, function(bla))
кривая программа: import java.util.Timer именно который сидит на system.datetimeНа пальцах:
бармен всегда следит чтобы перед клиентом стояла полный бокал
жалоба клиента: бармен мне поставил 2 бокала подряд -мне пришлось нажраться и бармен казёл
> 1. ntp просто синхронизирует время, и честно вставил одну секунду и заметь,
> не 61, а ещё одну 59, что есть даже в твоём
> логе.Извиняюсь, невнимательность. Да, ntp неверно сделал, но по факту проблемы только у конкретного списка приложений
NTP всё правильно сделал, баг в ядре, в реализации adjtimex.
В общем, после драки кулаками не машут, фронт работы всем ясен
- тестирование, тестирование, и ещё раз тестирование.
> - тестирование, тестирование, и ещё раз тестирование.Спасибо, Капитан! :)
> Давайте будем откровенными, в новости неправильно подана информация, в результате таких
> словесных пассов очернён ntp.Не ntp, а ядерный счёт времени.
> Правильнее было бы назвать вещи своими именами: global timers в java, mysql
> и пр. фигурантах не имеют собственной системы контроля временных тиков и
> соответственно подвержены уязвимостям через банальное изменение времени.Неправда ваша.
Проблема сохранялась и при перезапуске этих приложений: запущенные с нуля после leap second они жрали процессор точно так же.
Лечилась только прямой установкой времени (например, date -s `date`), вызовом adjtimex(), рестартом ntpd и аналогичными мерами. Ну или ребутом целиком сервера, что банально.
Никакой простой рывочный сдвиг времени никогда к таким эффектам не приводил.У нас саппорт имел бессонную ночь перезапуская всех и испробовал все варианты, так что я знаю, что говорю.
На CentOS 6 MySQL'ю плохеет слегка - жрёт 100% одно ядра, крутится в спинлоках. Рестарт MySQL'я не помогает. Единственная радость - на отзывчивость системы и вообще сервис не влияет никак - т.е. время всё-таки отдаёт при надобности.Лечится так: service ntpd stop ; service ntpdate start ; service ntpd start
После этого ядро прочёсывается, и более не доставляет.
на оракловой сборке RH ночью, пишут, были большие проблемы с сервисами
на 5 или 6 - пока не скажу, но работы в поддержки было полно
> на оракловой сборке RH ночью, пишут, были большие проблемы с сервисами
> на 5 или 6 - пока не скажу, но работы в поддержки
> было полноМолодец оракл, хорошо ядро собрал. Энтерпрайзненько.
> на оракловой сборке RH ночью, пишут, были большие проблемы с сервисами
> на 5 или 6 - пока не скажу, но работы в поддержки
> было полноRHEL 5 не пострадал, 6 - пострадал в полный рост
SL6 с ntpd
F16 с chronydничто не повисло, но везде mysqld и chrome начали жрать цпу
а знал ли кто об этом заранее? Кроме того тут в новости совсем ничего не написано про виндовые сервера (а они-то как это все "переварили"? Сколько их существует всего? Есть ли те, которые по-прежнему работают на "винде2000")
Как в свое время была "переварена" проблема 2000 года? (по тв об этом тогда много показывали, про то с секундой- нет. А когда будет такая же корректировка опять?)
Незнаю как на win 2000 server, но на win 2003 и win 2008 server полет нормальный, что на x86 так и x64, как впрочем и на ubuntu 10.04. Железки с линуксом тоже не выеживались.
ядро 2.6.31 - 7x24x365
ядро 3.2.6 - 7x24
Трудностей не возникло.
ЧЯДНТ? Где и что я упустил?
MySQL, Java сервисы присутствуют или новость читал по диагонали?
это даже круче чем уязвимые курсоры!!! ))))
> это даже круче чем уязвимые курсоры!!! ))))Это DoS, а то remote code exec с предельными привилегиями. Встаньте с головы на ноги.
> это даже круче чем уязвимые курсоры!!! ))))Да ну, чего там круче? Курсоры позволяли ремотно кернельный код вдуть. А тут какие-то полторы программы повисло. Фи.
Благодаря Opennet-у, наша ж№па спасена! Сутки всем офисом ломали голову, отчего на всех серверах LA под 200, причём и под linsux и под windoze. :)
Отлично, спишу очередное зависание своего компьютера на это событие, а не на 10-летнее железо.
Debian Squeeze упал, а Wheezy выжил..
Я так и не понял, проблема в ядре или в самих серверных приложениях?
Разрабы соотв. приложений видимо ничего не слышали про uptime и пили мало йаду. ;)
Вот теперь понятно, чего у меня сервачок Майнкрафтовский начал жрать проц как бешенный и лагать через раз. Перезапуск не помогал - вплоть до физического ребута компа. А я уж на что только не грешил. Да уж, следить за такими вещами надоть.
> Вот теперь понятно, чего у меня сервачок Майнкрафтовский начал жрать проц как
> бешенный и лагать через раз. Перезапуск не помогал - вплоть до
> физического ребута компа. А я уж на что только не грешил.
> Да уж, следить за такими вещами надоть.Вряд ли напрямую из-за этого. На Хабре уже разобрали, там была ссылка в базу знанй M$. Так да - они забивают на эту секнду...
> В полночь с 30 июня на 1 июля с целью синхронизации с астрономическим временем > Земли эталонные мировые атомные часы были приостановлены на одну секундуНе надо обманывать людей. Атомная шкала времени равномерная и атомные стандарты никогда не останавливаются. Как вы себе это представляете: рубильник на стандарте частоты? Почитайте определение шкалы TAI.
Другое дело, что добавили секунду к шкале UTC.
Короче, прежде, чем писать новость, неплохо было бы прокачать теорию
Fedora, CentOS, RedHat + MySQL + Java application Все нормольно работает ни каких глюков не было что за прогон ...
чорт!а я то дума чего опеннмс la под 100 и более выдавал....буквально час назад коллега сервак ребутнул) наверное помогло