命名管道上的eek()操作是否可以成功返回？

Question

有什么方法可以使当程序尝试seek()在命名管道上执行操作时它将成功返回（但就像管道是一个空文件一样）而不是“非法查找”？

我的系统上的所有日志记录都存储在 SQLite 数据库中，我在任何地方都没有文件。然而，有一些程序在这方面遇到了麻烦。具体有2种情况；

• 程序想要写入 syslog-ng 作为命名管道创建并正在读取的日志文件。该程序由于某种原因想要执行 a seek()，然后失败了。
• 程序（例如denyhosts或fail2ban）想要读取syslog-ng已创建为命名管道并正在写入的日志文件。该程序想要seek()对其执行操作但失败了。

理想情况下，我希望这些搜索的行为就像命名管道只是一个空文件一样。我看不出为什么写入日志的程序需要执行查找，它应该只打开文件进行追加并开始写入。我可以理解为什么程序读取想要查找，以便它可以从最后的位置恢复，所以我希望它的行为就像文件是空的一样（就像它被截断一样）。

那么是否可以在命名管道上设置一些选项来让它们以这种方式运行？如果没有，当 syslog-ng 打开管道时是否可以设置一种模式，使其以这种方式运行（我愿意更改代码）？还是我在小溪里？

Answer 1

已经为 Linux 内核提出了可查找管道，但我不知道有可用的补丁来实现它们。

你可以使用LD_PRELOAD'ed 库覆盖lseek对特定文件的调用。我不知道有任何现成的包装纸可以用于此目的。影子文件系统可能有助于写一篇。

Answer 2

如果应用程序正在调用seek，那么它要么已损坏，要么不适用于管道。如果是前者，则需要修复。如果是后者，那么它期望搜索真正起作用，因此撒谎并声称它在没有起作用时几乎肯定会导致错误的操作。

此外，如果日志文件被替换为命名管道，则一次只有一个进程可以从中读取。它应该是一个套接字。