On Mon, Apr 8, 2019, 20:15 Dr. Todor Dimitrov <dimit...@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...) >
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
