在Linux中，锁定串口和其他设备的最佳实践是什么？

Question

目标是“锁定”串行设备或其他Linux设备的访问，以确保在使用设备时对设备进行独占式访问。这可以防止两个程序同时打开同一串行设备并“竞争”读取设备中的字节。

建议使用SYSV风格的UUCP设备锁文件，例如 `/var/lock/LCK..ttyS1`。这是 Linux Serial HOWTO: Locking Out Others 推荐的方法，并在Filesystem Hierarchy Standard 中有所记录。它由串行终端程序如 gtkterm、picocom 实现。也有一些库支持这种方式，如liblockdev和liblockfile（尽管这两个库之间的实现细节有所不同）。

然而，我发现 Debian bug #734086，它说在Linux上，SYSV风格的UUCP设备锁已经被弃用，应该改用 flock() 推荐的咨询锁。

然而，除了Debian bug本身之外，我找不到可靠的文档来源来描述这些SYSV风格的UUCP设备锁的弃用和flock() 的推荐使用。

我还发现了ioctl(fd, TIOCEXCL)，它被screen实用程序用于锁定终端。

在Linux中，锁定串口和其他设备的现代“最佳实践”是什么？我们在哪里可以找到描述这一点的最新文档？

- Craig McQueen

---

我看到这篇文章因为“主要基于观点”而受到了紧密的投票。但是，为了使用像UUCP锁文件或flock()这样的东西来实现串口锁定（两者都是“咨询性的”），所有程序都使用相同的方法非常重要，否则锁定将无法工作。例如，如果一个程序使用UUCP文件锁，另一个程序使用flock()，那么锁定就无效了，两个程序都可以打开端口。因此，在Linux社区达成共识对于这个实用上重要的问题是非常重要的。 - Craig McQueen

Answer 1

据我所知，在Linux中，使用flock(fd, LOCK_EX | LOCK_NB)锁定串口或其他设备可能是最好的选择，遵循Debian在Debian bug #734086中的领导。请注意，这个Debian变化的原倡导者Roger Leigh在2014/2015年已经转向FreeBSD（参见此处的评论）。但是，Debian似乎仍然坚持使用flock()方法，这值得一些东西。

然而，考虑到目前这种变化如何向更广泛的Linux社区传达得很差，因此支持旧的SYSV风格的UUCP设备锁文件（/var/lock/LCK..ttyS1）作为编译时选项可能是有好处的，用于仍在使用旧锁定方法的系统。

例如，picocom现在已经更改为使用flock()方法，并可选选择SYSV风格的UUCP设备锁文件。

StackOverflow上的另一个答案描述了两种方法：

1. ioctl(fd, TIOCEXCL)
2. flock(fd, LOCK_EX | LOCK_NB)方法

它说“应用程序可以选择一个或两个”，进一步解释道：

同时使用两者的原因是为了检测是否已经有另一个进程打开了设备而没有将其放入独占模式，但希望设置了咨询锁定。在这种情况下，open()和ioctl()都成功，但flock()失败。

因此，值得另外实现ioctl(fd, TIOCEXCL)。

- Craig McQueen