Leap second привёл к зависанию некоторых серверов на Linux

[VolCh]

А с мускулом ни у кого проблем не наблюдалось? В первый раз видел, что процесс мускула нельзя убить.

[nitro80]

Хз, у меня 2 сервера на дебиане с пятницы не отвечают, хотя пока никто не звонил :)
Даже и не знаю что думать :)

[Gangsta]

это по-нашему! :)

[Amadeusck]

«Админ» года?

[bezgubov]

может у человека под сотню серверов, хрен ли ему в выходные напрягаться из-за парочки малонужных машин?

[stigger]

В том же треде говорят, что в приложениях на Java наблюдались схожие проблемы.

проблемы были другие — начиная с 00:00:00 01.07.2012 GMT java-процесс сразу после старта начинал жрать cpu, но при этом работал. аналогичный эффект наблюдался с ruby. лечится перезагрузкой системы.

в каких случаях возникала эта проблема мне так установить и не удалось — на RHEL5 такого не наблюдалось, RHEL6 повально вели себя как описано выше, но при этом нашлась одна система с RHEL6 которая вела себя нормально.

[timothyz]

Та же самая хрень наблюдалась с mysql

[syndicut]

Наблюдаю ту же самую проблему с java-процессами.

[Eirenliel]

Удивительно. Мы голову сломали, что произошло с сервером на Java, когда там нет совершенно никого (4 ночи-то...) и он ест абсолютно 100% CPU, хотя профилировщик говорит обратное… Ребут машины помог, ничего посреди ночи лучшего не придумали.

[coolcold]

Подтверждаю, такая же хрень, Jenkins жрёт проц.

[Akvel]

У нас все java процессы кушали проц + серверные порты с java перестали открываться. Вылечили перезагрузкой

[netto]

— Томас, ты рад, что у нас появилось 32 мая?
— Вообще-то не очень, господин барон. Первого июня мне платят жалование.

[lehha]

RHEL5/6 стоят спокойно. Ubuntu тоже не подвис.

Хотя странно — RHEL5 + mysql slave — LA 6.72…

[FreeLSD]

Подтверждаю проблему. На двух из 1000 серверов (примечательно что оба с явой) вылетела проблема.
Один помер сразу, второй достаточно популярный ресурс информационного СМИ и не можем его перегружать.
Живет под Load Average 40.

[OmIkRoNiXz]

Похоже тоже самое, вот только 2 из 8 повисли на ровном месте, один бегал как виртуалка под ESX, оба Debian Squeeze после рестарта работают как ни в чём не бывало!

[FreeLSD]

UPDATE!
Вылечили без перезагрузки, ребята!
[e-mail]# /etc/init.d/ntp stop [e-mail]# date Sun Jul 1 13:09:45 MSK 2012 [e-mail]# date `date +"%m%d%H%M%C%y.%S"` [e-mail]# date Sun Jul 1 13:09:51 MSK 2012

[FreeLSD]

После этого стартуем ntp обратно и… вуаля!

[ValdikSS]

THE WORKAROUND

Ok people, here's how I worked around it.
disabled ntp: /etc/init.d/ntp stop
created linux.brong.fastmail.fm/2012-06-30/fixtime.pl (code stolen from Marco, see blog posts in comments)
ran fixtime.pl without an argument to see that there was a leap second set
ran fixtime.pl with an argument to remove the leap second

NOTE: depends on adjtimex. I've put a copy of the squeeze adjtimex binary at linux.brong.fastmail.fm/2012-06-30/adjtimex — it will run without dependencies on a squeeze 64 bit system. If you put it in the same directory as fixtime.pl, it will be used if the system one isn't present. Obviously if you don't have squeeze 64 bit… find your own.

[FreeLSD]

you are welcome!

[dvayanu]

Линк по теме

[Xeron]

date -s "`date -u`" && service ntp restart
Отсюда blog.mozilla.org/it/2012/06/30/mysql-and-the-leap-second-high-cpu-and-the-fix/
Проверено на MySQL и Java. Помогает без рестартов сервисов/серверов.

[Porfel]

Да, помогает.
Кстати, помимо java и mysql та же самая беда с bind9 еще.

[Eirenliel]

Помогло с сервером на Java, спасибо.

[pikach00]

Так получается с виндовсом все в порядке?

[Xeron]

Подозреваю, что Windows вообще не вставляла секунду.

support.microsoft.com/kb/909614

Особо позабавило «No method exists to include a leap second explicitly for the Windows Time service when the service is working as an NTP server.»

[KaterSpieler]

Решил и БСД-сервер на работе пингануть. Все хорошо, тоже видеть ничего не вставлял.

[VolCh]

Пингануть мало. Нужно top смотреть.

[Krypt]

Секунда может по разному вставляться — есть «мягкий» переход, когда в течении минуты часы идут медленнее, чтобы небыло двух одинаковых секунд и, как следствие, факапов.

[Speedimon]

