Bug#348610: kcontrol: Causes delay during boot
On Tuesday 17 January 2006 19:44, Sam Morris wrote:
> Subject: kcontrol: Causes delay during boot
> Package: kcontrol
> Version: 4:3.4.3-3
> Severity: normal
>
> The script /etc/hotplug/usb/logitechmouse causes a long delay during
> boot, while udev waits 'for /dev to by fully populated'. From my tests,
> it seems that DEVICE isn't even set in the script's environment, so the
> script is timing out while waiting for a file with an empty file to be
> created. I suggest adding something like this to the top of the script:
>
> test -n "$DEVICE" || exit
udev shouldn't be running scripts in /etc/hotplug at all. These are legacy
hotplug scripts, for non-udev users. If udev is still running those
scripts, then file a bug against udev. I doubt very much that it is,
however. I suggest looking again, or giving me more detail concerning how
you arrived at your findings.
> Or better yet, removing the script entirely: what is the purpose of the
> script, and why is it in kcontrol?
Because KControl includes the ability to configure certain parameters of
certain Logitech mice.
> Why should mouse devices have their group set to plugdev?
Setting them to group plugdev allows users to change these settings.
> Why does this only apply to Logitech mice, and why only for users of
> KDE? :)
Only Logitech mice are supported. Because KControl is part of KDE. Hey, I
only package this stuff, I don't write it.
> In fact I just noticed the presence of /etc/udev/logitechmouse.rules that
> does the same thing (even though `find /dev -group plugdev` returns no
> results--should I file a separate bug for that?).
It does the same thing, but for udev, whereas the other script works for
hotplug only. If you don't have any plugdev owned devices, then presumably
you don't have plugged a Logitech mouse that is supported by KControl.
> Perhaps the script should exit immediatly if it detects that /dev/.udev
> exists?
If you're referring to the hotplug script, then it shouldn't be run at all.
Perhaps what is happening is that the udev rules script is making udev load
the USB modules earlier, since it needs to load the USB modules to create
their /dev nodes to be able to apply the rules the script contains, but my
knowledge of udev is fuzzy here. So the boot delay, if my speculation is
right, is really more of a rearrangement than a net increase.
Cheers,
Christopher Martin
Reply to: