public inbox for fstests@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: David Disseldorp <ddiss@suse.de>
Cc: fstests@vger.kernel.org, Dave Chinner <david@fromorbit.com>
Subject: Re: [PATCH] common/rc: add default _udev_wait timeout
Date: Fri, 20 Mar 2026 07:44:13 -0700	[thread overview]
Message-ID: <20260320144413.GA6212@frogsfrogsfrogs> (raw)
In-Reply-To: <20260320103736.40f275b8.ddiss@suse.de>

On Fri, Mar 20, 2026 at 10:37:36AM +1100, David Disseldorp wrote:
> On Thu, 19 Mar 2026 08:38:43 -0700, Darrick J. Wong wrote:
> 
> > On Thu, Mar 19, 2026 at 11:51:54AM +1100, David Disseldorp wrote:
> > > If udevd isn't running then "udevadm wait" loops endlessly. With a
> > > --timeout parameter provided, udevadm (udev-254.27) prints to stderr:
> > >   Timed out for waiting devices being initialized.  
> > 
> > If you don't have udevd running, then perhaps we should detect that and
> > directly call "sleep 10"?  Because otherwise...
> 
> I normally have udevd running, but sometimes mess it up. My latest screw
> up came from ommitting a "/run" dir in the initramfs test env, which
> causes systemd-udevd to die on "/run/udev" creation. The error message
> is hard to spot amoungst the other boot messages...

Oh, ok.  For some reason I thought you were trying to run fstests
without udev.  What if instead ./check looked for udevd and refused to
proceed if it isn't running?  AFAIK even the anti-systemd distros ship
eudev.

> > > The error message causes test failure via golden output mismatch and
> > > is easier to debug than an infinite loop.
> > > 
> > > The timeout parameter is also compatible with existing
> > > args="--removed <dev>" callers.
> > > 
> > > Signed-off-by: David Disseldorp <ddiss@suse.de>
> > > ---
> > >  common/rc | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/common/rc b/common/rc
> > > index fd4ca964..aade0e5b 100644
> > > --- a/common/rc
> > > +++ b/common/rc
> > > @@ -5544,7 +5544,7 @@ _udev_wait()
> > >  	if [ -z "$UDEV_WAIT_PROG" ]; then
> > >  		$UDEV_SETTLE_PROG >/dev/null 2>&1
> > >  	else
> > > -		$UDEV_WAIT_PROG $args
> > > +		$UDEV_WAIT_PROG --timeout 10 $args  
> > 
> > ...a system running udevd that's taking forever to process rules can hit
> > this 10 second timeout, at which point the test moves on and might just
> > fail due to unconfigured /dev nodes.
> 
> The 10 seconds is arbitrary. If there's a concern that the timeout will
> prematurely fire on a regular systems then I'll gladly raise it up to a
> minute or so. I just want to get an explicit failure instead of a
> never-ending test.

<nod>

--D

> > /methinks this could be done like so:
> > 
> > 	if [ ! -S /run/udev/control ]; then
> ...
> 
> That's a good idea as a udevd sanity check. I'll add it to my test env. 
> 
> Thanks, David
> 

  reply	other threads:[~2026-03-20 14:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-19  0:51 [PATCH] common/rc: add default _udev_wait timeout David Disseldorp
2026-03-19 15:38 ` Darrick J. Wong
2026-03-19 23:37   ` David Disseldorp
2026-03-20 14:44     ` Darrick J. Wong [this message]
2026-03-23  1:54       ` David Disseldorp
2026-03-23  2:03         ` Darrick J. Wong

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=20260320144413.GA6212@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=david@fromorbit.com \
    --cc=ddiss@suse.de \
    --cc=fstests@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