Ну вообще-то оно и логично при правильной схеме организации времени.
Есть некоторый компьютер с выходом в интернет, который синхронизируется с точным источником в интернете. На него в свою очередь нацелен контроллер домена с ролью PDC. У него уже берут время остальные контроллеры и потом финальным аккордом отдают клиентам.
При такой схеме — надо только убедиться что те точные часы в интернете знают о leap second. Остальные системы сами синхронизируются.

[Xeron]

При такой схеме точно известно, что в промежуток между двумя синхронизациями после добавления секунды время на всех хостах будет спешить на 1 секунду.

[Xeron]

Обычному пользователю, конечно, пофигу. Но некоторые сервисы, бывает, критично относятся к таким большим погрешностям.

[Xeron]

При таком подходе нельзя гарантировать, что внутри сети в пределах этих 15 минут время будет синхронизировано. Спешить на секунду все начнут в 00:00, но вот синхронизируются все в разное время, в итоге (далее идет образный пример, цифры с потолка) в 00:05 на 50% машин внутри сети время будет спешить, а на других 50% время будет точным.

Пример сервиса под носом — NTP сервер. Простите, но NTP сервер, который в течение 15 минут врет на 1 секунду — не нужен. Другой пример — распределенные вычислительные системы, где важна синхронизация и недопустимы большие скачки при ее выполнении. Различное ПО для низкоуровневой работы с GPS. Обсерватории.

[Xeron]

Или вот вам 2 примера из моей практики:
1) wiki2.dovecot.org/TimeMovedBackwards/
2) Веб-сервис с генерацией токена и проверкой времени. При такой резкой синхронизации в течение секунды все запросы с только-что сгенерированными токенами не будут обработаны из-за ошибки авторизации.

[Alukardd]

У меня проблем не наблюдалось.
Несколько серверов на Debian Squeeze. Java отсутствует как класс, зато mysql крутится на всех.
Правда служба ntp отсутствует посему проблем быть и не могёт, как я понял — время раз в час рывком offset'ится через cron и ntpdate.

[FreeLSD]

Java наиболее подвержена.
А без ntp Вы зря, время надо подкручивать.

[DLag]

Подкручивать можно и утилитой ntpdate по cron.
В данном случае это оказалось стабильнее, хотя сам метод не без проблем.

[Alukardd]

Ну проблема только одна, раз в неделю, примерно, одно из 24 суточных заданий по синхронизации не дожидается ответа от ntp-сервера и мне на почту сваливается соответствующее письмо от cron'а. Других «проблем» не наблюдаю.
У меня нету приложений которым настолько необходимо точное время что бы не хватало раз в час или даже 2 offset'нуться.

[DLag]

Проблема может быть с кривым генератором тиков.
У меня есть пара серверов в парке, на которых время за час начинает спешить на 3-4 секунды.
Если делать синхронизацию раз в час, то скачки на 3-4 секунды сильно мешают.
К тому же у нас есть задачи с требуемой точность до 50мс.
Тут обновление по cron не подойдет.
А вообще вариант более экономный к ресурсам и прозрачный для понимания.

[timothyz]

man 8 ntpdate:

Time adjustments are made by ntpdate in one of two ways. If ntpdate determines the clock is in error more than 0.5 second it will simply step the time by calling the system settimeofday() routine. If the error is less than 0.5 seconds, it will slew the time by calling the system adjtime() routine. The latter technique is less disruptive and more accurate when the error is small, and works quite well when ntpdate is run by cron every hour or two.

BTW: ntpd в ряде случаев тоже переставляет время рывком.

[ufoton]

Серваки с Ораклом тоже подвержены проблеме.

[agladysh]

Вот и Хецнер затронуло. Пишут, что саппорт переружен запросами от пользователей, у которых всё сломалось: www.hetzner-status.de/en.html#692

[Biga]

А из-за чего одна лишняя секунда вызвала такие проблемы? Насколько я понимаю, в программах обычно используется unix time, которому на эту leap second глубоко пофигу, то есть время назад не пошло, не зависло и вперёд неожиданно не прыгнуло. Из-за чего же тогда такие драматические последствия?

[agmt]

Как раз таки наоборот. Високосная секунда — отход от определения времени Unix:«количество секунд с 01.01.1970 00:00:00». Обе секунды подряд время 1 и то же. По-хорошему, хочется оторвать некоторые части тела человеку, сделавшему так. Гораздо красивее хранить значения time_t за каждые полгода (Земные). Не думаю, что размер такого файла к 2970 в менее 8к вызовет хоть какие проблемы.

[Biga]

Т.е. ntpd изменило значение unix time в системе?

[Biga]

Хм, с другой стороны, задача ntpd как раз и состоит в том, чтобы менять системное время в целях подстройки. Но тогда, не должна ли такая ситуация происходить чаще, чем раз в 5 лет, и не должны ли программы быть на это расчитаны?

[ekungurov]

Бага не в ntpd, а где-то в глубинах ядра. У меня ядро в логи вот такое написало, после чего всё и началось:

Jul 1 03:59:59 phoenix kernel: [2747214.725946] Clock: inserting leap second 23:59:60 UTC

