Czy można sprawić, że operacje seek () na zwrócony potok o nazwie zakończą się powodzeniem?

Czy można to zrobić tak, aby programy próbujące wykonywać seek()operacje na nazwanym potoku powróciły pomyślnie (ale działały tak, jakby potok był pustym plikiem) zamiast „Nielegalne wyszukiwanie”?

Mam ostatnie logowanie do mojego systemu przechowywane w bazie danych SQLite, nigdzie nie mam plików. Jednak istnieje kilka programów, które mają z tym problem. Istnieją 2 konkretne przypadki;

Program chce zapisać do pliku dziennika, który syslog-ng utworzył jako nazwany potok i odczytuje. Program chce wykonać z seek()jakiegoś powodu, a następnie nie powiedzie się.
Program (taki jak denyhosts lub fail2ban) chce czytać z pliku dziennika, który syslog-ng utworzył jako nazwany potok i do którego pisze. Program chce wykonać seek()na nim i kończy się niepowodzeniem.

Idealnie chciałbym, żeby te zachowywały się tak, jakby nazwany potok był tylko pustym plikiem. Nie widzę żadnego powodu, dla którego program piszący dziennik musiałby przeprowadzić wyszukiwanie, powinien po prostu otworzyć plik w celu dołączenia i rozpoczęcia pisania. Rozumiem, dlaczego czytający program chciałby szukać, aby mógł wznowić od swojej ostatniej pozycji, i dlatego chciałbym, aby zachowywał się tak, jakby plik był pusty (jakby został obcięty).

Czy istnieje jakaś opcja, którą można ustawić dla nazwanych potoków, aby zachowywały się w ten sposób? Jeśli nie, czy istnieje tryb, który można ustawić, gdy syslog-ng otwiera potok, aby zachowywał się w ten sposób (jestem otwarty na wprowadzanie zmian w kodzie)? A może jestem potokiem?

pipe syslog

— Patrick
źródło

Odpowiedzi:

Dla jądra Linuksa zaproponowano widoczne rurki, ale nie znam działającej łatki do ich implementacji.

Możesz użyć LD_PRELOADbiblioteki, która zastępuje lseekwywołanie określonych plików. Nie znam żadnego gotowego opakowania do tego celu. Shadowfs może pomóc w napisaniu jednego.

— Gilles „SO- przestań być zły”
źródło

Spróbuję trasy LD_PRELOAD. Nie jest to najlepsze rozwiązanie, ale powinno być wykonalne.

— Patrick,

A tak przy okazji, czy posiadanie widocznej rury byłoby konieczne, aby mniej mogła podążać za rurą w taki sam sposób jak plik? Pytam w kontekście podążania za rurą, używając mniej? pytanie (możesz tam odpowiedzieć).

— Piotr Dobrogost

@PiotrDobrogost W kontekście Fpolecenia w mniej, wystarczy mniej, aby odświeżyć ekran, jeśli nie otrzyma żadnego wyjścia przez około sekundę. Sprawienie, by potoki były widoczne, nie pomogłoby: istotna różnica polega na tym, że Fidzie na koniec pliku, a następnie czeka na pojawienie się danych za końcem - ale w przypadku potoku koniec pliku pojawia się dopiero po zamknięciu pliku przez program piszący.

— Gilles „SO- przestań być zły”

Jeśli aplikacja wywołuje funkcję seek, jest albo zepsuta, albo nie działa na potokach. Jeśli ten pierwszy, to wymaga naprawy. Jeśli to drugie, to oczekuje, że szukanie rzeczywiście zadziała, więc kłamanie i twierdzenie, że zadziałało, gdy nie, prawie na pewno spowoduje nieprawidłowe działanie.

Również jeśli plik dziennika zostanie zastąpiony nazwanym potokiem, tylko jeden proces może odczytać z niego jednocześnie. Zamiast tego powinno to być gniazdo.

— psusi
źródło

Nie przeznaczone do pracy na rurach nie oznacza, że nie mogę pracować na rurach. Co jeśli aplikacja po prostu wykonuje SEEK_END, aby dostać się do końca pliku? A może robi SEEK_CUR, aby znaleźć bieżącą lokalizację. Żaden z nich nie spowodowałby żadnych problemów, gdybym okłamał program o wynikach poszukiwania. Jedyne miejsce, które się zepsułoby, to gdyby aplikacja próbowała cofnąć się i zastąpić już zapisane dane, co nie powinno być zrobione z plikami dziennika. I tak, jestem świadomy ograniczenia jednego procesu na rurę. To nie będzie problem.

— Patrick

Jeśli wszystko, co robi, to do końca dołączać, to po prostu powinno otwierać plik w trybie dołączania, więc należy do kategorii zepsutej. Aplikacje nie próbują znaleźć bieżącej lokalizacji, chyba że muszą szukać innego miejsca, a następnie wracają do bieżącej lokalizacji, więc należy ona do kategorii „złamiesz ją przez cichą awarię”. Jest bardzo mało prawdopodobne, że wywołania programu szukają, ale tak naprawdę nie potrzebują go do działania (a jeśli tak, to należy do zepsutej kategorii).

— psusi

Nie prawda. Wiele aplikacji szuka końca pliku na wypadek, gdyby jakiś inny program zapisał go do pliku od czasu jego ostatniego użycia. W przeciwnym razie pisanie tam, gdzie jest obecnie, blokuje zmiany w innym programie. A jeśli odczytuje z pliku, może użyć SEEK_CUR, aby uzyskać swoją bieżącą lokalizację, aby po uruchomieniu programu program mógł wznowić od miejsca, w którym zakończył.

— Patrick

@Patrick, dla pierwszego, jeśli się dołącza, powinno ponownie otworzyć plik w trybie dołączania. W tym przypadku mówisz o czytaniu, w którym to przypadku nie ma sensu pomijać nowych danych, których jeszcze nie odczytało (a ciche ignorowanie wyszukiwania mogłoby to przerwać). Jeśli chodzi o to drugie, jeśli próbuje użyć funkcji seek, aby powrócić do tej samej pozycji po zamknięciu i ponownym otwarciu pliku, który złamie się na potoku, jeśli po cichu zignorujesz szukanie, ponieważ po zamknięciu potoku serwer otrzymuje SIGPIPE, który przypuszczalnie powoduje zresetowanie, więc następny klient, który otworzy potok, zaczyna od początku.

— psusi