flock() versus lock file semantics

Posted Oct 16, 2025 12:31 UTC (Thu) by chris_se (subscriber, #99706)
In reply to: flock() versus lock file semantics by gdt
Parent article: Debian Technical Committee overrides systemd change

> The device /dev/ttyS0 is open()ed and flock(, LOCK_EX) applied. The terminal program now has exclusive use of the modem and proceeds to use it. Later a line condition causes Data Carrier Detect to drop. The way to reinitiate the modem link is to close() and re-open() the device file: this will drop and then re-assert the Data Terminal Ready line, which makes the modem re-attempt a connection.

You can set the status of the DTR line via TIOCM_DTR on an open device, see also <https://man7.org/linux/man-pages/man2/TIOCMSET.2const.html>. There is no need to close the serial device. This is completely race-free.

I don't think lockfiles are a good idea in any way, shape or form, because especially with modern containerization solutions, the only guarantee you have as a program is that if you can open() and flock() the device, you are allowed access to it. With containers you might not even see the same lock directory as the rest of the system (or another container), whereas you might have access to the same serial device.

Hence I completely agree that getting rid of /var/lock and /run/lock is the right thing to do, it's just that in the current state of affairs this change should be coordinated with other software before the lock directory is phased out, so I do agree with Debian's TC's decision here.

Side note:

Actually, flock(, LOCK_EX) by itself is not sufficient to properly lock a serial port: every time a port is opened on Linux, at least some of the port's settings are reset to their defaults, even if it's already open. So the proper thing to do in my opinion is:

1) First flock(fd, LOCK_EX) it to avoid races
2) second ioctl(fd, TIOCEXCL) to prevent further opens

You need both LOCK_EX and TIOCEXCL: TIOCEXCL prevents the open() command from other processes from working, so that other programs can't open the same device while your program is handling it, preventing some settings to be reset. flock() is still needed regardless, because otherwise you might have a race condition where process A calls open(), then process B calls open(), then process A calls ioctl(), and then process B calls ioctl(), and they both succeed (they would only prevent a process C from calling open() thereafter, the ioctls will both succeed), so use the flock() to avoid that specific race as well.

(Caveat: TIOCEXCL doesn't help against root, but ideally you should run as little stuff as possible as root anyway.)

flock() versus lock file semantics

Posted Oct 20, 2025 2:45 UTC (Mon) by gdt (subscriber, #6284) [Link] (1 responses)

> You can set the status of the DTR line via TIOCM_DTR on an open device

That changes the semantics of the end of a login session from a dial-in modem. The user terminates the shell, and that file close brings down DTR, clearing down the call. To adjust to this behaviour every shell will need to be updated.

Whereas currently the system boot can create a lock file for every dial-in line to prevent its use by programs looking for a dial-out line.

flock() versus lock file semantics

Posted Oct 20, 2025 16:11 UTC (Mon) by hmh (subscriber, #3838) [Link]

These two posts are about the best take-home on the whole issue thus far IMHO (along with the reminder that the old way of setting up /var/lock had it as a separate 5MiB-maximum tmpfs, which is desirable over a default-limit tmpfs).

It is worth considering that using /var/lock to ensure dial-in and dial-out separation, or any other "reservation" can, in the end, be decently implemented by naming the serial devices you want for dial-out differently from the ones for dial-in, etc (udev/mdev/etc are perfectly capable of being configured to do so). Giving it a good UX might not be that easy, though, and going distro-specific here is a major loss.

The point about how classical tty-like devices behave ties in with the way other components (like the shells) work when plugged to a tty is very valuable.