Re: [PATCH 3/3] Use --yes option to lvcreate

[Kent Overstreet <kent.overstreet@gmail.com>]

On Tue, Apr 27, 2021 at 02:02:15PM -0700, Eric Biggers wrote:
> On Tue, Apr 27, 2021 at 09:43:19PM +0100, Matthew Wilcox wrote:
> > On Tue, Apr 27, 2021 at 04:29:23PM -0400, Kent Overstreet wrote:
> > > On Wed, Apr 28, 2021 at 01:03:39AM +0800, Eryu Guan wrote:
> > > > On Tue, Apr 27, 2021 at 12:44:19PM -0400, Kent Overstreet wrote:
> > > > > This fixes spurious test failures caused by broken pipe messages.
> > > > > 
> > > > > Signed-off-by: Kent Overstreet <kent.overstreet@gmail.com>
> > > > > ---
> > > > >  tests/generic/081 | 2 +-
> > > > >  tests/generic/108 | 2 +-
> > > > >  2 files changed, 2 insertions(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/tests/generic/081 b/tests/generic/081
> > > > > index 5dff079852..26702007ab 100755
> > > > > --- a/tests/generic/081
> > > > > +++ b/tests/generic/081
> > > > > @@ -70,7 +70,7 @@ _scratch_mkfs_sized $((300 * 1024 * 1024)) >>$seqres.full 2>&1
> > > > >  $LVM_PROG vgcreate -f $vgname $SCRATCH_DEV >>$seqres.full 2>&1
> > > > >  # We use yes pipe instead of 'lvcreate --yes' because old version of lvm
> > > > >  # (like 2.02.95 in RHEL6) don't support --yes option
> > > > > -yes | $LVM_PROG lvcreate -L 256M -n $lvname $vgname >>$seqres.full 2>&1
> > > > > +$LVM_PROG lvcreate --yes -L 256M -n $lvname $vgname >>$seqres.full 2>&1
> > > > 
> > > > Please see above comments, we use yes pipe intentionally. I don't see
> > > > how this would result in broken pipe. Would you please provide more
> > > > details? And let's see if we could fix the broken pipe issue.
> > > 
> > > If lvcreate never ask y/n - never reads from standard input, then echo sees a
> > > broken pipe when it tries to write. That's what I get without this patch.
> > 
> > I think it's something in how ktest sets up the environment.  I also see
> > the SIGPIPEs when using your ktest scripts, but not when ssh'ing into
> > the guest and running the test.
> > 
> > What that thing is, I don't know.  I'm not tall enough to understand
> > signal handling.
> 
> See xfstests commit 9bcb266cd778 ("generic/397: be compatible with ignored
> SIGPIPE") for an example of the same problem being fixed in another test, with
> some more explanation.
> 
> But it's better to just not execute xfstests (or any shell script, for that
> matter) in an environment where SIGPIPE is ignored.

Ah, thanks for the info. I'll see if I can figure out what's mucking with the
signal handler (probably systemd...)