建议文件锁定是否适用于默认文件描述符？答案

【问题标题】：Does advisory file locking work with default file descriptors?建议文件锁定是否适用于默认文件描述符？
【发布时间】：2018-04-05 12:37:54
【问题描述】：

例如，假设我有以下 shell 命令。

~]$ foobar 2>> foobar.log

上述命令将标准错误输出（stderr，或文件描述符2）重定向到文件foobar.log，并附加输出（>> 而不仅仅是>）。

现在，假设两个用户都在运行完全相同的命令。在这种情况下，文件的输出是交错的，因此很难阅读。

程序可以利用“建议文件锁定”（通过fcntl() C 函数）作为操作系统级别的文件互斥，本质上协调多个进程，以便在任何给定时间只有一个进程写入文件.因此，两个进程的输出不再交错，变得更容易阅读。

但是，shell 是如何实现上述调用的呢？如果他们使用pipe() 系统调用，建议文件锁定将不起作用。另一方面，如果他们在调用fork()/exec() 之前使用dup()（或其他一些变体），则建议文件锁定应该起作用。

是哪种情况，建议文件锁定是否应该对 shell 重定向的标准输出（stdout，文件描述符 1）和标准错误（stderr，文件描述符 2）起作用？

【问题讨论】：

您可以检查errno 以了解有关错误的更多详细信息。根据我自己的测试，fcntl(2, F_SETLKW, &lock) 在 linux 上运行良好（当 stderr 是终端时） - 但它也取决于操作系统、文件描述符 2 连接到什么以及您在lock 中提出的参数跨度>
请发minimal reproducible example。
取决于你的 shell，但通常没有锁定，只有 open() 和 O_APPEND 在标志中。

【解决方案1】：

fcntl() 文件锁绑定到进程，而不是线程。因此，锁定附加到仅对该进程可用的东西的文件描述符似乎没有用。不仅没有要锁定的实际文件（例如，机制必须以某种方式有所不同），锁定自己的 stderr 的进程正在与其他人竞争该锁定。

【讨论】：

【解决方案2】：

根据@nos 的评论，这可能取决于操作系统和文件描述符 2 连接到的文件类型。例如，如果标准错误被传送到另一个程序，上述调用将不起作用，如下所示：

~]$ mkfifo pipe
~]$ cat pipe
~]$ foobar 2>> pipe

但是，如果将标准错误重定向到常规文件（如上例所示），那么建议文件的工作似乎确实有效，至少在 Arch Linux 上是这样。

【讨论】：