Коллеги, есть демон, который создает дочерние процессы.
Хотелось, чтобы все эти процессы писали сообщения в один лог-файл.

В связи с чем вопросы:
1. Можно ли детям использовать дескрипторы лог-файла, унаследованные от родителя?
2. Нужна ли синхронизация записи в лог, и если да, как проще всего ее реализовать?

Здравствуйте, Аноним, Вы писали:

А>Коллеги, есть демон, который создает дочерние процессы.
А>Хотелось, чтобы все эти процессы писали сообщения в один лог-файл.

А>В связи с чем вопросы:
А> 1. Можно ли детям использовать дескрипторы лог-файла, унаследованные от родителя?
А> 2. Нужна ли синхронизация записи в лог, и если да, как проще всего ее реализовать?

Можно. Но надо продумать, как будет делаться атомарность записи. Варианты — запись кусками короче страницы (не гарантируется, но на практике работает для большинства современных флаворов); flock/lockf/аналоги.

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, Аноним, Вы писали:

А>>Коллеги, есть демон, который создает дочерние процессы.
А>>Хотелось, чтобы все эти процессы писали сообщения в один лог-файл.

А>>В связи с чем вопросы:
А>> 1. Можно ли детям использовать дескрипторы лог-файла, унаследованные от родителя?
А>> 2. Нужна ли синхронизация записи в лог, и если да, как проще всего ее реализовать?

N>Можно. Но надо продумать, как будет делаться атомарность записи. Варианты — запись кусками короче страницы (не гарантируется, но на практике работает для большинства современных флаворов); flock/lockf/аналоги.

А семафор можно использовать? Демон на Perl, если это имеет значение.

Здравствуйте, Аноним, Вы писали:

А>А семафор можно использовать?

Лучше использовать syslog.

Здравствуйте, ДимДимыч, Вы писали:

ДД>Здравствуйте, Аноним, Вы писали:

А>>А семафор можно использовать?

ДД>Лучше использовать syslog.

Хочется использовать перловый модуль Log::Dispatch.
С ним как быть?

Здравствуйте, netch80, Вы писали:


А>>В связи с чем вопросы:
А>> 1. Можно ли детям использовать дескрипторы лог-файла, унаследованные от родителя?

Ну, дети же используют унаследованные stderr и stdout. Может, еще до fork-а тупо перенаправить stderr в нужный файл, и все сразу же упростится?

N>Можно. Но надо продумать, как будет делаться атомарность записи. Варианты — запись кусками короче страницы (не гарантируется, но на практике работает для большинства современных флаворов); flock/lockf/аналоги.

Открыть нужный файл с флагом O_APPEND?

Рочкинд пишет, что при записи перед вызовом write в таком случае всегда "будет предшествовать атомарный и неявный вызов lseek, переустанавливающий текущую позицию в конец" (AUP, 2-е изд., 2005г.)

Здравствуйте, slava_phirsov, Вы писали:

_>Здравствуйте, netch80, Вы писали:

_>Открыть нужный файл с флагом O_APPEND?

_>Рочкинд пишет, что при записи перед вызовом write в таком случае всегда "будет предшествовать атомарный и неявный вызов lseek, переустанавливающий текущую позицию в конец" (AUP, 2-е изд., 2005г.)

И что? А сама операция записи — атомарная? И потом, у меня перловый скрипт, использующий модуль Log::Dispatch и иже с ними, хз как оно там логи открывает.

Здравствуйте, Аноним, Вы писали:

А>И что? А сама операция записи — атомарная? И потом, у меня перловый скрипт, использующий модуль Log::Dispatch и иже с ними, хз как оно там логи открывает.

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

Log::Dispatch::Handle — Object for logging to IO::Handle classes. Открываем нужный файл с нужными флагами — и вперед!

Здравствуйте, Аноним, Вы писали:

_>>Рочкинд пишет, что при записи перед вызовом write в таком случае всегда "будет предшествовать атомарный и неявный вызов lseek, переустанавливающий текущую позицию в конец" (AUP, 2-е изд., 2005г.)

А>И что? А сама операция записи — атомарная? И потом, у меня перловый скрипт, использующий модуль Log::Dispatch и иже с ними, хз как оно там логи открывает.

Там же: "флаг O_APPEND прекрасно подходит для ведения файлов журналов и в других ситуациях, когда необходимо собирать в файл данные, поступающие от нескольких процессов". Т.е. как раз для того самого и предназначался.