[Biga]

Спасибо, теперь немного понятнее.

На мой взгляд, лучше бы системное время шло непрерывно, а учётом leap second занимались бы функции перевода в local time. Я думал, что так оно и было сделано, но похоже, что нет.

[relgames]

То же самое думал. Странно, почему сделано именно так.

[agmt]

Во-во. Согласен с Biga: ядру знать о високосных секундах незачем вредно. Это другой уровень. Определение Unix-time было таким красивым и естественным образом обходило проблему високосной секунды.

[burjui]

Простите уж мою дотошность, но над фразой «Обе секунды подряд время 1 и то же» я завис на полминуты, пока не понял, что она означает (перечитал раз пять, особенно сбивала с толку единица). Стоило написать проще: «Високосная секунда не учитывается в Unix time (как будто её нет): високосная секунда прошла, а Unix time не поменялось».

[xReaper]

Oracle linux ;( DEAD

[amarao]

Без указания на версию ядра звучит как «из-за отказов тормозов АВТОМОБИЛИ врезались в здание».

По моим наблюдениям все более-менее новые линуксы (включая даже 2.6.18) живут.

[FreeLSD]

Так и запишем, что Селектел ставит юзерам 2.6.18 ядро.
У нас отказы в основном на
Linux 3.2.13 #1 SMP Tue Mar 27 15:20:18 MSK 2012 x86_64 GNU/Linux

[amarao]

Вы не поверите, но в центосе 5.6 до сих пор 2.6.18. 2.6.18-308? кажись. А записывать вы можете что угодно, но только после изучения устройства RHEL/Centos.

А 3.2 у меня есть, в лаборатории, в частности — и я там никаких затруднений не заметил в связи с этим.

uname -a
Linux lab-xh4 3.2.0-3-686-pae #1 SMP Thu Jun 28 08:56:46 UTC 2012 i686 GNU/Linux
uptime
02:00:54 up 2 days, 10:29, 1 user, load average: 0.19, 0.09, 0.06

dmesg|tail

dmesg |tail
[ 24.307789] eth0: no IPv6 routers present
[ 24.750686] device xenbr0 entered promiscuous mode
[ 24.751243] device eth0 entered promiscuous mode
[ 25.123107] ip_tables: © 2000-2006 Netfilter Core Team
[ 25.289750] device eth0 left promiscuous mode
[ 25.303870] device xenbr0 left promiscuous mode
[ 25.403459] device xenbr0 entered promiscuous mode
[ 25.456223] device eth0 entered promiscuous mode
[ 27.597534] blktap_device_init: blktap device major 253
[ 27.597538] blktap_ring_init: blktap ring major: 251

[FreeLSD]

Какой же Вы невнимательный! Проблема практически не встречается
if
[ `ps aux | grep java | wc -l` -eq 1 ]
fi

2.6.18-194.32.1.el5xen — ядрышко из знаменитого репозитория Gitco на 5-й центе.

Хост-системы мы давно перекатили на 3-е ядро, он в него уже вшит и работает ми-ми-ми.

[Nrs]

java 6.24 успешно выжила (2.6.32-100.0.19.el5), а вот 6.31 на тесте (2.6.32-300.11.1.el5uek) — почти колом встал сервер, но на запросы отвечал.
применением даты и рестартом ntpd все вылечилось…
причем прикол — последнее ядро от Оракла :)

[noreply]

Сервак на OpenSUSE 12.1 — kernel 3.1.10-1.9-xen.
Сегодня упал. В логах фагурировал процесс с java.

[Fragster]

OpenSuSE Linux 3.4.3-30 x86_64 — полет нормальный

[dimazaur]

1/07 ночью все java процессы начали хавать 100% cpu
пришлось перестартовывать сервер
Ubuntu 10

[agladysh]

Вот ещё один сводный пост: landslidecoding.blogspot.co.uk/2012/07/linuxs-leap-second-deadlocks.html

[chupkb]

linux.derkeiler.com/Mailing-Lists/Kernel/2007-07/msg00714.html
lists.debian.org/debian-user/2009/01/msg00056.html

Однаго багу не один год уже. Линукс такой линукс.

[relgames]

Проблема в ядре линукса.

Вот кусок метода ntp_leap_second() из kernel/time/ntp.c (версия 3.2.0):

        write_seqlock(&xtime_lock);
        switch (time_state) {
...
        case TIME_INS:
                timekeeping_leap_insert(-1);
                time_state = TIME_OOP;
                printk(KERN_NOTICE "Clock: inserting leap second 23:59:60 UTC\n");
                hrtimer_add_expires_ns(&leap_timer, NSEC_PER_SEC);
                res = HRTIMER_RESTART;
                break;
...
        }
        write_sequnlock(&xtime_lock);

Проблема в том, что захватывается блокировка xtime_lock, и в это же время вызывается printk который вызывает klogd демон, и при некоторых условиях может возникнуть deadlock. Странно, что этот баг до сих пор не пофикшен.

lkml.org/lkml/2009/1/2/373