From: Ruediger Meier <sweet_f_a@gmx.de>
To: Karel Zak <kzak@redhat.com>
Cc: util-linux@vger.kernel.org
Subject: Re: [PATCH] tests: don't lock fd 1 (stdout)
Date: Wed, 7 Mar 2018 12:48:44 +0100 [thread overview]
Message-ID: <201803071248.45196.sweet_f_a@gmx.de> (raw)
In-Reply-To: <20180307104252.zwdcehv27fp3ny6k@ws.net.home>
On Wednesday 07 March 2018, Karel Zak wrote:
> On Wed, Mar 07, 2018 at 12:38:07AM +0100, Ruediger Meier wrote:
> > This is how this patch changes the test output:
> >
> > --- /tmp/a 2018-03-06 22:31:15.000000000 +0000
> > +++ /tmp/b 2018-03-06 22:30:34.000000000 +0000
>
> git-am had really difficult time to accept to your patch with patch
> in the patch comment :-)
Oops.
> > index d1c97e0b6..8cc148fb8 100644
> > --- a/tests/functions.sh
> > +++ b/tests/functions.sh
> > @@ -226,6 +226,8 @@ function ts_init_env {
> > local mydir=$(ts_abspath ${0%/*})
> > local tmp
> >
> > + shopt -s nullglob
> > +
>
> 1) It seems it breaks ts/ipcs/limits:ipcs_limits_check(), the sed
> arguments in the line
Ah sorry, I've checked the tests only on that bsd box. I will review
again and do it without "shopt -s nullglob". It's confusing anyways for
test writers if the bash uses non-default options.
> "echo \$(cat /proc/sys/kernel/shmall) / 1024 \* $PAGE_SIZE | bc
> -l | sed 's/\..*//'"
>
> are ignored, so with eval it calls
>
> eval echo '$(cat' '/proc/sys/kernel/shmall)' / 1024 '\*' 4096 '|'
> bc -l '|' sed
>
> I have added
>
> shopt -u nullglob
>
> to the function to fix the problem. It seems it works.
>
>
> 2) I see
>
> mount: btrfs (fstab) ...
>
> : btrfs ... OK
> : auto ... SKIPPED (failed to
> : lock fstab)
>
> and with ./run.sh --parallel I see another "failed to lock" messages
> :-(
Hm, I had never really tried --parallel root checks yet because the
non-deterministic behavior regarding udevadm and my NFS /home is
already complicated enough for my taste ;)
Are the files unlocked automatically if we exit the test without calling
ts_unlock?
BTW could it be better to use our own ./flock instead of the global one?
And maybe it's possible to print separate messages for "failed to lock"
and "timeout lock".
>
> Maybe we can use --nolocks for debian-kfreebsd (TS_NOLOCKS in
> tests/functions.sh).
Well, I had already tried to check whether /proc/*/fd is behaving like
we expect. But seems difficult to find out. Maybe just the stupid way,
like:
if root && ! Linux; then parallel=1
if ! Linux; then TS_NOLOCKS=yes
cu,
Rudi
next prev parent reply other threads:[~2018-03-07 11:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-06 23:38 [PATCH] tests: don't lock fd 1 (stdout) Ruediger Meier
2018-03-06 23:45 ` Ruediger Meier
2018-03-07 10:42 ` Karel Zak
2018-03-07 11:48 ` Ruediger Meier [this message]
2018-03-07 14:31 ` Ruediger Meier
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=201803071248.45196.sweet_f_a@gmx.de \
--to=sweet_f_a@gmx.de \
--cc=kzak@redhat.com \
--cc=util-linux@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