É possível fazer com que as operações de busca () em um pipe nomeado retornem com êxito?

Existe alguma maneira de fazê-lo para que, quando os programas tentem executar seek()operações em um pipe nomeado, ele volte com êxito (mas aja como se o pipe fosse um arquivo vazio) em vez de 'Busca ilegal'?

Tenho todo o último logon do meu sistema armazenado em um banco de dados SQLite, não tenho arquivos em lugar nenhum. No entanto, existem alguns programas que têm problemas com isso. Existem 2 casos específicos;

Um programa deseja gravar em um arquivo de log que o syslog-ng criou como um pipe nomeado e está lendo. O programa deseja executar um seek()por algum motivo e depois falha.
Um programa (como denyhosts ou fail2ban) deseja ler de um arquivo de log que o syslog-ng criou como um pipe nomeado e está gravando. O programa quer executar um seek()e falhar.

Idealmente, eu gostaria que essas buscas se comportassem como se o pipe nomeado fosse apenas um arquivo vazio. Não vejo nenhuma razão para que um programa que esteja escrevendo um log precise executar uma busca de qualquer maneira, ele deve apenas abrir o arquivo para anexar e começar a escrever. Eu posso ver por que uma leitura de programa gostaria de procurar, para que pudesse retomar de sua última posição, e gostaria que ele se comportasse como se o arquivo estivesse vazio (como se tivesse sido truncado).

Então, existe alguma opção que pode ser definida em pipes nomeados para que eles se comportem dessa maneira? Caso contrário, existe um modo que pode ser definido quando o syslog-ng abre o canal para que ele se comporte dessa maneira (estou aberto a fazer alterações no código)? Ou eu estou subindo um riacho?

pipe syslog

— Patrick
fonte

Respostas:

Os pipes pesquisáveis foram propostos para o kernel do Linux, mas não estou ciente de um patch funcional para implementá-los.

Você pode usar uma LD_PRELOADbiblioteca que substitui a lseekchamada em arquivos específicos. Não conheço nenhum invólucro disponível para esse fim. Shadowfs pode ajudar a escrever um.

— Gilles 'SO- parar de ser mau'
fonte

Vou tentar a rota LD_PRELOAD. Não é a melhor solução, mas deve ser factível.

— 224 Patrick Patrick

Btw, seria necessário um canal procurável para que menos pudesse seguir o canal da mesma maneira que pode seguir um arquivo? Estou perguntando no contexto de Siga um pipe usando menos? pergunta (você pode preferir responder lá).

— Piotr Dobrogost

@PiotrDobrogost No contexto do Fcomando em menos, seria suficiente que menos atualizasse a tela se ela não obtiver nenhuma saída por um segundo ou mais. Tornar os tubos procuráveis não ajudaria: a diferença relevante existe Fno final do arquivo e aguarda a exibição dos dados após o final - mas, no caso de um pipe, o fim do arquivo só ocorre quando o gravador fecha o arquivo.

— Gilles 'SO- stop be evil'

Se o aplicativo estiver chamando de busca, ele está quebrado ou não deve funcionar em tubulações. Se o primeiro, então ele precisa ser corrigido. Nesse último caso, espera que a busca realmente funcione; portanto, mentir e afirmar que funcionou quando não o fez quase certamente causará operação incorreta.

Além disso, se o arquivo de log for substituído por um pipe nomeado, somente um processo poderá ler a partir dele por vez. Deve ser um soquete.

— psusi
fonte

Não se destina a trabalhar em tubos, não significa que não pode trabalhar em tubos. E se o aplicativo estiver simplesmente executando um SEEK_END para chegar ao final do arquivo? Ou talvez esteja fazendo um SEEK_CUR para encontrar a localização atual. Nenhum deles causaria problemas se eu mentisse para o programa sobre os resultados da busca. O único lugar que seria interrompido é se o aplicativo estivesse tentando voltar e substituir os dados já gravados, o que não deveria estar fazendo com os arquivos de log. E sim, estou ciente da limitação de um processo por tubo. Isso não será um problema.

— 315 Patrick Patrick

Se tudo o que faz é procurar anexar ao final, basta abrir o arquivo no modo anexar, para que caia na categoria quebrada. Os aplicativos não tentam encontrar o local atual, a menos que precisem procurar em outro lugar e, em seguida, retornam ao local atual, de modo que caem na categoria "você quebrará por falha silenciosa". É muito improvável que um programa chamado procure, mas realmente não precise que ele funcione (e, se o fizer, cai na categoria quebrada).

— Psusi

Não é verdade. Muitos aplicativos procuram o final do arquivo, caso algum outro programa tenha gravado no arquivo desde a última vez. Caso contrário, a escrita de onde está atualmente atrapalha as alterações do outro programa. E, se estiver lendo o arquivo, convém usar SEEK_CUR para obter sua localização atual, para que, quando o programa for reiniciado, ele possa continuar de onde parou.

— 626 Patrick

@Patrick, para o primeiro, se estiver anexando, deverá reabrir o arquivo no modo de acréscimo. Nesse caso, você está falando sobre leitura; nesse caso, não faz sentido ignorar novos dados que ainda não foram lidos (e ignorar silenciosamente a busca seria uma quebra). Quanto ao último, se estiver tentando usar, procure retornar à mesma posição depois de fechar e reabrir o arquivo que irá quebrar em um canal se você silenciosamente ignorar a busca, pois quando ele fecha o canal o servidor recebe um SIGPIPE, que presumivelmente, ela é redefinida para que o próximo cliente que abre o tubo comece no início.

— Psusi