[PATCH] Fix udev "temporary rules" for read-only root filesystems

[PATCH] Fix udev "temporary rules" for read-only root filesystems

[Paul Stewart]

Fix udev issue where temporary persistent rules are written in one
place and read from another.  The upstream udev release placed dynamic
persistent rules (ones that get deleted every reboot) in /dev/.udev/,
but the actual udev daemon read these rules out of
/dev/.udev/rules.d/.  The side effect of this is that if the static
directory (/etc/udev/rules.d) is not writeable (read-only root
filesystem, for example), device interfaces keep getting renamed
wlan0, wlan1, wlan2, etc, if they are plugged and unplugged or if
udevd restarts.

In addition to the directory being incorrect, the actual filename was
incorrect as well -- the filename was set to begin with "tmp-", which
breaks the lexical sorting rules that udevd uses, so even if the file
was in the right directory, the 75-persistent-net-generator.rules
would fire first, and increment the device number anyway.

I've tested this patch to apply clieanly to udev-146 and udev-156.

Note that this change by itself won't work on most distributions (with
read only fses) unless they they also make sure that the
/dev/.udev/rules.d directory is created before udevd starts up, since
otherwise the inotify will never trigger for that directory since it
didn't exist when the inotify call was made.

--- extras/rule_generator/rule_generator.functions.orig 2008-10-23
06:33:41.000000000 -0700
+++ extras/rule_generator/rule_generator.functions 2010-05-26
10:26:20.000000000 -0700
@@ -57,7 +57,9 @@
 # Choose the real rules file if it is writeable or a temporary file if not.
 # Both files should be checked later when looking for existing rules.
 choose_rules_file() {
- local tmp_rules_file="/dev/.udev/tmp-rules--${RULES_FILE##*/}"
+ local orig_rules_base=${RULES_FILE##*/}
+ local tmp_rules_base=${orig_rules_base%%.rules}--tmp.rules
+ local tmp_rules_file="/dev/.udev/rules.d/$tmp_rules_base"
  [ -e "$RULES_FILE" -o -e "$tmp_rules_file" ] || PRINT_HEADER=1

  if writeable ${RULES_FILE%/*}; then

Re: [PATCH] Fix udev "temporary rules" for read-only root filesystems

[Kay Sievers]

On Thu, May 27, 2010 at 01:03, Paul Stewart <pstew@google.com> wrote:
> Fix udev issue where temporary persistent rules are written in one
> place and read from another.  The upstream udev release placed dynamic
> persistent rules (ones that get deleted every reboot) in /dev/.udev/,
> but the actual udev daemon read these rules out of
> /dev/.udev/rules.d/.

I think these temporary rules have never been expected to be read by
the udev daemon directly.

> The side effect of this is that if the static
> directory (/etc/udev/rules.d) is not writeable (read-only root
> filesystem, for example), device interfaces keep getting renamed
> wlan0, wlan1, wlan2, etc, if they are plugged and unplugged or if
> udevd restarts.

The temporary rules files, which might be created in /dev/.udev/ are
supposed to be copied to /etc/udev/rules.d/ as soon as the rootfs is
writable. There should be no restart of udevd in the meantime. :)

What kind of system you are seeing problems? Is it a known distribution?

How do you handle the temporary rules files you copy into
/dev/.udev/rules.d/? How do they get into /etc?

> Note that this change by itself won't work on most distributions (with
> read only fses) unless they they also make sure that the
> /dev/.udev/rules.d directory is created before udevd starts up, since
> otherwise the inotify will never trigger for that directory since it
> didn't exist when the inotify call was made.

What do you mean? Udevd itself creates this directory, and watches it
with inotify.

Kay

Re: [PATCH] Fix udev "temporary rules" for read-only root

[Marco d'Itri]

On May 27, Kay Sievers <kay.sievers@vrfy.org> wrote:

> I think these temporary rules have never been expected to be read by
> the udev daemon directly.
Indeed, I invented this for Debian which copies the files to
/etc/udev/rules.d/ in /etc/init.d/udev-mtab.

-- 
ciao,
Marco

Re: [PATCH] Fix udev "temporary rules" for read-only root filesystems

[Paul Stewart]

Thanks for the great info. I'm mostly sold that the current behavior
is a intended. I'm using a read-only-root distribution, and as such I
started this process of solving device incrementation by moving /etc/
udev/rules.d to a symlink to a writable partition.

However, I did discover a few things along the way which inspired this
patch.

Firstly, the rules in /dev/.udev are essentially "write only". Udevd
does not monitor this directory, which on the surface is okay if you
assume you will only need it briefly while in initrd. However, since
udevd never reads these rules, a device "flicker" during boot (e.g. a
usb network device detaches and re-attaches due to initial firmware
load) will cause two rules for the same device to be written to the /
dev/.udevd tmp-.rules file.

The reason for that us dual. When the device reattaches, udev finds no
rules since it doesn't monitor that directory so "NAME=" I'd never
assigned by the time the 75-persistent-rules generator runs. The
generator script doesn't care that the MAC or other identifiers for
this device are identical -- it just makes sure that if an "eth0"
already exists, that it now name the device "eth1".

So I was confused about who if anyone puts rules in /dev/.udevd/
rules.d. I read the comment in the generator code and it seemed to
imply that the location it was writing to would be seen by udev, so I
just assumed it was a mistake and merged the two.  If that's not
correct, could someone clarify why that is worse than what is there
now?  This way rules created by the generator go directly into udev
instead of waiing until later in the boot cycle.

Secondly, assuming the current configuration has always been the case,
I would assume nobody has actually tested that inotify works on /
dev/.udevd/rules.d if the directory does not already exist before
udevd has started. I have done this myself and it does not. If that is
unexpected behavior for udevd, I'll hunt down the issue in the C code
and send a patch for that instead of one for the unit script.

Thanks so much for the responses!




--
Paul

On May 26, 2010, at 11:02 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:

> On Thu, May 27, 2010 at 01:03, Paul Stewart <pstew@google.com> wrote:
>> Fix udev issue where temporary persistent rules are written in one
>> place and read from another.  The upstream udev release placed
>> dynamic
>> persistent rules (ones that get deleted every reboot) in /dev/.udev/,
>> but the actual udev daemon read these rules out of
>> /dev/.udev/rules.d/.
>
> I think these temporary rules have never been expected to be read by
> the udev daemon directly.
>
>> The side effect of this is that if the static
>> directory (/etc/udev/rules.d) is not writeable (read-only root
>> filesystem, for example), device interfaces keep getting renamed
>> wlan0, wlan1, wlan2, etc, if they are plugged and unplugged or if
>> udevd restarts.
>
> The temporary rules files, which might be created in /dev/.udev/ are
> supposed to be copied to /etc/udev/rules.d/ as soon as the rootfs is
> writable. There should be no restart of udevd in the meantime. :)
>
> What kind of system you are seeing problems? Is it a known
> distribution?
>
> How do you handle the temporary rules files you copy into
> /dev/.udev/rules.d/? How do they get into /etc?
>
>> Note that this change by itself won't work on most distributions
>> (with
>> read only fses) unless they they also make sure that the
>> /dev/.udev/rules.d directory is created before udevd starts up, since
>> otherwise the inotify will never trigger for that directory since it
>> didn't exist when the inotify call was made.
>
> What do you mean? Udevd itself creates this directory, and watches it
> with inotify.
>
> Kay

Re: [PATCH] Fix udev "temporary rules" for read-only root filesystems

[Kay Sievers]

On Thu, May 27, 2010 at 15:55, Paul Stewart <pstew@google.com> wrote:
> So I was confused about who if anyone puts rules in /dev/.udevd/
> rules.d. I read the comment in the generator code and it seemed to
> imply that the location it was writing to would be seen by udev, so I
> just assumed it was a mistake and merged the two.  If that's not
> correct, could someone clarify why that is worse than what is there
> now?  This way rules created by the generator go directly into udev
> instead of waiing until later in the boot cycle.

I guess the generator is older than the /dev/.udev/rules.d/ directory.
We could think about moving these rules there. Not sure, if there are
any unwanted side-effects.

> Secondly, assuming the current configuration has always been the case,
> I would assume nobody has actually tested that inotify works on /
> dev/.udevd/rules.d if the directory does not already exist before
> udevd has started. I have done this myself and it does not. If that is
> unexpected behavior for udevd, I'll hunt down the issue in the C code
> and send a patch for that instead of one for the unit script.

The generator run from udev rules, started by udevd. How should
anything write a rule when udevd is not running? :)

Kay