Пользователь
0,0
рейтинг
30 октября 2011 в 15:49

Администрирование → Своеобразие cron при не-переводе времени на зимнее

*nix*
Сегодня мы бы перевели время. И мы бы сделали это, если бы не указ Президента «Об отмене перехода на сезонное время»… Все, видимо, обновили ПО на серверах (и мы не исключение) и не ждали подвоха, но…

Тестовый скрипт, проверяющий живучесть одной из систем, радостно отрапортовал мне сегодня в час дня вместо запланированных полудня. Я полез на сервер. Время стояло правильное (не переведенное), таймзона тоже верная. Проверил как Ruby возвращает время. Тоже правильно. Посмотрел логи. Время нигде не перевелось! (как и должно было быть).

Закралось одно подозрение, и я вписал в кронтаб тестовый запуск cron'а — ага! — так и срабатывает с задержкой на час! Перезапустил крон. Еще один тест. Да, теперь работает как надо. Нашли! Правда, последовавший за этим ручной перезапуск кронов на остальных (порядка 20) серверах — занятие было еще то.

Мораль: дефолтный cron на FreeBSD (разных версий, вплоть до 8.2) нуждается в перезапуске, после даты «непереведения» времени, иначе где-то в своих недрах все-таки его переводит! Интересно, что будет весной (может быть, к весне обновится?). Или может уже стоило обновить, но теперь удостовериться можно будет только весной?..

«Хозяйке на заметку», как говорится: «если ломатете голову, что сегодня пошло не так, перезапустите крон».

