[nSLUG] udev (Was: DVD drive...sound...)

Rich 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 
the events.

>> 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 
rules files,
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...
URL: <http://nslug.ns.ca/mailman/private/nslug/attachments/20090206/6760b7e8/attachment.html>

More information about the nSLUG mailing list