Udev rule oddity

Bryan Kadzban bryan at kadzban.is-a-geek.net
Tue Jan 26 20:10:27 PST 2010

Matthew Burgess wrote:
> I wasn't sure whether to report this as a bug in LFS or Udev or
> whether it's just my misunderstanding.  If I remove 
> /etc/udev/rules.d/70-persistent* (simulating how things look on a
> first boot into a freshly-built system) I then get the following on a
> reboot:
> udevd[371]: can not read '/etc/udev/rules.d/70-persistent-cd.rules' 
> udevd[371]: can not read '/etc/udev/rules.d/70-persistent-net.rules'

This smells like inotify acting unexpectedly.

Looking at write_net_rules, the actual rules are generated by lots of
individual calls to echo.  If inotify wakes up udev after -- say -- the
first echo finishes (and appends to the empty file), it's *possible*
that udev will read a blank file.

What I don't know is whether this causes it to log that error.  Can you
create an empty (say) 99-test.rules file in /etc/udev/rules.d and see if
it logs the same thing?  I believe it'll write to /dev/kmsg, so the log
message should show up in the kernel logs, if it gets sent...

Or, actually, what happens if you move 70-persistent-net.rules out to
/dev/.udev/rules.d/, then do what we have in the udev_retry bootscript?
(That is, cat the file out of /dev/.udev/rules.d, and append the result
into /etc/udev/rules.d, then rm the version in /dev/.udev/rules.d as a
separate operation.)  At what point is the message logged, if it's
logged in that operation anywhere?

> By the time I've logged in, those files do exist because they were 
> created by write_cd_rules and write_net_rules respectively, in turn
> by 75-cd-aliases-generator.rules and
> 75-persistent-net-generator.rules.
> So the question is, why does Udev try to read files that don't exist
> yet? How does it even know that they will/should exist?  This looks
> to me to be some kind of race condition but I'm not overly sure!

Yeah, seems like a race to me as well.  Otherwise udev would have had to
hardcode the 70-persistent-*.rules filenames somewhere, to know to try
to look for them.

If you have console access, you might also try booting with
init=/bin/bash (after deleting the generated rules) and running each
bootscript individually.  This should show which script is causing the
log message at least.  (Just be sure that if you get to the point of
mounting anything read-write, you unmount it before rebooting.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20100126/43062ebe/attachment.sig>

More information about the lfs-dev mailing list