PS. Linux-овые машины (конкретно: Debian и Gentoo с vixie-cron) не оказались подвержены данной оказии. Ну, это не мудрено — там сам крон другой. Но тем не менее, на сабжевой ОС мы все же столкнулись с данным, скажем так, своеобразием поведения отдельно взятого системного приложения.
@dave42
карма
0,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

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

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

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

  • 0
    Мне вспоминается древний Alt Linux 2.0 или 2.2. Там в логах messages периодически проскакивали блоки с временем -3 или -4. Т.е. какие-то сервисы изначально жили по своему собственному времени.
    • 0
      Кроме крона может послетать время в PHP: echo date(...); и MySQL: select now(). При том что date и date -u будут показывать корректное время. Похоже что в юниксах за daylight switch каждая софтина следит по-своему, из операционки эта информация не берётся.
      • 0
        Если это правда (последнее предложение), то, народ, а что же это тогда за операционная СИСТЕМА, если системности нет никакой?! Или я чего-то не понял, растолкуйте кому не лень?
        • 0
          это POSIX система, которая может дать только UTC время и параметры часового пояса, но не скалькулированное под этот часовой пояс время. В итоге все кэшируют параметры timezone и если apache/nginx/mysql давно не ребутились, то они сами не переподхватят свежие настройки, где переход на зимнее время отменён. С PHP вообще какая-то мутная история — как я понял, в него вшита своя база переходов, независящая от операционки и лечится это каким-то модулем. Опенсорсный коммунизм в расцвете :) биллборды ВТБ и сбербанк-онлайн сегодня тоже на часа назад съехали + популярные хостинги со скрипом всё на место вертают.
      • 0
        Да, действительно и cron, и mysqld, и (что я заметил только через неделю) rsyslogd работал по переведённому времени, что путало меня в течение минут 15-20 пока я искал в логах нужное событие…
  • 0
    Кстати, у меня было подозрение, что патчи ОС для отмены перевода времени могут оказаться недоделанными, а где-то просто не устанавливаться. Поэтому мы приняли решение о простом переводе часового пояса на Asia/Muscat. Единственный минус — теперь формально живем по-арабскому времени…
    • +1
      Это первое что пришло в голову, когда уже знали о переводе времени, но не знали, успеют ли всё запатчить )
      • 0
        Для ESX 4 патч вышел 27 (а то и 28) числа. Они полагали, что в России все делается только по пятницам :)
        • 0
          В России, действительно, многое делается по пятницам, но как правило это далеко от обновления ПО! Повезло, что вендор еще успел сообщить, а вы еще это обновление заметить успели.
          • 0
            Кому-то может так и «повезло», а я его заметил только сейчас. Реальная дата выпуска мне не известна. Стоит 27.10, однако патчи у VmWare всегда датируются задним числом. Уже не в первый раз выкладывают апдейты по пятницам.
  • +5
    А еще оказывается надо mysql рестартануть, чтобы он тоже подхватил из системы нужную таймзону. Тоже смотрю, все везде ок, а время NOW() в мускуле неверное.
  • 0
    В догонку к посту — Постгрес версий до 9.0.5 тоже оказался подвержен «проблеме 2011».
    Там спасет «timezone = +4» в конфиге плюс рестарт (не релоад).
    • 0
      У меня постгрес 9.1.1, увы, сам сменил время. Тоже без перезагрузки не обошлось.
  • +5
    Я один все серверные машины настраиваю на использование UTC?
    • +1
      Тут есть много «за» и «против». Мы — нет, кой-какой софт не позволяет.
      • +2
        Вот столкнётесь с особенностями украинской политики в области временных зон — сразу перейдёте на UTC :) и софт поправите.
        • +1
          Может быть. Пока столкнулись с особенностями в РФ. Обошлось малой кровью, как видите!
          • 0
            Посмотрите press.rzd.ru/isvp/public/press?layer_id=4069&id=78265 — они обошлись не малой кровью. А всё потому, что не решились в своё время UTC ввести.
            • 0
              Могу только посочуствовать и сказать «спасибо» за предупреждение — будем иметь в виду «особенности национальной политики», если придется с ними работать. Хотя, у нас не сильно критично бизнес на подобные вещи завязан, но кто его знает, что там будет в будущем. Спасибо.
      • +1
        Хм…

        $ date
        Sun Oct 30 15:49:07 UTC 2011
        $ TZ='Asia/Kolkata' date
        Sun Oct 30 21:19:14 IST 2011

    • 0
      Чтобы это работало, нужно чтобы клиентский софт клиенту показывал его время, а не сервера. А это не всегда так.
  • 0
    Мне пришлось поставить misc/zoneinfo чтобы часы стали идти правильно. Мир пересобирать не стал, т.к. планирую на 9.0 свой тестовый сервер перевести и уже скачал исходники 9.0-RC1.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Мой тоже перевел, но потом я включил в настройках синхронизацию времени с сетью и все стало ок :)
      В HTC Hero: Настройки -> Дата и время -> Автоматически (Использовать значения, предоставленные сетью)
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          У меня для Екатеринбурга он пишет GMT+6 (обычно +5), что совпадает со значением в винде (она тоже выставила эту зону после установки обновления), так что вроде правильные данные получает от сети.

          Не знаю в чем может быть проблема, так как не знаком с технической стороной вопроса, может в операторе дело — не все перенастроили оборудование как надо :) У меня МТС.
      • 0
        Если сеть предоставляет время.
        На Украине это одно время работало на тогдашнем ЮМС, но потом они отключили.
        И всё, другие ГСМ операторы время вообще не отдавали.
        Сейчас точно CDMA оператор инетретелеком отдает, как на остальных фронтах — не знаю.
      • 0
        Да, казалось бы это очевидно! Однако, на htc hero по дефолту есть два виджета с часами:
        — Часы(от HTC)
        — Часы(от Android)
        так вот те которые android — на них время нормальное, а те которые от HTC — временная зона Москва все равно показывает на час назад. Ничего не получилось с ними сделать, пришлось более удобный виджет HTC убрать с рабочего стола.
        • 0
          Если кликнуть по виджету и зайти на вторую вкладку (Мировое время), то там есть, в моем случае:
          — «Екатеринбург (Домашнее)» — отстает на час назад, видимо виджет использует это время.
          — «Asia/Novosibirsk (Текущее)» — правильное время, с правильным часовым поясом (хоть и не правильная надпись Новосибирск), встроенные часы андроида используют это время, которое видимо получено от сети.

          Поэтому я удалил виджет от HTC, потом нажал добавить его, и при добавлении выбрал «Текущее местоположение». В итоге время стало как и на часиках в трее. На самом виджете, около погоды город пишется правильный, не Novosibirsk :)

          • 0
            Домашнее Москва, текущее — тоже Москва, в обоих случаях выдает на час назад…
            В итоге добавил город Мускат( в котором время совпадает с нашим новым президентским, как писали выше) и вывел в виджет его, убрав галку «показывать название города»… костыли :)
  • +1
    Сегодня то же самое на дебиане заметил. После перезапуска cron заработал правильно. Наверно, он читает настройки один раз при запуске. Сейчас у сервера аптайм — 57 дней. Видимо, два месяца назад обновление часовых поясов еще не было установлено.
    • 0
      На дебе у меня на самом деле крон все верно отрабатывал. В отличие от rsyslog'а, который время показывал неправильно.
      • 0
        Спаведливости ради, у меня Деб тоже нормально отработал. Но там все обновляли не так давно.
  • 0
    Android перевел на час вперед (спасибо тебе LG). Вернул просто на 1 час назад, ничего критичного не случилось.
    С зонами разбираться пока не стал, надеюсь выйдет все же свежая прошивка скоро.
    На десктопе Ubuntu 10.04 я работал во время перевода и на ходу, внезапно перезагрузился X server, прибив все открытые приложения.
    Это я спустя пару часов понял, что случилось, перерыв все логи и не найдя никаких проблем.
    Все обновления стояли, перезапуск делал за ~8 часов до инцидента.
    • 0
      Перевод раньше совершался таки назад, а не вперёд.
      • 0
        Да конечно назад. Болею, плющит немного :)
  • +4
    У меня настенные часы, магнитола и микроволновка сдержались (но они и не умели, за что им спасибо). Макось 10.6.7, iOS 4.2 и Android 3.2 перевелись. А телефон уехал в GMT+6 Novosibirsk time (вместо правильной Yeakterinburg GMT+6) по времени сети :)
    Теперь я точно хочу купить наконец часы.
  • +2
    В который раз подтверждается правило — «Работает — не трогай». Всё ведь было нормально, все сервисы знали о переводе, и надо же было кому-то умному сказать Президенту о наличии разных временных зон…

    Может быть, кто-то от перевода и страдал. А для меня, к примеру, раз в год поспать на час дольше всегда был приятный сюрприз. Потерянный же раз в год час проходил незамеченным на фоне ненормированного дня программиста и администратора.
    • 0
      Вот через год-два одумаются и вернут как было ]:->
  • +1
    Мускуль тоже рестартнуть пришлось.

    now() возвращал сдвинутое на час время.
  • 0
    Спасибо большое за статью, сильно помогло.

    Не могу понять почему Бтирикс версии 7.х в «календариках» (где надо выбирать дату и время), выводит время со сдвигом на час назад, причем, ссылаясь, что это серверное время. На сервере везде вроде правильное время (mysql, логи, вывод date), в самом битриксе в его же логах уже правильное время.
    • 0
      Кому интересно, это проблема с таймзонами в PHP.
      Решилась так.

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