Здравствуйте, slava_phirsov, Вы писали:

_>Здравствуйте, Аноним, Вы писали:

_>>>Рочкинд пишет, что при записи перед вызовом write в таком случае всегда "будет предшествовать атомарный и неявный вызов lseek, переустанавливающий текущую позицию в конец" (AUP, 2-е изд., 2005г.)

А>>И что? А сама операция записи — атомарная? И потом, у меня перловый скрипт, использующий модуль Log::Dispatch и иже с ними, хз как оно там логи открывает.

_>Там же: "флаг O_APPEND прекрасно подходит для ведения файлов журналов и в других ситуациях, когда необходимо собирать в файл данные, поступающие от нескольких процессов". Т.е. как раз для того самого и предназначался.

Еще раз повторю вопрос: есть гарантия, что сама операция записи в файл из разных процессов — атомарная?

Здравствуйте, Аноним, Вы писали:

_>>Там же: "флаг O_APPEND прекрасно подходит для ведения файлов журналов и в других ситуациях, когда необходимо собирать в файл данные, поступающие от нескольких процессов". Т.е. как раз для того самого и предназначался.

А>Еще раз повторю вопрос: есть гарантия, что сама операция записи в файл из разных процессов — атомарная?

Еще раз повторю ответ: по данным из Рочкинда, флаг O_APPEND предназначен для записи данных, поступающих от нескольких процессов (ваш случай). man open говорит, что он открывает файл в режиме дописывания, и что он не даст защиты от гонок для случая NFS. "Ну что мне, землю из горшка есть?"(c)

Здравствуйте, slava_phirsov, Вы писали:

N>>Можно. Но надо продумать, как будет делаться атомарность записи. Варианты — запись кусками короче страницы (не гарантируется, но на практике работает для большинства современных флаворов); flock/lockf/аналоги.
_>Открыть нужный файл с флагом O_APPEND?
_>Рочкинд пишет, что при записи перед вызовом write в таком случае всегда "будет предшествовать атомарный и неявный вызов lseek, переустанавливающий текущую позицию в конец" (AUP, 2-е изд., 2005г.)

O_APPEND не спасает от ситуаций следующего вида:
1. Процесс 1 делает write(), например, на 64KB.
2. Процесс 2 делает write() на 64KB.
3. Ядро в контексте процесса 1 скидывает 16KB в блок (кластер) файла и уходит в спячку на запись.
4. Ядро в контексте процесса 2 скидывает 16KB в блок (кластер) файла и уходит в спячку на запись.
[...]

В результате таких взаимодействий внутри файла могут оказаться куски одной операции перемешанные кусками другой операции.
"Атомарный" lseek перед write от этого не защищает.
Я говорил ранее именно о практической (нестандартной) гарантии атомарной записи кусков небольшого размера (системно-зависимо, но реально начинается от 4KB).

Здравствуйте, Аноним, Вы писали:

N>>Можно. Но надо продумать, как будет делаться атомарность записи. Варианты — запись кусками короче страницы (не гарантируется, но на практике работает для большинства современных флаворов); flock/lockf/аналоги.

А>А семафор можно использовать? Демон на Perl, если это имеет значение.

Можно, но это ничуть не лучше flock, зато с недостатком в виде организации и поиска отдельного семафора.

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, slava_phirsov, Вы писали:

N>O_APPEND не спасает от ситуаций следующего вида:
N>1. Процесс 1 делает write(), например, на 64KB.
N>2. Процесс 2 делает write() на 64KB.
N>3. Ядро в контексте процесса 1 скидывает 16KB в блок (кластер) файла и уходит в спячку на запись.
N>4. Ядро в контексте процесса 2 скидывает 16KB в блок (кластер) файла и уходит в спячку на запись.
N>[...]

N>В результате таких взаимодействий внутри файла могут оказаться куски одной операции перемешанные кусками другой операции.
N>"Атомарный" lseek перед write от этого не защищает.
N>Я говорил ранее именно о практической (нестандартной) гарантии атомарной записи кусков небольшого размера (системно-зависимо, но реально начинается от 4KB).

