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

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

Нello Serguei,

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

AG>> Переход времени - по at создавался симлинк /etc/localtime на
AG>> зону с таким же, фиксированным смещением но на час меньше.

SL> М-м-м, процесс процессу - рознь, одни вызывают tzset() часто, другие
SL> по запросу, третьи вообще не вызывают, поэтому у них могут быть очень
SL> разные и непредсказуемые представления о временной зоне установленной
SL> в системе по умолчанию.
Да уж. Спасибо, буду знать.

SL> Честно говоря, я тоже не понял, чего ты хотел добиться своим "...по at
SL> создавался симлинк /etc/localtime...".
Автоматической, в указанное время, смены зоны с одной, не зависящей от законодательных инициатив на другую, такую же, но с другим смещением. А как иначе обеспечивать переводы стрелок часов в не [регулярно] обновляемых системах? Как выясняется - не годный, глюкавый способ. Но другие мне известные чреваты еще большими глюками на прикладном уровне.
SL> Так как в Linux у программ,
SL> библиотек и демонов не принято работать по документации, то это самая
SL> глючная конфигурация из всех возможных конфигураций, ибо динамическая.
Гораздо хуже ситуация когда у прикладного софта и операционки разное мнение о текущем смещении относительно UTC.

SL> Кроме того "симлинк /etc/localtime" - моветон и источник граблей.
А как правильно?
SL> При стандартной конфигурации, в которой /etc/localtime
SL> перезаписывается
SL> , гюков меньше, хотя и сохраняется зависимость от
SL> устанавливаемых обновлений.
А в чем разница между cp /usr/share/zoneinfo/Etc/GMT-n /etc/localtime и
ln -s /usr/share/zoneinfo.Etc.GMT-n /etc/localtime или, быть может, хардлинком?

Да, кстати, cp как и вызов system-config-date не повлиял на ситуацию.
SL> Тогда уж, нужно было бы установить для всех демонов переменную
SL> окружения TZ в классические "UTC+0" или "IST-2IDT" (man tzset). А для
SL> себя устанавливать уже свою TZ с человеческой зоной. Тогда бы у тебя
SL> бы если бы и возникали бы вопросы, то только к самому себе.
Да, согласен. Мысль - держать систему в UTC+0 а прикладной софт, чувствительный к актуальности TZ в отдельном окружении, с которым и сексоваться при необходимости - интересная. Сразу вопрос - а обязан ли софт, при наличии TZ в окружении брать информацию именно оттуда?


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

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

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

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

Anatoly Gerasimov <Anatoly.Gerasimov@f109.n6070.z2.fidonet.org> wrote:
> А в чем разница между cp /usr/share/zoneinfo/Etc/GMT-n /etc/localtime и
> ln -s /usr/share/zoneinfo.Etc.GMT-n /etc/localtime или, быть может, хардлинком?

Если обновляешь пакет с названием типа tzdata (/usr/share/zoneinfo), то в
случае символической ссылки системная зона изменяет сей секунд, а это может
быть нежелательно.

> необходимости - интересная. Сразу вопрос - а обязан ли софт, при наличии TZ в
> окружении брать информацию именно оттуда?

Компоненты glibc берут только оттуда.

Программы могут иметь возможность явного указания в конфигурационных
файлах.

В отличии от местного языка (locale), который в последнее время в новом
интерфейсе POSIX можно установить различным для разных потоков или частей
программы, временная зона устанавливается одна на весь процесс.

Поэтому, практически все многопоточные среды исполнения: Java, perl, php,
python ... имеют собственные реализации базы данных временных зон.

Обычно, это всё совместимо с документацией tzset() в части переменной
окружения TZ, конечно, с точностью до ошибок. Полезно сравнить man tzset и
документацией на конкретную программу.

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

Valentin Davydov написал(а) к Alexey Vissarionov в Feb 15 15:50:39 по местному времени:

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

> From: Alexey Vissarionov
> <Alexey.Vissarionov@f545.n5020.z2.fidonet.org>
> Date: Sun, 25 Jan 2015 18:11:18 +0300
>
> SL> По POSIX тот же localtime() безусловно вызывает tzset().
> SL> Фактически же оно в glibc работает иначе, не так, как описано в
> SL> документации и это ошибка.
>
>Предлагаешь всякий раз заглядывать в /etc/localtime?

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

Вал. Дав.

--- ifmail v.2.15dev5.4

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

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

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

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

Это немного дороже, чем 1 страница. В типичном случае, это open() на
символическую ссылку "/etc/localtime" и read() небольшого объёма. В
прочем, при наличии localtime_r() такая реализация тоже была бы приемлема.

??>> Однако, т.к. glibc уже давно библиотека практически одной
??>> системы GNU/Linux, то есть же в GNU/Linux эффективные
??>> средства мониторинга изменений файлов.
VD> Это да. В других системах особенности поведения localtime()
VD> чётко описаны в документации, например;
VD> The function localtime() uses tzset(3) to initialize time
VD> conversion information if tzset(3) has not already been called
VD> by the process.

Ну потребители более строгие, так что немного честнее, а так, те же
грабли, только в профиль. Это получается уже почти localtime_r(). И
каждый производитель программы или демона должен выбирать между:
- забить и удовлетворится однократным считыванием;
- звать tzset() на сигнал НUP (/etc/rc.d/XXXX reload);
- каждый раз звать tzset();
- делать это по расписанию (типа в 02:01) или по таймауту, например, раз
в 10^6 - 10^9 тактов процессора;
- самостоятельно мониторить изменения (технически возможно, ибо
устройство tzset() документировано, но это всё же его потороха и
программам негоже зависеть от них).

??>> Как вариант, периодическое считывание по расписанию.
VD> Авторы демонов этой возможностью почему-то неохотно
VD> пользуются...

Возможно они думают, что когда нибудь эту ошибку реализации localtime()
в glibc исправят. Хотя, по хорошему, могли бы перейти на честный
localtime_r().

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

>>
--- ifmail v.2.15dev5.4

Valentin Davydov написал(а) к Serguei E. Leontiev в Mar 15 14:04:08 по местному времени:

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

> From: "Serguei E. Leontiev" <leo@sai.msu.ru>
> Date: Tue, 24 Mar 2015 10:42:07 +0000 (UTC)
>
> SL>>>>> По POSIX тот же localtime() безусловно вызывает tzset().
> SL>>>>> Фактически же оно в glibc работает иначе, не так, как описано в
> SL>>>>> документации и это ошибка.
> ??>>>> Предлагаешь всякий
> ??>>>> раз заглядывать в /etc/localtime?
> VD>>> А в чём проблема, собственно, заглянуть? Файлец маленький, в
> VD>>> одну страницу помещается.
> ??>> Каждый раз считывать - лишний системный вызов.
> VD> Так оно ж всё равно вызывается не просто так, а ради того,
> VD> чтобы лог записать, хедер отослать или ещё какую штуку сдеалть,
> VD> которая и сама по себе системные вызовы требует, причём, в
> VD> отличие от считывания 1 страницы из кэша, занимает дорогие
> VD> ресурсы вроде диска или сети.
>
>Это немного дороже, чем 1 страница. В типичном случае, это open() на
>символическую ссылку "/etc/localtime" и read() небольшого объёма.

Так к диску при этом обращение идёт или нет? Пусть соседний процесс
секунду назад его уже читал.

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