Чи можна зробити операції пошуку () на поверненні названої труби успішними?


12

Чи є спосіб зробити так, що коли програми намагаються виконувати seek()операції над названою трубкою, він повернеться успішним (але діятиме так, ніби труба була порожнім файлом), а не "Незаконний пошук"?

У мене кожен останній невеликий вміст входу в мою систему зберігається в базі даних SQLite, я ніде не маю файлів. Однак є кілька програм, які мають проблеми з цим. Є 2 конкретні випадки;

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

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

То чи є якийсь варіант, який можна встановити на названі труби, щоб змусити їх вести себе таким чином? Якщо ні, чи існує режим, який можна встановити, коли syslog-ng відкриває трубу, щоб вона вела себе таким чином (я відкрита для внесення змін до коду)? Або я під витоком?

Відповіді:


10

Для ядра Linux були запропоновані пошукові труби, але мені не відомий робочий патч для їх реалізації.

Ви можете використовувати LD_PRELOAD"ed-бібліотеку", яка перекриває lseekвиклик певних файлів. Я не знаю жодної непотрібної обгортки для цієї мети. Shadowfs може допомогти в написанні.


1
Я спробую маршрут LD_PRELOAD. Не найбільше рішення, але повинно бути виконаним.
Патрік

Btw, чи потрібна буде шукана труба, щоб менше могло слідкувати за трубою так само, як і за файлом? Я запитую в контексті " Follow a pipe", використовуючи менше? питання (ви могли б там відповісти).
Пьотр Доброгост

@PiotrDobrogost У контексті Fкоманди менше, достатньо буде менше, щоб оновити екран, якщо він не отримує жодного результату на секунду або близько того. Здійснення пошуку труб не допоможе: відповідна різниця полягає в тому, що Fйде в кінці файлу, а потім чекає, коли дані з’являться минулого кінця - але для труби кінець файлу настає лише тоді, коли автор закриє файл.
Жил "ТАК - перестань бути злим"

1

Якщо програма викликає пошук, то вона або зламана, або не призначена для роботи на трубах. Якщо колишній, то його потрібно виправити. Якщо останній, то він очікує, що прагнення насправді працює, тому брехня і твердження, що вона працювала тоді, коли це не призведе майже допевно, призведе до неправильної роботи.

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


2
Не призначений для роботи на трубах, не означає, що не може працювати на трубах. Що робити, якщо програма просто робить SEEK_END, щоб дістатися до кінця файлу? Або, можливо, це робить SEEK_CUR для пошуку поточного місця. Жодне з них не спричинило б жодних проблем, якби я брехав програмі про результати пошуку. Єдине місце, яке може зламатися - це якщо програма намагалася повернутися назад і перезаписати вже написані дані, які вона не повинна робити з файлами журналів. І так, я знаю обмеження одного процесу на трубу. Це не буде проблемою.
Патрік

1
Якщо все, що він робить, це прагнути до кінця додати, то він повинен просто відкривати файл у режимі додавання, щоб він потрапляв у розбиту категорію. Програми не намагаються знайти поточне місце розташування, якщо їм не потрібно буде шукати десь інше, а потім повернутися до поточного місця, тому він потрапляє до категорії "Ви зламаєте його, мовчки не виходячи з ладу". Це дуже малоймовірно , що програма викликає шукати , але не на самому ділі потрібно працювати (і якщо це станеться, він потрапить в розбитій категорії).
psusi

1
Неправда. Багато додатків прагнуть до кінця файлу, якщо якась інша програма записала у файл з моменту останнього. В іншому випадку написання місця, де його зараз знаходиться, призведе до зменшення змін інших програм. І якщо його зчитування з файлу, воно може захотіти використовувати SEEK_CUR, щоб отримати його поточне місце, щоб після запуску програми резервного копіювання програма може відновитись там, де вона припинилася.
Патрік

1
@Patrick, для першого, якщо він додається, слід перезапустити файл у режимі додавання. У цьому випадку ви говорите про читання, і в цьому випадку не має сенсу пропускати нові дані, які він ще не прочитав (і мовчки ігнорування спроби порушить це). Що стосується останнього, якщо він намагається використати прагнення повернутися до того ж положення після закриття та повторного відкриття файлу, який розірветься на трубі, якщо ви мовчки ігноруєте пошук, оскільки при закритті труби сервер отримує SIGPIPE, який імовірно, він робить його скинутим, тому наступний клієнт, який відкриває трубу, починається на початку.
psusi
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.