在 Linux 中锁定串行端口和其他设备的最佳做法是什么？

Question

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

建议使用 SYSV 样式的 UUCP 设备锁定文件，例如 /var/lock/LCK..ttyS1。这就是Linux Serial HOTWO: Locking Out Others 所推荐的。它也记录在Filesystem Heirarchy Standard 中。由 gtkterm、picocom 等串口终端程序实现。有诸如 liblockdev 和 liblockfile 之类的库来支持这一点（尽管这两个库的实现细节不同）。

但是，我发现 Debian bug #734086，它说在 Linux 上，不推荐使用 SYSV 样式的 UUCP 设备锁，而应该使用 flock() 咨询锁。

但是，除了 Debian 错误本身之外，我找不到可靠的文档来源来描述这些 SYSV 样式 UUCP 设备锁的弃用以及flock() 的推荐。

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

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

Answer 1

据我所知，使用flock(fd, LOCK_EX | LOCK_NB) 锁定串行端口或其他设备可能是 Linux 中最好的方法，紧随 Debian 在Debian bug #734086 中的领先地位。请注意，这项 Debian 变更的最初倡导者 Roger Leigh 在 2014/2015 年已经从 Debian 和 Linux 转移到了 FreeBSD（参见 his comments here）。但是 Debian 似乎坚持使用 flock() 方法，所以这很值得。

但是鉴于此时此更改与更广泛的 Linux 社区的沟通非常糟糕，支持较旧的 SYSV 样式 UUCP 设备锁定文件 (/var/lock/LCK..ttyS1) 作为编译时选项可能会很好，以供使用在仍在使用旧锁定方法的系统中。

例如picocom 现在已更改为使用 flock() 方法，编译时可选择 SYSV 样式的 UUCP 设备锁定文件。

Another answer on StackOverflow 描述了两种方法：

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

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

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

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