Re: [PATCH] common/rc: add default _udev_wait timeout

["Darrick J. Wong" <djwong@kernel.org>]

On Mon, Mar 23, 2026 at 12:54:21PM +1100, David Disseldorp wrote:
> On Fri, 20 Mar 2026 07:44:13 -0700, Darrick J. Wong wrote:
> ...
> > > 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.
> 
> I've added the extra udevd sanity check to my test env, so I shouldn't
> need anything in check. I'd expect NFS, SMB, CephFS, etc. may still want
> to run without udevd.

<nod>

> > > > > 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>
> 
> I'd still like to see a timeout added, as a failed test (with timeout
> msg) is IMO a far better outcome than an endless wait. Any objections if
> I send a v2 patch with 60s timeout?

Nope, 60 seconds should be enough for anyone. ;)

--D