[nSLUG] udev (Was: DVD drive...sound...)
budman85 at eastlink.ca
Fri Feb 6 17:50:49 AST 2009
Mike Spencer wrote:
> Rich wrote:
>>> Worthy of note is that "/etc/rc.d/rc.udev restart" apparently doesn't
>>> read newly created/edited files in /etc/udev/rules.d. It required a
>>> reboot for the new 10-local.rules file to take effect.
>> Its GNU/Linux - this ain't Microshaft!
>> There are three rc.x files:
>> cd /etc/rc.d
>> ./rc.udev stop
>> ./rc.messagebus stop
>> ./rc.hald stop
>> Then start them up in that order.
> First, I'm not using hal. The dbus daemon is running but hal's not
> there so hal doesn't need dbus. Without hal, udev deosn't depend on
> dbus either, right?
right. I didn't know you were not running hal.
The event line of command is:
kernel -> udev -> dbus -> hal -> volmgr -> :) happy user
udev handles device detection, setting up links, renaming the device,
running script on device events
dbus tells hal something happened
hal provides a list of devices to the volmgr
volmgr mounts the device (like having fstab always active instead of
just at boot)
> I see that rc.udev has both reload) and force-reload) options that
> appear to re-load *.rules and then (partially?) reconstruct /dev on
> the fly without restarting udev. It makes sense to me that restarting
> udev should reload rules and rebuilt /dev, too, but it didn't AFAICS.
reload should work for most devices - its like a HUP for syslog.
as you said, seeing the results would either need a reboot,
or unmount the device and remount it.
That should trigger the kernel event.
> I see now that:
> + "rc.udev start" does a bunch manipulation and checks, while
> + "rc.udev restart" just kills and re-invokes the daemon.
> I guess I assumed that starting the daemon itself would set up
> everything the daemon needed from scratch, i.e. from the *.rules.
> That appears to be wrong.
Not really - you need kernel events to trigger the udev settings.
I was using USB card readers that I was hot swapping - this triggered
>> Actually, if you add a udev change, the udev daemon should pickup
>> changes on its next cycle.
>> I only have to cycle it if I'm in X, but I notice recent updates to hald
>> have gotten better.
> I don't get that. udev has "cycles"? udev gets "device events"
> asynchronously from the kernel, right? Do you mean "udevadm trigger"
> that actively requests "events" from the kernel? Or are you referring
> to some periodic update interaction between udev and hal that
> sometimes fails to do the right thing?
The udevd listens to the kernel for any device changes.
I'm trying to remember where I read it that udev will detect changes to
but use reload to force it more quickly.
When I was testing usb card readers, I would edit and save the rules file.
After swapping the reader, the new settings were picked up and I didn't
restart or reload udev.
The only time I had to restart was when the volmgr in XFCE lost itself.
Usually cycling messagebus worked.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nSLUG