Re: DDF test fails if default udev rules are active

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 3244 bytes --]

On Tue, 06 Aug 2013 23:44:37 +0200 Martin Wilck <mwilck@arcor.de> wrote:

> On 04/24/2013 08:13 AM, NeilBrown wrote:
> > On Wed, 27 Mar 2013 21:44:21 +0100 Martin Wilck <mwilck@arcor.de> wrote:
> > 
> >> Hi Neil,
> >>
> >> with my latest patch set, the DDF test case (10-ddf-create) succeeds
> >> reliably for me, with one caveat: It works only if I disable the rule
> >> that runs "mdadm -I" on a newly discovered container. On my system
> >> (Centos 6.3) it is in /lib/udev/65-md-incremental.rules, and the rule is
> >>
> >> SUBSYSTEM="block", ACTION="add|change", KERNEL="md*", \
> >>   ENV{MD_LEVEL}=="container", RUN+="/sbin/mdadm -I $env{DEVNAME}"
> >>
> >> The reason is that the DDF test case runs mdadm -Asc after writing the
> >> conf file defining the container and 3 arrays.
> >>
> >> mdadm -Asc will first create the container. When it starts tries to
> >> create the member arrays, these have already been started by the udev
> >> rule above, causing the assembly to fail with the error message "member
> >> /dev/md127/1 in /dev/md127 is already assembled".
> >>
> >> I have done my testing with the above udev rule commented out, and all
> >> goes fine. But I am not sure if "mdadm -Asc /var/tmp/mdadm.conf" failing
> >> indicates a problem with the DDF code, or if it's really just a problem
> >> with the test case. Personally, I'd rather have a test case that
> >> succeeds by default on a system with standard configuration (which means
> >> the above udev rule should be active).
> >>
> >> What do you think?
> >> Martin
> > 
> > Hi Martin,
> >  I think this is a real issue that has occasionally annoyed me a bit but
> >  never enough to make me seriously address it - so thanks for raising it.
> > 
> >  I generally would like the tests to run without any interference from udev,
> >  though I certainly see the value of testing in a "standard config" context
> >  too.
> > 
> >  Fortunately it appears to be easy to address.
> >    udevadm control --stop-exec-queue
> >  will pause udev, and
> >    udevadm control --start-exec-queue
> >  will cause udev to resume.
> > 
> >  So I suggest that we change the 'test' script to run:
> > 
> >     udevadm settle; udevadm control --stop-exec-queue
> > 
> >  before running each test script, and
> > 
> >     udevadm control --start-exec-queue
> > 
> >  after the script.
> >  Then if a script wants to run in "standard" context, it could simply put
> >     udevadm control --start-exec-queue
> >  at the top.  The default would be to disable udev which is what most scripts
> >  expect.
> > 
> >  Can you try that?
> 
> It took me a while. I just tried today. Unfortunately it doesn't work
> right, at least not on CentOS 6. With the exec 	queue stopped, the
> container devices /dev/md/xyz won't be created in the first place
> ("timeout waiting for /dev/md/ddf"). I also tried additionally
> MDADM_NO_UDEV=1, but that would cause even other problems. I didn't dig
> any deeper. Disabling that single rule works fine for me.

Yes of course, we need udev to create the names in /dev.  We just don't want
it to auto-start things.
No easy around that that I can think of.
Bother.

Thanks,
NeilBrown


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]