Именно это и интересует ТС, и когда-то интересовало меня — а не будут ли перекрываться операции записи? Я искал ответа (возможно, не там искал), но никаких железобетонных гарантий, что операции записи перекрываться не будут нигде и никогда, не нашел. Но. Я не нашел и обратного утверждения, что режим "дописывания" может дать такую проблему. Если может, то тогда вопрос — а что это за такое "дописывание", и какой тогда смысл в гарантии позиционирования "точно в конец файла", если данные потом все равно могут быть перезаписаны другим процессом?

Здравствуйте, slava_phirsov, Вы писали:

_>Именно это и интересует ТС, и когда-то интересовало меня — а не будут ли перекрываться операции записи? Я искал ответа (возможно, не там искал), но никаких железобетонных гарантий, что операции записи перекрываться не будут нигде и никогда, не нашел. Но. Я не нашел и обратного утверждения, что режим "дописывания" может дать такую проблему.

Я наблюдал это на практике.

_> Если может, то тогда вопрос — а что это за такое "дописывание", и какой тогда смысл в гарантии позиционирования "точно в конец файла", если данные потом все равно могут быть перезаписаны другим процессом?

Это ограниченные гарантии, как уже сказано

Здравствуйте, netch80, Вы писали:

N>Я наблюдал это на практике.

Ну, это могла быть ошибка наблюдения (например, один из пишущих процессов не установил флаг O_APPEND), или кривизна конкретной реализации (на NFS, как честно указано в доках, оно вообще не работает). Я использовал эту штуку (для задачи схожей с задачей ТС — записи логов от нескольких процессов) и в режиме 24/7 ничего подозрительного не нашел. Впрочем, размер сообщения в лог был значительно меньше 64к.

_>> Если может, то тогда вопрос — а что это за такое "дописывание", и какой тогда смысл в гарантии позиционирования "точно в конец файла", если данные потом все равно могут быть перезаписаны другим процессом?

N>Это ограниченные гарантии, как уже сказано

Вот, кстати здесь

If the O_APPEND flag of the file status flags is set, the file offset shall be set to the end of the file prior to each write and no intervening file modification operation shall occur between changing the file offset and the write operation.

но там же много и возражений, так что...

Здравствуйте, Аноним, Вы писали:

А>Коллеги, есть демон, который создает дочерние процессы.
А>Хотелось, чтобы все эти процессы писали сообщения в один лог-файл.

А>В связи с чем вопросы:
А> 1. Можно ли детям использовать дескрипторы лог-файла, унаследованные от родителя?
А> 2. Нужна ли синхронизация записи в лог, и если да, как проще всего ее реализовать?

Дети пишут в пайп родителю, или в local “udp” сокет, если хочется автоматические границы. Родитель жрет из этих сокетов и пишет в файл.

Здравствуйте, andrey.desman, Вы писали:

AD>Дети пишут в пайп родителю, или в local “udp” сокет, если хочется автоматические границы. Родитель жрет из этих сокетов и пишет в файл.

Опять вопрос упирается в ограничение размера. Для пайпов есть, ЕМНИП, граница PIPE_BUF, датаграммы тоже не резиновые. Но хоть, по кр. мере, в этом случае поведение хоть как-то гарантируется

Здравствуйте, slava_phirsov, Вы писали:

_>Здравствуйте, Аноним, Вы писали:

_>>>Там же: "флаг O_APPEND прекрасно подходит для ведения файлов журналов и в других ситуациях, когда необходимо собирать в файл данные, поступающие от нескольких процессов". Т.е. как раз для того самого и предназначался.

А>>Еще раз повторю вопрос: есть гарантия, что сама операция записи в файл из разных процессов — атомарная?

_>Еще раз повторю ответ: по данным из Рочкинда, флаг O_APPEND предназначен для записи данных, поступающих от нескольких процессов (ваш случай). man open говорит, что он открывает файл в режиме дописывания, и что он не даст защиты от гонок для случая NFS. "Ну что мне, землю из горшка есть?"(c)

Респект всем. Плюнул и посмотрел код Log::Dispatch::FileRotate
Там внутри flock() используется, так что проблем быть не должно даже при записи в один лог из разных процессов.

Здравствуйте, Аноним, Вы писали:

А>Респект всем. Плюнул и посмотрел код Log::Dispatch::FileRotate
А>Там внутри flock() используется, так что проблем быть не должно даже при записи в один лог из разных процессов.

Попрошу суд занести в протокол тот факт, что господин подзащитный также планирует использовать недокументированные особенности реализации