crontab... Что я делаю не правильно?

Serguei E. Leontiev написал(а) к Anatoly Gerasimov в Jan 15 15:41:00 по местному времени:

From: "Serguei E. Leontiev" <leo@sai.msu.ru>

Анатолий, привет,

Anatoly Gerasimov <Anatoly.Gerasimov@f109.n6070.z2.fidonet.org> wrote:
>>>> Уточни, когда последний раз перезагружался?
>>> 355 дней назад.
>> Понял откуда час взялся?
> Нет, не понял. Зоны используются с фиксированным смещением, без перехода на
> летнее-зимнее время.

Да даже, если бы и не фиксированные смешения, 355 дней назад было бы тоже
зимнее время.

Кроме, того, ИМХО, glibc считывал тогда правила изменения локального
времени, поэтому он бы отследил бы переходы с летнего на зимнее и обратно.
А вот на изменение правил, он забил.

>> Это ж Linux
> И что такого интересного в нем?

В данном случае glibc :)

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

--
Успехов, Сергей Леонтьев, <http://www.cryptopro.ru> (NewsTap)
--- ifmail v.2.15dev5.4

Serguei E. Leontiev написал(а) к Anatoly Gerasimov в Jan 15 15:41:01 по местному времени:

From: "Serguei E. Leontiev" <leo@sai.msu.ru>

Привет, Анатолий,

Anatoly Gerasimov <Anatoly.Gerasimov@f109.n6070.z2.fidonet.org> wrote:
>> yum install tzdata
> В наших условиях - бесполезно в принципе.

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

>> && service crond restart
> Это помогло. Но на мой взгляд это чуть менее криво чем перезагрузка системы. В
> какой доке написана необходимость этого мероприятия после смены TZ?

Не написано, мало того рестарта одного crond может быть недостаточно для
счастливой жизни (почтовые, фидошные и прочие демоны так же могут
продолжать страдать). Проблема в ошибочной наивной реализации POSIX в
glibc, который считывает tzdata один раз за время жизни процесса, игнорируя
дальнейшие изменения.

P.S.

Будем посмотреть, вот ты оформишь ли сообщение об ошибке glibc? Или
оставишь Linux в его убогом положении и далее.

--
Успехов, Сергей Леонтьев, <http://www.cryptopro.ru> (NewsTap)
--- ifmail v.2.15dev5.4

Alexey Vissarionov написал(а) к Serguei E. Leontiev в Jan 15 16:22:16 по местному времени:

Доброго времени суток, Serguei!
25 Jan 2015 15:41:00, ты -> Anatoly Gerasimov:

>>> && service crond restart
>> Это помогло. Но на мой взгляд это чуть менее криво чем перезагрузка
>> системы. В какой доке написана необходимость этого мероприятия после
>> смены TZ?
SL> Не написано, мало того рестарта одного crond может быть недостаточно
SL> для счастливой жизни (почтовые, фидошные и прочие демоны так же могут
SL> продолжать страдать). Проблема в ошибочной наивной реализации POSIX в
SL> glibc, который считывает tzdata один раз за время жизни процесса,
SL> игнорируя дальнейшие изменения.

Временная зона - свойство процесса, а не системы.
Точно как же, как и, например, локаль.

SL> Будем посмотреть, вот ты оформишь ли сообщение об ошибке glibc? Или
SL> оставишь Linux в его убогом положении и далее.

NAB.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii

... Все мы - да. Но некоторые - таки.
--- /bin/vi

Serguei E. Leontiev написал(а) к Alexey Vissarionov в Jan 15 17:29:05 по местному времени:

From: "Serguei E. Leontiev" <leo@sai.msu.ru>

Алексей, привет,

Alexey Vissarionov <Alexey.Vissarionov@f545.n5020.z2.fidonet.org> wrote:
>>> системы. В какой доке написана необходимость этого мероприятия после
>>> смены TZ?
>> Не написано, мало того рестарта одного crond может быть недостаточно
>> для счастливой жизни (почтовые, фидошные и прочие демоны так же могут
>> продолжать страдать). Проблема в ошибочной наивной реализации POSIX в
>> glibc, который считывает tzdata один раз за время жизни процесса,
>> игнорируя дальнейшие изменения.
> Временная зона - свойство процесса, а не системы.

Твоя правда, только ты открой нормативную документацию POSIX и прочитай,
что именно является этим свойством. Значение переменной окружения TZ -
определяет правила преобразования, которые устанавливаются вызовом tzset().

По POSIX тот же localtime() безусловно вызывает tzset().

По документации glibc, "The localtime() function converts the calendar time
timep to broken-time representation, expressed relative to the user's
specified timezone. The function acts as if it called tzset(3) and sets the
external variables tzname with information about the current timezone, ..."

