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

Mike Spencer mspencer at tallships.ca
Fri Feb 6 15:11:46 AST 2009


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?

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.

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.

> 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?


- Mike

-- 
Michael Spencer                  Nova Scotia, Canada       .~. 
                                                           /V\ 
mspencer at tallships.ca                                     /( )\
http://home.tallships.ca/mspencer/                        ^^-^^





More information about the nSLUG mailing list