Details of serial port locking / UUCP locking

[kaechele]

Currently, as far as I can tell, gensio only implements its own UUCP-style locking mechanism.

It seems that at least on Linux there are other (and possibly better) ways of locking serial ports.
There was an effort within Debian in 2014 to streamline this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734086
From this discussion one of the participants developed some recommendations for best practices around this issue: https://stackoverflow.com/questions/30316722/what-is-the-best-practice-for-locking-serial-ports-and-other-devices-in-linux

1. Would it be beneficial for gensio to support flock(1) based locking of serial ports on Linux, given that the information above suggests it could be more robust?
2. Would using liblockdev be beneficial on distributions that utilize it more or less consistently (like Fedora)?

It is my understanding, that when using flock(1) UUCP-style locking (with or without liblockdev) can still occur to support programs that use or require it as it does not interfere with programs that ignore it.

Less relevant context on why I bring this up

ser2net recently started shipping a systemd unit file.
In this unit file there is a definition of a User and a Group. In trying to incorporate this in my Fedora package I noticed that ser2net would not be able to write to /var/lock, gensio's default UUCP lock path, unless ser2net was run as root. So I looked into the issue further and found that most other software in Fedora uses lockdev (and liblockdev) to facilitate UUCP-style locking and the path to use for that would be /run/lock/lockdev, which is group writeable by users in the lock group.
So I fixed the issue as suggested in the gensio README: by creating a ser2net user and adding it to both the dialout and lock groups and compiling gensio with the --with-uucp-locking=/run/lock/lockdev option.

[cminyard]

On Tue, Jul 25, 2023 at 10:27:54AM -0700, Felix Kaechele wrote: Currently, as far as I can tell, gensio only implements [its own UUCP-style locking mechanism](https://github.com/cminyard/gensio/blob/master/lib/uucplock.c).

Yes, when I started all this nothing else was available. I followed the available practices that other programs used. That was a long time ago...

It seems that at least on Linux there are other (and possibly better) ways of locking serial ports. There was an effort within Debian in 2014 to streamline this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734086 From this discussion one of the participants developed some recommendations for best practices around this issue: https://stackoverflow.com/questions/30316722/what-is-the-best-practice-for-locking-serial-ports-and-other-devices-in-linux

Well, what a mess. I wonder why nobody contacted me about this.

1. Would it be beneficial for gensio to support `flock(1)` based locking of serial ports on Linux, given that the information above suggests it could be more robust?

Yes, that makes sense. I can add that.

2. Would using `liblockdev` be beneficial on distributions that utilize it more or less consistently (like Fedora)?

Maybe, but I still probably need to implement file-based locking, too, even on Debian. And I can see that liblockdev is no longer available. If I have to implement it, anyway, I might as well just use what I've implement. I should add the SvR4 style locking, too.

It is my understanding, that when using `flock(1)` UUCP-style locking (with or without `liblockdev`) can still occur to support programs that use or require it as it does not interfere with programs that ignore it.

Yes, I believe they can co-exist. And I agree that it's more robust. I wonder if you can do this on other *nix systems... I'll plan on this in the next release.

<details> <summary>Less relevant context on why I bring this up</summary> `ser2net` recently started shipping a [systemd unit file](cminyard/ser2net@f98e6e5). In this unit file there is a definition of a `User` and a `Group`. In trying to incorporate this in my Fedora package I noticed that ser2net would not be able to write to `/var/lock`, gensio's default UUCP lock path, unless ser2net was run as root. So I looked into the issue further and found that most other software in Fedora uses `lockdev` (and `liblockdev`) to facilitate UUCP-style locking and the path to use for that would be `/run/lock/lockdev`, which is group writeable by users in the `lock` group. So I fixed the issue [as suggested in the gensio README](https://github.com/cminyard/gensio/blob/8ee436e17502c283943d98adac8772b3ff6e8138/README.rst?plain=1#L111): by [creating a `ser2net` user and adding it to both the `dialout` and `lock` groups](https://src.fedoraproject.org/rpms/ser2net/blob/rawhide/f/ser2net.sysusers) and compiling gensio with the `--with-uucp-locking=/run/lock/lockdev` option.

Yes, that works, and is probably the best practice. Thanks for bringing this up.

…

-corey

</details> -- Reply to this email directly or view it on GitHub: #65 You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[cminyard]

SVr4 and flock locking is now added. Thanks again.