Таким образом, и POSIX, и документация glibc, указывают на то, что должны
применятся правила преобразования, которые действуют на момент вызова того
же localtime().

Фактически же оно в glibc работает иначе, не так, как описано в
документации и это ошибка.

>> Будем посмотреть, вот ты оформишь ли сообщение об ошибке glibc? Или
>> оставишь Linux в его убогом положении и далее.
> NAB.

Перевод 'nab' в русском бесплатном словаре и многие другие русские
переводы. ... to nab [nabbed|nabbed] {глаг.} схватить на месте преступления
{глаг.} ???

--
Успехов, Сергей Леонтьев, <http://www.cryptopro.ru> (NewsTap)
--- ifmail v.2.15dev5.4

Alexey Vissarionov написал(а) к Serguei E. Leontiev в Jan 15 18:11:18 по местному времени:

Доброго времени суток, Serguei!
25 Jan 2015 17:29:04, ты -> мне:

>>>> В какой доке написана необходимость этого мероприятия после смены
>>>> TZ?
>>> Проблема в ошибочной наивной реализации POSIX в glibc, который
>>> считывает tzdata один раз за время жизни процесса, игнорируя
>>> дальнейшие изменения.
>> Временная зона - свойство процесса, а не системы.
SL> Твоя правда, только ты открой нормативную документацию POSIX и
SL> прочитай, что именно является этим свойством. Значение переменной
SL> окружения TZ - определяет правила преобразования, которые
SL> устанавливаются вызовом tzset().

Процесс остался тем же, но вызвал setenv(); что должно поменяться?

SL> По POSIX тот же localtime() безусловно вызывает tzset().
SL> Фактически же оно в glibc работает иначе, не так, как описано в
SL> документации и это ошибка.

Предлагаешь всякий раз заглядывать в /etc/localtime?

>>> Будем посмотреть, вот ты оформишь ли сообщение об ошибке glibc?
>>> Или оставишь Linux в его убогом положении и далее.
>> NAB.
SL> Перевод 'nab'

... предельно прост: not a bug.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii

... # losetup -e blowfish -k 256 -Н sha512 /dev/loop0 /dev/md0
--- /bin/vi

Anatoly Gerasimov написал(а) к Serguei E. Leontiev в Jan 15 23:57:28 по местному времени:

Нello Serguei,

25 Jan 15, Serguei E. Leontiev (2:5020/400) wrote to Anatoly Gerasimov:

>>>> 355 дней назад.
>>> Понял откуда час взялся?
>> Нет, не понял. Зоны используются с фиксированным смещением, без
>> перехода на летнее-зимнее время.

SL> Да даже, если бы и не фиксированные смешения, 355 дней назад было бы
SL> тоже зимнее время.
Если честно, то я не понял идеи. При установке системы изначально выбиралась зона с фиксированным от GMT смещением. Переход времени - по at создавался симлинк /etc/localtime на зону с таким же, фиксированным смещением но на час меньше. Как я понимаю, проблема именно здесь. Кто-то (я) поменял таймзону в системе, но откуда это знать процессам? Считав один раз правила и убедившись в отсутствии перехода они спокойно живут вчерашним днём (с 00:00 до 01:00 текущего дня).

WBR Anatoly.
--- GoldED+/W32-MINGW 1.1.5-b20061116

Anatoly Gerasimov написал(а) к Serguei E. Leontiev в Jan 15 23:47:56 по местному времени:

Нello Serguei,

25 Jan 15, Serguei E. Leontiev (2:5020/400) wrote to Anatoly Gerasimov:

SL> Не написано, мало того рестарта одного crond может быть недостаточно
SL> для счастливой жизни (почтовые, фидошные и прочие демоны так же могут
SL> продолжать страдать).
Ты знал!
2 последовательные записи в логе sendmail

=================== Cut ===================
Jan 25 19:45:53 microsoft sendmail[3399]: <MTA получил письмо>
Jan 25 18:45:53 microsoft sendmail[4367]: <доставлено локально>
================= End cut =================

WBR Anatoly.
--- GoldED+/W32-MINGW 1.1.5-b20061116

Serguei E. Leontiev написал(а) к Alexey Vissarionov в Jan 15 20:59:21 по местному времени:

From: "Serguei E. Leontiev" <leo@sai.msu.ru>

Привет Алексей,

От 25 января 2015 г., 18:11:18 в fido7.ru.linux.chainik ты писал:
??>>>>> В какой доке написана необходимость этого
??>>>>> мероприятия после смены TZ?
??>>>> Проблема в ошибочной наивной реализации POSIX в
??>>>> glibc, который считывает tzdata один раз за время
??>>>> жизни процесса, игнорируя дальнейшие изменения.
??>>> Временная зона - свойство процесса, а не системы.
SL>> Твоя правда, только ты открой нормативную документацию
SL>> POSIX и прочитай, что именно является этим свойством.
SL>> Значение переменной окружения TZ - определяет правила
SL>> преобразования, которые устанавливаются вызовом tzset().
AV> Процесс остался тем же, но вызвал setenv(); что должно
AV> поменяться?

