flock() versus lock file semantics [LWN.net]

flock() versus lock file semantics

Posted Oct 20, 2025 2:45 UTC (Mon) by gdt (subscriber, #6284)
In reply to: flock() versus lock file semantics by chris_se
Parent article: Debian Technical Committee overrides systemd change

> 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.

to post comments

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.