0,0
рейтинг
1 июля 2012 в 09:04

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

Пользователь Bron Gondwana на ServerFault отмечает, что начиная с утра 30-го июня некоторые его сервера на Debian Squeeze стали зависать, не подавая никаких признаков жизни.

С одного из серверов удалось вытащить вот такой дамп:

[3161000.864001] BUG: spinlock lockup on CPU#1, ntpd/3358
[3161000.864001] lock: ffff88083fc0d740, .magic: dead4ead, .owner: imapd/24737, .owner_cpu: 0


Остальные машины просто молча уходили в глубокую задумчивость и не возвращались.

Решением стало временное отключение ntpd на всех машинах.

Обидно, что баг был известен как минимум с 15-го марта.

Leap second day уже прошёл, поэтому детали по фиксу я не привожу, смотрите их в треде по ссылке выше. Тем не менее, кому-то эта информация может пригодиться при расследовании вчерашнего поведения машин. Тред также содержит очень подробное описание причин произошедшего.

P.S. В том же треде говорят, что в приложениях на Java наблюдались схожие проблемы.
Александр Гладыш @agladysh
карма
91,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (74)

  • +4
    А с мускулом ни у кого проблем не наблюдалось? В первый раз видел, что процесс мускула нельзя убить.
    • –5
      Хз, у меня 2 сервера на дебиане с пятницы не отвечают, хотя пока никто не звонил :)
      Даже и не знаю что думать :)
      • +9
        это по-нашему! :)
      • +22
        «Админ» года?
        • +3
          может у человека под сотню серверов, хрен ли ему в выходные напрягаться из-за парочки малонужных машин?
  • +5
    В том же треде говорят, что в приложениях на Java наблюдались схожие проблемы.

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

    в каких случаях возникала эта проблема мне так установить и не удалось — на RHEL5 такого не наблюдалось, RHEL6 повально вели себя как описано выше, но при этом нашлась одна система с RHEL6 которая вела себя нормально.
    • +2
      Та же самая хрень наблюдалась с mysql
    • 0
      Наблюдаю ту же самую проблему с java-процессами.
    • +2
      Удивительно. Мы голову сломали, что произошло с сервером на Java, когда там нет совершенно никого (4 ночи-то...) и он ест абсолютно 100% CPU, хотя профилировщик говорит обратное… Ребут машины помог, ничего посреди ночи лучшего не придумали.
    • 0
      Подтверждаю, такая же хрень, Jenkins жрёт проц.
      • 0
        У нас все java процессы кушали проц + серверные порты с java перестали открываться. Вылечили перезагрузкой
  • +53
    — Томас, ты рад, что у нас появилось 32 мая?
    — Вообще-то не очень, господин барон. Первого июня мне платят жалование.
  • 0
    RHEL5/6 стоят спокойно. Ubuntu тоже не подвис.

    Хотя странно — RHEL5 + mysql slave — LA 6.72…
  • +8
    Подтверждаю проблему. На двух из 1000 серверов (примечательно что оба с явой) вылетела проблема.
    Один помер сразу, второй достаточно популярный ресурс информационного СМИ и не можем его перегружать.
    Живет под Load Average 40.

    image
    • +1
      Похоже тоже самое, вот только 2 из 8 повисли на ровном месте, один бегал как виртуалка под ESX, оба Debian Squeeze после рестарта работают как ни в чём не бывало!
    • +23
      UPDATE!
      Вылечили без перезагрузки, ребята!
      root@srv37.vpsville.ru# /etc/init.d/ntp stop root@srv37.vpsville.ru# date Sun Jul 1 13:09:45 MSK 2012 root@srv37vpsville.ru# date `date +"%m%d%H%M%C%y.%S"` root@srv37vpsville.ru# date Sun Jul 1 13:09:51 MSK 2012
      • +3
        После этого стартуем ntp обратно и… вуаля!

        image
        • +1
          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.
      • +1
        Действительно помогло, спасибо!
        • 0
          you are welcome!
  • +1
  • +9
    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. Помогает без рестартов сервисов/серверов.
    • 0
      Да, помогает.
      Кстати, помимо java и mysql та же самая беда с bind9 еще.
    • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Помогло с сервером на Java, спасибо.
  • +4
    Так получается с виндовсом все в порядке?
    • +2
      Подозреваю, что 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.»
      • +1
        Лучше уж вообще не вставлять, чем таким образом. =)
      • 0
        Решил и БСД-сервер на работе пингануть. Все хорошо, тоже видеть ничего не вставлял.
        • 0
          Пингануть мало. Нужно top смотреть.
        • 0
          Секунда может по разному вставляться — есть «мягкий» переход, когда в течении минуты часы идут медленнее, чтобы небыло двух одинаковых секунд и, как следствие, факапов.
      • +1
        Ну вообще-то оно и логично при правильной схеме организации времени.
        Есть некоторый компьютер с выходом в интернет, который синхронизируется с точным источником в интернете. На него в свою очередь нацелен контроллер домена с ролью PDC. У него уже берут время остальные контроллеры и потом финальным аккордом отдают клиентам.
        При такой схеме — надо только убедиться что те точные часы в интернете знают о leap second. Остальные системы сами синхронизируются.
        • +1
          При такой схеме точно известно, что в промежуток между двумя синхронизациями после добавления секунды время на всех хостах будет спешить на 1 секунду.
          • 0
            Ну это конечно хуже, чем повальное зависание серверов =) Целых пятнадцать минут время будет спешить на 1 000 000 000 наносекунд.
            • 0
              Обычному пользователю, конечно, пофигу. Но некоторые сервисы, бывает, критично относятся к таким большим погрешностям.
              • 0
                Например?
              • 0
                Желательно пример сервиса которому критично, что время отличается от всемирного, при том, что в пределах сети оно синхронизировано.
                • 0
                  При таком подходе нельзя гарантировать, что внутри сети в пределах этих 15 минут время будет синхронизировано. Спешить на секунду все начнут в 00:00, но вот синхронизируются все в разное время, в итоге (далее идет образный пример, цифры с потолка) в 00:05 на 50% машин внутри сети время будет спешить, а на других 50% время будет точным.

                  Пример сервиса под носом — NTP сервер. Простите, но NTP сервер, который в течение 15 минут врет на 1 секунду — не нужен. Другой пример — распределенные вычислительные системы, где важна синхронизация и недопустимы большие скачки при ее выполнении. Различное ПО для низкоуровневой работы с GPS. Обсерватории.
                • 0
                  Или вот вам 2 примера из моей практики:
                  1) wiki2.dovecot.org/TimeMovedBackwards/
                  2) Веб-сервис с генерацией токена и проверкой времени. При такой резкой синхронизации в течение секунды все запросы с только-что сгенерированными токенами не будут обработаны из-за ошибки авторизации.
                  • 0
                    1. Проблема в софте, в том, что он не правильно отрабатывает ситуацию возврата в прошлое.
                    2. Вопрос то был не про резкую синхронизацию, а про разницу времени внутри сети и снаружи.

                    По большому счёту проблема времени не первый день существует и даже самые критичные к этому системы — безопасность прежде всего, весьма толерантно относятся к этой разнице. Тот же керберос допускает разницу до 5 минут.

                    Есть область применения, где системы должны быть очень точно синхронизированы — это разного рода кластеры и транзакционные системы. Но там речь идёт о взаимной синхронизации и точность обеспечивается куда более точная и специальными механизмами.
  • НЛО прилетело и опубликовало эту надпись здесь
  • –1
    У меня проблем не наблюдалось.
    Несколько серверов на Debian Squeeze. Java отсутствует как класс, зато mysql крутится на всех.
    Правда служба ntp отсутствует посему проблем быть и не могёт, как я понял — время раз в час рывком offset'ится через cron и ntpdate.
    • 0
      Java наиболее подвержена.
      А без ntp Вы зря, время надо подкручивать.
      • +3
        Подкручивать можно и утилитой ntpdate по cron.
        В данном случае это оказалось стабильнее, хотя сам метод не без проблем.
        • 0
          Ну проблема только одна, раз в неделю, примерно, одно из 24 суточных заданий по синхронизации не дожидается ответа от ntp-сервера и мне на почту сваливается соответствующее письмо от cron'а. Других «проблем» не наблюдаю.
          У меня нету приложений которым настолько необходимо точное время что бы не хватало раз в час или даже 2 offset'нуться.
          • 0
            Проблема может быть с кривым генератором тиков.
            У меня есть пара серверов в парке, на которых время за час начинает спешить на 3-4 секунды.
            Если делать синхронизацию раз в час, то скачки на 3-4 секунды сильно мешают.
            К тому же у нас есть задачи с требуемой точность до 50мс.
            Тут обновление по cron не подойдет.
            А вообще вариант более экономный к ресурсам и прозрачный для понимания.
          • 0
            проблема в том что ntpdate выставляет время мгновено в соответсвиии с ntp сервером
            демон же корректирует время плавно

            в первом случае, в некоторых ситуациях это может привести к пробемам в некоторых приложениях (теоретически )

            • 0
              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 в ряде случаев тоже переставляет время рывком.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Серваки с Ораклом тоже подвержены проблеме.
  • 0
    Вот и Хецнер затронуло. Пишут, что саппорт переружен запросами от пользователей, у которых всё сломалось: www.hetzner-status.de/en.html#692
  • 0
    А из-за чего одна лишняя секунда вызвала такие проблемы? Насколько я понимаю, в программах обычно используется unix time, которому на эту leap second глубоко пофигу, то есть время назад не пошло, не зависло и вперёд неожиданно не прыгнуло. Из-за чего же тогда такие драматические последствия?
    • +1
      Как раз таки наоборот. Високосная секунда — отход от определения времени Unix:«количество секунд с 01.01.1970 00:00:00». Обе секунды подряд время 1 и то же. По-хорошему, хочется оторвать некоторые части тела человеку, сделавшему так. Гораздо красивее хранить значения time_t за каждые полгода (Земные). Не думаю, что размер такого файла к 2970 в менее 8к вызовет хоть какие проблемы.
      • 0
        Т.е. ntpd изменило значение unix time в системе?
      • 0
        Хм, с другой стороны, задача ntpd как раз и состоит в том, чтобы менять системное время в целях подстройки. Но тогда, не должна ли такая ситуация происходить чаще, чем раз в 5 лет, и не должны ли программы быть на это расчитаны?
        • 0
          Бага не в ntpd, а где-то в глубинах ядра. У меня ядро в логи вот такое написало, после чего всё и началось:

          Jul 1 03:59:59 phoenix kernel: [2747214.725946] Clock: inserting leap second 23:59:60 UTC
          • +1
            Спасибо, теперь немного понятнее.

            На мой взгляд, лучше бы системное время шло непрерывно, а учётом leap second занимались бы функции перевода в local time. Я думал, что так оно и было сделано, но похоже, что нет.
            • –1
              То же самое думал. Странно, почему сделано именно так.
          • 0
            Во-во. Согласен с Biga: ядру знать о високосных секундах незачем вредно. Это другой уровень. Определение Unix-time было таким красивым и естественным образом обходило проблему високосной секунды.
      • +2
        Простите уж мою дотошность, но над фразой «Обе секунды подряд время 1 и то же» я завис на полминуты, пока не понял, что она означает (перечитал раз пять, особенно сбивала с толку единица). Стоило написать проще: «Високосная секунда не учитывается в Unix time (как будто её нет): високосная секунда прошла, а Unix time не поменялось».
  • 0
    Oracle linux ;( DEAD
  • 0
    Без указания на версию ядра звучит как «из-за отказов тормозов АВТОМОБИЛИ врезались в здание».

    По моим наблюдениям все более-менее новые линуксы (включая даже 2.6.18) живут.
    • –1
      Так и запишем, что Селектел ставит юзерам 2.6.18 ядро.
      У нас отказы в основном на
      Linux 3.2.13 #1 SMP Tue Mar 27 15:20:18 MSK 2012 x86_64 GNU/Linux
      • +1
        Вы не поверите, но в центосе 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
        • 0
          Какой же Вы невнимательный! Проблема практически не встречается
          if
          [ `ps aux | grep java | wc -l` -eq 1 ]
          fi

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

          Хост-системы мы давно перекатили на 3-е ядро, он в него уже вшит и работает ми-ми-ми.
    • 0
      java 6.24 успешно выжила (2.6.32-100.0.19.el5), а вот 6.31 на тесте (2.6.32-300.11.1.el5uek) — почти колом встал сервер, но на запросы отвечал.
      применением даты и рестартом ntpd все вылечилось…
      причем прикол — последнее ядро от Оракла :)
    • 0
      А зря вы уязвимую версию не используете — могли бы неплохо подзаработать на точном аккаунтинге загруженных на 100% систем :)
  • 0
    Сервак на OpenSUSE 12.1 — kernel 3.1.10-1.9-xen.
    Сегодня упал. В логах фагурировал процесс с java.
  • 0
    OpenSuSE Linux 3.4.3-30 x86_64 — полет нормальный
  • 0
    1/07 ночью все java процессы начали хавать 100% cpu
    пришлось перестартовывать сервер
    Ubuntu 10
  • 0
    Вот ещё один сводный пост: landslidecoding.blogspot.co.uk/2012/07/linuxs-leap-second-deadlocks.html
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    linux.derkeiler.com/Mailing-Lists/Kernel/2007-07/msg00714.html
    lists.debian.org/debian-user/2009/01/msg00056.html

    Однаго багу не один год уже. Линукс такой линукс.
  • 0
    Проблема в ядре линукса.

    Вот кусок метода 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

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.