И в документации POSIX, и документации glibc - ясно же указано, что
tzset() устанавливает правила, согласно значению переменной TZ, текущему
значению.

И, насколько мне известно, tzset() работает так, как описано.

SL>> По POSIX тот же localtime() безусловно вызывает tzset().
SL>> Фактически же оно в glibc работает иначе, не так, как
SL>> описано в документации и это ошибка.
AV> Предлагаешь всякий раз заглядывать в /etc/localtime?

Это не единственный способ реализовать эквивалентность вызовов
localtime() и "(tzset(), localtime())".

??>>>> Будем посмотреть, вот ты оформишь ли сообщение об
??>>>> ошибке glibc? Или оставишь Linux в его убогом
??>>>> положении и далее.
??>>> NAB.
SL>> Перевод 'nab'
AV> ... предельно прост: not a bug.

Ну да это не ошибка, а целый букет ошибок:

1. Очевидно crond функционирует некорректно: пользователь вносит задание
согласно текущему состоянию временной зоны, а crond его исполняет
согласно состоянию временной зоны на момент старта (предположительно, он
сразу обращается к localtime() или tzset()). Вариантов три: свалить на
ошибку glibc (ИМХО, предпочтительный), обеспечить адекватный вызов
tzset() или описать в документации;

2. Функция localtime() работает не так, как описано в POSIX и своей
документации. Вариантов два: исправить функцию, либо исправить
документацию и отразить отличие от POSIX, что localtime() пользуется
результатом tzset() и вызывает его, в случае если он ещё ни разу не был
вызван ранее;

3. В случае, если избранный путь - послать POSIX со всеми остальными
лесом и править документацию. Тогда надо научить дистрибутивы Linux, при
обновлении tzdata, перезагружать всех демонов, которые используют
localtime(). Си речь об улучшениях конфигурации systemd, ибо SVR5 init с
этим явно не справится. :)

--
Успехов, Сергей Леонтьев. E-mail: lse@CryptoPro.ru


--- ifmail v.2.15dev5.4

Serguei E. Leontiev написал(а) к Valentin Davydov в Feb 15 09:02:13 по местному времени:

From: "Serguei E. Leontiev" <leo@sai.msu.ru>

Привет Валентин,

От 5 февраля 2015 г., 15:50:39 в fido7.ru.linux.chainik ты писал:
SL>>> По POSIX тот же localtime() безусловно вызывает tzset().
SL>>> Фактически же оно в glibc работает иначе, не так, как описано в
SL>>> документации и это ошибка.
??>> Предлагаешь всякий раз заглядывать в /etc/localtime?
VD> А в чём проблема, собственно, заглянуть? Файлец маленький, в
VD> одну страницу помещается.

Каждый раз считывать - лишний системный вызов.

Однако, т.к. glibc уже давно библиотека практически одной системы
GNU/Linux, то есть же в GNU/Linux эффективные средства мониторинга
изменений файлов.

Как вариант, периодическое считывание по расписанию.

--
Успехов, Сергей Леонтьев. E-mail: lse@CryptoPro.ru


--- ifmail v.2.15dev5.4

Valentin Davydov написал(а) к Serguei E. Leontiev в Feb 15 19:40:12 по местному времени:

From: Valentin Davydov <sp@m.davydov.spb.su>

> From: "Serguei E. Leontiev" <leo@sai.msu.ru>
> Date: Sun, 15 Feb 2015 06:02:13 +0000 (UTC)
>
> SL>>> По POSIX тот же localtime() безусловно вызывает tzset().
> SL>>> Фактически же оно в glibc работает иначе, не так, как описано в
> SL>>> документации и это ошибка.
> ??>> Предлагаешь всякий раз заглядывать в /etc/localtime?
> VD> А в чём проблема, собственно, заглянуть? Файлец маленький, в
> VD> одну страницу помещается.
>
>Каждый раз считывать - лишний системный вызов.

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

>Однако, т.к. glibc уже давно библиотека практически одной системы
>GNU/Linux, то есть же в GNU/Linux эффективные средства мониторинга
>изменений файлов.

Это да. В других системах особенности поведения localtime() чётко описаны
в документации, например;

The function localtime() uses tzset(3) to initialize time conversion
information if tzset(3) has not already been called by the process.

>Как вариант, периодическое считывание по расписанию.

Авторы демонов этой возможностью почему-то неохотно пользуются...

Вал. Дав.
--- ifmail v.2.15dev5.4