[systemd-devel] udev - device nodes removed even if created/copied from /lib/udev/devices/

[Dr. Todor Dimitrov]

> Support for /lib/dev/devices has been removed in systemd 183, see NEWS
> file, i.e. in 2012, seven years ago.
> 
> Support for "ignore_remove" has been removed in udev 152, nine years
> ago, see its announcement back then.

We are working with a system from 2010 (kernel 2.6.34, udev 161). Unfortunately, it cannot be updated!

> You can use tmpfiles.d/ snippets to create device nodes manually if
> you like. if you do, they are created from userspace and then not
> deleted by the kernel, since the kernel doesn't remove device nodes
> created from userspace. Also, udev itself never deletes device nodes
> either.
> 
> But do note that using tmpfiles.d/ for this is racy: if the device
> already exists, tmpfiles.d won't delete it and reacreated it, hence
> depending on initialization timing it sometimes is the kernel that
> created the device node, and sometimes userspace, and hence you know.

I guess tmpfiles.d/ is not a thing on such an old system.

> Moreover, do note that device node major/minor are generally assumed
> to be entirely dynamic these days, hence it's problematic to
> pre-create most device nodes these days, in particular on hotpluggy
> subsystems which operate with fully dynamic major/minors.
> 
> Hence, it's not really a great idea to do what you do. Interfering
> from userspace into an allocation scheme and naming scheme owned by
> the kernel is problematic. Yes, you can get away with a certain amount
> of akwardness but it's ugly in any case. Doing the tmpfiles.d/ thing
> to create device nodes is fully safe only on subsystems that never got
> updated to the driver model properly (which I think is the lp0 driver
> but nothing of relevance today, except nvidia drivers).


The device nodes are not created by the kernel (modules) but rather by udev. The usb-serial driver allocates minor numbers sequentially, nothing fancy there. Moreover, it will reuse them when they are freed, i.e. when a device is unplugged.

> Why would you bind mount a device node that references a non-existing
> device into a container?

This is necessary for unprivileged containers (run by an unprivileged user), which are not able to create device nodes after boot. So these have to be bind mounted on start, even if the nodes are not "occupied". This works perfectly fine. In this particular case, we can probably work around this issue since the kernel is way too old for running unprivileged containers.

I’ve looked inside the udev 161 code and it seems that the device nodes will be removed no matter what. I wonder whether there is some other way to prevent udev from deleting the device nodes. Maybe somehow stop the event propagation?

Thanks,
Todor

> On 8. Apr 2019, at 18:04, Lennart Poettering <lennart at poettering.net> wrote:
> 
> On Mo, 08.04.19 15:59, Dr. Todor Dimitrov (dimitrov at technology.de) wrote:
> 
>> Hello,
>> 
>> we are observing a weird problem with udev, where the nodes
>> /dev/ttyUSB* are removed as soon as the corresponding devices are
>> unplugged, although they have been statically created using
>> /lib/udev/devices/. According to the documentation/change logs, this
>> should not happen:
> 
> Support for /lib/dev/devices has been removed in systemd 183, see NEWS
> file, i.e. in 2012, seven years ago.
> 
> Support for "ignore_remove" has been removed in udev 152, nine years
> ago, see its announcement back then.
> 
> You can use tmpfiles.d/ snippets to create device nodes manually if
> you like. if you do, they are created from userspace and then not
> deleted by the kernel, since the kernel doesn't remove device nodes
> created from userspace. Also, udev itself never deletes device nodes
> either.
> 
> But do note that using tmpfiles.d/ for this is racy: if the device
> already exists, tmpfiles.d won't delete it and reacreated it, hence
> depending on initialization timing it sometimes is the kernel that
> created the device node, and sometimes userspace, and hence you know.
> 
> Moreover, do note that device node major/minor are generally assumed
> to be entirely dynamic these days, hence it's problematic to
> pre-create most device nodes these days, in particular on hotpluggy
> subsystems which operate with fully dynamic major/minors.
> 
> Hence, it's not really a great idea to do what you do. Interfering
> from userspace into an allocation scheme and naming scheme owned by
> the kernel is problematic. Yes, you can get away with a certain amount
> of akwardness but it's ugly in any case. Doing the tmpfiles.d/ thing
> to create device nodes is fully safe only on subsystems that never got
> updated to the driver model properly (which I think is the lp0 driver
> but nothing of relevance today, except nvidia drivers).
> 
>> Any help or suggestions are highly appreciated. We need the device
>> nodes to be static since we are bind mounting them inside a
>> container.
> 
> Why would you bind mount a device node that references a non-existing
> device into a container?
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3868 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20190408/f4b4630b/attachment.bin>