<div dir="auto"><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Mon, Apr 8, 2019, 20:15 Dr. Todor Dimitrov <<a href="mailto:dimitrov@technology.de">dimitrov@technology.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Support for /lib/dev/devices has been removed in systemd 183, see NEWS<br>
> file, i.e. in 2012, seven years ago.<br>
> <br>
> Support for "ignore_remove" has been removed in udev 152, nine years<br>
> ago, see its announcement back then.<br>
<br>
We are working with a system from 2010 (kernel 2.6.34, udev 161). Unfortunately, it cannot be updated!<br>
<br>
> You can use tmpfiles.d/ snippets to create device nodes manually if<br>
> you like. if you do, they are created from userspace and then not<br>
> deleted by the kernel, since the kernel doesn't remove device nodes<br>
> created from userspace. Also, udev itself never deletes device nodes<br>
> either.<br>
> <br>
> But do note that using tmpfiles.d/ for this is racy: if the device<br>
> already exists, tmpfiles.d won't delete it and reacreated it, hence<br>
> depending on initialization timing it sometimes is the kernel that<br>
> created the device node, and sometimes userspace, and hence you know.<br>
<br>
I guess tmpfiles.d/ is not a thing on such an old system.<br>
<br>
> Moreover, do note that device node major/minor are generally assumed<br>
> to be entirely dynamic these days, hence it's problematic to<br>
> pre-create most device nodes these days, in particular on hotpluggy<br>
> subsystems which operate with fully dynamic major/minors.<br>
> <br>
> Hence, it's not really a great idea to do what you do. Interfering<br>
> from userspace into an allocation scheme and naming scheme owned by<br>
> the kernel is problematic. Yes, you can get away with a certain amount<br>
> of akwardness but it's ugly in any case. Doing the tmpfiles.d/ thing<br>
> to create device nodes is fully safe only on subsystems that never got<br>
> updated to the driver model properly (which I think is the lp0 driver<br>
> but nothing of relevance today, except nvidia drivers).<br>
<br>
<br>
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.<br></blockquote></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Why would you bind mount a device node that references a non-existing<br>
> device into a container?<br>
<br>
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.<br></blockquote></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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?<br>
<br>
Thanks,<br>
Todor<br></blockquote></div><div dir="auto"><br></div><div dir="auto">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...)</div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div>