Можно ли сделать успешными операции поиска () для именованного канала?

Есть ли способ сделать так, чтобы когда программы пытались выполнить seek()операции с именованным каналом, он возвращался успешно (но действовал так, как если бы канал был пустым файлом) вместо «Незаконного поиска»?

У меня есть все последние записи в моей системе, хранящиеся в базе данных SQLite, у меня нигде нет файлов. Однако есть несколько программ, которые имеют проблемы с этим. Есть 2 конкретных случая;

Программа хочет записать в файл журнала, который syslog-ng создал как именованный канал и который читает. Программа хочет выполнить seek()по какой-то причине, а затем не удается.
Программа (например, denyhosts или fail2ban) хочет читать из файла журнала, который syslog-ng создал как именованный канал и в который пишет. Программа хочет выполнить seek()на нем и терпит неудачу.

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

Так есть ли какая-либо опция, которая может быть установлена для именованных каналов, чтобы заставить их вести себя таким образом? Если нет, то есть ли режим, который можно установить, когда syslog-ng открывает канал, чтобы он так себя вел (я открыт для внесения изменений в код)? Или я до ручья?

pipe syslog

— Патрик
источник

Ответы:

Для ядра Linux были предложены доступные для поиска каналы, но я не знаю, как работает исправление для их реализации.

Вы можете использовать LD_PRELOADбиблиотеку ed, которая переопределяет lseekвызов для определенных файлов. Я не знаю ни одной готовой упаковки для этой цели. Shadowfs может помочь в написании одного.

— Жиль "ТАК - перестань быть злым"
источник

Я попробую маршрут LD_PRELOAD. Не самое лучшее решение, но должно быть выполнимым.

— Патрик

Кстати, будет ли иметь доступную трубу для того, чтобы меньше могло следовать по трубе так же, как она может следовать за файлом? Я спрашиваю в контексте Следуй трубе, используя меньше? вопрос (вы можете предпочесть ответить там).

— Петр Доброгост

@PiotrDobrogost В контексте Fкоманды less было бы достаточно, чтобы меньше обновляло экран, если он не получает никакого вывода в течение секунды или около того. Создание каналов для поиска не помогло бы: существующее различие заключается в том, что он Fидет в конец файла, а затем ожидает появления данных после конца, но для канала конец файла наступает только тогда, когда записывающее устройство закрывает файл.

— Жиль "ТАК - перестань быть злым"

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

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

— psusi
источник

Не предназначен для работы на трубах не означает, что не может работать на трубах. Что если приложение просто выполняет SEEK_END, чтобы добраться до конца файла? Или, может быть, он делает SEEK_CUR, чтобы найти текущее местоположение. Ни один из них не вызвал бы никаких проблем, если бы я солгал программе о результатах поиска. Единственное место, которое может сломаться, - это если приложение пытается вернуться назад и перезаписать уже записанные данные, чего не следует делать с файлами журналов. И да, я знаю об ограничении одного процесса на трубу. Это не будет проблемой.

— Патрик

Если все, что он делает, это пытается завершить добавление до конца, тогда он должен просто открыть файл в режиме добавления, чтобы он попал в категорию неработающих. Приложения не пытаются найти текущее местоположение, если им не нужно искать в другом месте, а затем возвращаться к текущему местоположению, поэтому оно попадает в категорию «вы сломаете его, молча провалившись». Маловероятно, что программа вызывает поиск, но на самом деле она не нужна для работы (и если она это делает, она попадает в категорию неисправностей).

— psusi

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

— Патрик

@ Патрик, для первого, если он добавляется, он должен открыть файл в режиме добавления. В этом случае вы говорите о чтении, и в этом случае не имеет смысла пропускать новые данные, которые они еще не прочитали (и молчаливое игнорирование поиска может нарушить это). Что касается последнего, если он пытается использовать поиск, чтобы вернуться в ту же позицию после закрытия и повторного открытия файла, который будет разорван на канале, если вы молча проигнорируете запрос, так как, когда он закрывает канал, сервер получает SIGPIPE, который по-видимому, он сбрасывается, поэтому следующий клиент, открывающий канал, запускается в начале.

— psusi