From: Nix <nix@esperi.org.uk>
To: linux-hotplug@vger.kernel.org
Subject: Re: udevadm settle persistently failing
Date: Mon, 16 May 2011 10:01:21 +0000 [thread overview]
Message-ID: <87boz3ezgu.fsf@spindle.srvr.nix> (raw)
In-Reply-To: <8739kfzv1j.fsf@spindle.srvr.nix>
On 16 May 2011, Kay Sievers outgrape:
> With devtmpfs you get the "early" /dev for free, and you preserve the
> "early" /dev in the real root. Instead of mounting a 'tmpfs' just
> mount a 'devtmpfs' at /dev, and it will be magically filled already,
> that's the only difference.
>
> When mounting the real root, just mount --move it over to the real
> root before switching to the real root.
I'll have to see what busybox's switch_root does. I know it deletes
the entire contents of the root directory it switches away from: I'll
have to make sure that doesn't somehow include moved-away mountpoints.
(I doubt it does.)
> Maybe you can run:
> udevadm monitor
> in the background writing to a file, and get timestamps of your commands too.
They're fine.
After a bunch of straces, I think the problem is different. As I
suspected from its intermittent nature, it's a race.
When udevd starts up, it looks for an old database and converts it into
a new-style /run database. This takes nonzero time, and is done *after*
daemonization. Unfortunately, in the same time window it is quite
possible to fit a pair of 'udevadm trigger's and a 'udevadm settle': and
when udevadm settle kicks up and finds that udev hasn't even initialized
yet, what does it do? Well, unless I misread the code
udev_queue_get_queue_is_empty() returns 1 in this situation, so 'udevadm
settle' returns EXIT_SUCCESS, and boom.
My evidence for this is very thin: it's no more than a hypothesis
really. My only evidence for this so far is that I haven't managed to
get the failure to happen unless I mkdir the old udev directories first
to force udev to do an old->new db conversion. It would be nice to
gather more data, but it's hard to do that without perturbing the race
:/ even an ls of /run slows it down enough that it doesn't happen
anymore. Hm, perhaps an echo would be fast enough, it's a shell
builtin after all...
If I'm right (and I'm not sure I am, but it feels plausible), then I
suspect the only fix is to move the db conversion so that it happens
before daemonization.
--
NULL && (void)
next prev parent reply other threads:[~2011-05-16 10:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-15 18:19 udevadm settle persistently failing Nix
2011-05-15 18:32 ` Tom Gundersen
2011-05-15 23:25 ` Kay Sievers
2011-05-15 23:33 ` Kay Sievers
2011-05-15 23:38 ` Nix
2011-05-15 23:47 ` Nix
2011-05-15 23:51 ` Kay Sievers
2011-05-15 23:57 ` Kay Sievers
2011-05-16 5:05 ` DJ Lucas
2011-05-16 6:23 ` DJ Lucas
2011-05-16 10:01 ` Nix [this message]
2011-05-16 10:22 ` Marco d'Itri
2011-05-16 10:36 ` Nix
2011-05-16 10:51 ` Kay Sievers
2011-05-16 11:28 ` Kay Sievers
2011-05-16 12:47 ` Nix
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87boz3ezgu.fsf@spindle.srvr.nix \
--to=nix@esperi.org.uk \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.