È possibile eseguire correttamente le operazioni seek () su un ritorno di pipe denominato?

Esiste un modo per farlo in modo che quando i programmi tentano di eseguire seek()operazioni su una named pipe tornerà a buon fine (ma agisce come se la pipe fosse un file vuoto) anziché "Ricerca illegale"?

Ho tutti gli ultimi bit di registrazione sul mio sistema memorizzati in un database SQLite, non ho file da nessuna parte. Tuttavia, ci sono alcuni programmi che hanno problemi con questo. Ci sono 2 casi specifici;

Un programma vuole scrivere su un file di registro che syslog-ng ha creato come pipe denominata e da cui sta leggendo. Il programma vuole eseguire un seek()per qualche motivo e poi fallisce.
Un programma (come denyhosts o fail2ban) vuole leggere da un file di registro che syslog-ng ha creato come pipe denominata e su cui sta scrivendo. Il programma vuole eseguirne uno seek()e fallisce.

Idealmente, mi piacerebbe che questi tentativi si comportassero come se la pipe denominata fosse solo un file vuoto. Non vedo alcun motivo per cui un programma che scrive un registro dovrebbe comunque eseguire una ricerca, dovrebbe solo aprire il file per aggiungere e iniziare a scrivere. Vedo perché una lettura di programma vorrebbe cercare, in modo che potesse riprendere dalla sua ultima posizione, e quindi vorrei che si comportasse come se il file fosse vuoto (come se fosse stato troncato).

Quindi c'è qualche opzione che può essere impostata su named pipe per farli comportare in questo modo? Altrimenti esiste una modalità che può essere impostata quando syslog-ng apre la pipe per farlo funzionare in questo modo (sono aperto a fare modifiche al codice)? O sono su un torrente?

pipe syslog

— Patrick
fonte

Risposte:

Sono state proposte pipe ricercabili per il kernel Linux, ma non sono a conoscenza di una patch funzionante per implementarle.

È possibile utilizzare una LD_PRELOADlibreria "ed" che sovrascrive la lseekchiamata su file specifici. Non conosco alcun involucro standard per questo scopo. Shadowfs potrebbe aiutare a scriverne uno.

— Gilles 'SO- smetti di essere malvagio'
fonte

Proverò il percorso LD_PRELOAD. Non è la soluzione migliore, ma dovrebbe essere fattibile.

— Patrick,

A proposito, sarebbe necessario cercare pipe per meno per poter seguire pipe nello stesso modo in cui può seguire il file? Sto chiedendo nel contesto di Segui una pipa usando meno? domanda (potresti preferire rispondere lì).

— Piotr Dobrogost,

@PiotrDobrogost Nel contesto del Fcomando in meno, sarebbe sufficiente per meno per aggiornare lo schermo se non ottiene alcun risultato per un secondo circa. Rendere le pipe ricercabili non sarebbe d'aiuto: la differenza rilevante è che Fva alla fine del file, quindi attende che i dati appaiano oltre la fine - ma per una pipe, la fine del file arriva solo quando lo scrittore chiude il file.

— Gilles 'SO- smetti di essere malvagio' il

Se l'applicazione sta chiamando seek, allora è rotta o non è pensata per funzionare su pipe. Se il primo, allora ha bisogno di essere riparato. In quest'ultimo caso, si aspetta che la ricerca funzioni davvero, quindi mentire e affermare che ha funzionato quando non ha quasi certamente causato un funzionamento errato.

Inoltre, se il file di registro viene sostituito con una pipe denominata, solo un processo alla volta può leggere da esso. Dovrebbe essere invece un socket.

— psusi
fonte

Non significa lavorare su tubi non significa non poter lavorare su tubi. Che cosa succede se l'applicazione sta semplicemente eseguendo un SEEK_END per arrivare alla fine del file? O forse sta facendo un SEEK_CUR per trovare la posizione corrente. Nessuno di questi causerebbe problemi se mentissi al programma sui risultati della ricerca. L'unico posto che si spezzerebbe sarebbe se l'applicazione stesse tentando di tornare indietro e sovrascrivere i dati già scritti che non dovrebbe fare con i file di registro. E sì, sono a conoscenza della limitazione di un processo per tubo. Questo non sarà un problema.

— Patrick,

Se tutto ciò che fa è cercare fino alla fine di aggiungere, allora dovrebbe solo aprire il file in modalità append, quindi rientra nella categoria interrotta. Le applicazioni non provano a trovare la posizione corrente a meno che non debbano essere in grado di cercare altrove, quindi tornano alla posizione corrente, quindi rientra nella categoria "la interromperai in caso di errore silenzioso". È molto improbabile che le chiamate di un programma cerchino ma non ne hanno davvero bisogno per funzionare (e se lo fa, rientra nella categoria non funzionante).

— psusi,

Non vero. Molte applicazioni cercano la fine del file nel caso in cui qualche altro programma abbia scritto sul file dall'ultima volta. Altrimenti scrivere dove è attualmente bloccherebbe le modifiche dell'altro programma. E se la sua lettura dal file, potrebbe essere necessario utilizzare SEEK_CUR per ottenere la posizione corrente in modo che quando il programma viene riavviato, possa riprendere da dove era stato interrotto.

— Patrick,

@Patrick, per il primo, se lo sta aggiungendo, dovrebbe riaprire il file in modalità append. In questo caso stai parlando di lettura, nel qual caso, non ha senso saltare nuovi dati che non ha ancora letto (e ignorare silenziosamente la ricerca lo spezzerebbe). Per quanto riguarda quest'ultimo, se sta provando a usare cerca di tornare nella stessa posizione dopo aver chiuso e riaperto il file che si romperà su una pipe se ignori silenziosamente la ricerca, poiché quando chiude la pipe il server ottiene un SIGPIPE, che presumibilmente lo ripristina, quindi il client successivo che apre la pipe inizia all'inizio.

— psusi,