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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).