Bugzilla Bug 221253

The current startup scripts do not load the Unix Domain Sockets module before
udev is started. This causes the udevd startup to fail on kernels using Unix
Domain Sockets as a module.


Reproducible: Always




A modification to the file /lib/rcscripts/addons/udev-start.sh , which is part
of the udev package would fix this problem:

Modify the /lib/rcscripts/addons/udev-start.sh script, adding a modprobe line
before running udevd. Locate the udevd command and add a modprobe line above
it, as shown below:

  ebegin "Starting udevd"
  modprobe unix           # < ---- ADD THIS LINE TO LOAD UNIX DOMAIN SOCKETS
  /sbin/udevd --daemon
  eend $?

Making this change allows Unix Domain Sockets to be used as a module.

why is this assigned to me?  I'm not in charge of either udev or the kernel
package anymore...

Also, why would you want to make this a module?  You always need the code for
this, why not just build it into the kernel?

Do we really need this?
Shouldn't the kernel autoload this when unix-domain sockets are tried to be
used?

Added this to udev-122-r1.

What is the reason you want to put Unix Domain sockets in as a module in the
first place? Is it because you get a udev error that does not create all the
devices? We had that problem yesterday night ;) and the solution is very simple
(after hours of searching after midnight): emerge -C hotplug. The question is:
Why does the udev Version 119 in Gentoo not automatically do "emerge -C
hotplug". Once hotplug was gone all was fine! This should really be done by
Gentoo! Daniel Robbins is right: Something with the management at Gentoo is
less then perfect!

Best
Zeno

Cool it with the conspiracy theories and the tirades. Bugs happen.
Additionally, this has been documented for years that you shouldn't have
hotplug on your system with udev any longer. Learn to read the documentation.
And lastly, as with all other package managers, installing one package or
upgrading a package will not suddently delete a package.

Additionally, if you have anything PRODUCTIVE to add, stick it in an open bug
rather then a closed bug.

Thank you for your reply. I am sticking this right here because I bounced into
this bug yesterday after midnight but it did not help me any further. I believe
I am not the last person who will bounce into this and I hope he or she will
find this message and the solution after 10 min and not after 10 hours.

These are my five cents to this problem. I do not quite understand if you
considers this a bug or if you consider me stupid. But if you consider me
stupid then I believe it is better to adjust to the stupid users and make life
easier for them (you will have a bigger audience). 

Anyway, I also filed a separate bug report, as recommend by you. As a kind
gesture, can you please point me to the HowTo / Documentation that you claim I
did not find or did not read?

Thank you very much for your Feedback.

Best
Zeno

PS: Installing something critically important as udev without even being told
that you should consider uninstalling hotplug - to me is a real hot-hot-hot
dependency I would like to be told - being a very stupid user.

(In reply to comment #7)
This bug is only about adding "modprobe unix" to udev-start.
Nothing todo with hotplug or other.
For hotplug have a look at Bug #145809.

ok, perfect, thank you for this information!

Best
Zeno

(In reply to comment #5)
> What is the reason you want to put Unix Domain sockets in as a module in the
> first place? Is it because you get a udev error that does not create all the
> devices?

It is really motivated by a policy to have the smallest kernel core possible,
and to use modules to expand capabilities. This enables kernels for embedded
devices and mainframes (using the same instruction sets), to be consistent,
removing the need to have separate embedded and server editions of the
software.

An embedded system may not require Unix Domain Sockets, but a server may
require this. If the server requires this, it is a simple case of loading the
module. This is a better solution than hardcoding or hardbuilding into the
kernel making the embedded kernel larger.

Regards,

Mark.