Bug#991639: udev: 80-debian-compat.rules can yield non-stable and inconsistent symlinks

[Michael Biebl]

Am 29.07.21 um 17:53 schrieb Vincent Lefevre:
> On 2021-07-29 17:05:23 +0200, Michael Biebl wrote:
>> Am 29.07.21 um 16:33 schrieb Vincent Lefevre:
>>> On 2021-07-29 16:20:48 +0200, Michael Biebl wrote:
>>>> And the comment from 2017 still holds true:
>>>> https://lists.debian.org/debian-user/2017/04/msg00790.html
>>>>
>>>> "
>>>> See the comment in there:
>>>>
>>>> # These rules will create symlinks for CD/DVD drives, to help old
>>>> # programs which are unable to automatically discover the devices.
>>>> # The first detected device gets the symlink, but this is not stable across
>>>> # reboots.
>>>>
>>>> So, yes, what you see can happen depending on the order devices are
>>>> discovered.
>>>> "
>>>>
>>>> The kernel hasn't changed. It still probes devices asynchronously.
>>>> There is not much we can do about that.
>>>
>>> The comment says: "The first detected device gets the symlink".
>>> If this were true, all symlinks would be the same (even though
>>> this would not be stable), which is not the case.
>>>
>>> BTW, aren't the devices numbered 0, 1, etc. in the order they are
>>> detected, so that one would expect always sr0 here?
>>
>> It appears you do not believe what I said. Feel free to propose a patch.
> 
> This is not a question of belief, but of logic. Either sr0 or sr1 is the
> first detected device. Thus the 3 symlinks added by 80-debian-compat.rules
> are expected to be the same (possibly different from "sr0", which is
> hardcoded to "sr0" in 60-cdrom_id.rules).

This is a misunderstanding. Devices are detected asynchronously, which 
also means they can be processed in parallel (by independent udev worker 
processes).
So it can very well be, that one udev worker processes the first line 
and the second udev worker skipping the first line due to the failing 
condition but processes the second line. There is no locking around 
those 3 lines which would mean they are always processed en bloc.

Anyway, I'll just drop those rules so this issue will be gone for good.

Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20210729/33076a52/attachment-0001.sig>