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

[Mantas Mikulėnas]

On Mon, Apr 8, 2019, 20:15 Dr. Todor Dimitrov <dimitrov at technology.de>
wrote:

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

If the device numbers are sufficiently static that you can hardcode them in
/lib/udev/devices, why not avoid udev's and/or the kernel's handling of
that node entirely by using a different non-conflicting filename for it?
They shouldn't be creating nor removing /dev/ttyUSB0static, for example.


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

If that's the *only* purpose of the device node's existence, then it
doesn't have to live in /dev in the first place, does it? It could be bound
from /dev/containerstuff or even directly from /lib.



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

IMO, just build a local version with the code disabled. (If you have to
maintain such an old version, chances are it's something you'll need to do
sooner or later anyway...)

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20190409/7abaaecf/attachment-0001.html>