From: Jeff King <peff@peff.net>
To: "Randall S. Becker" <rsbecker@nexbridge.com>
Cc: 'Git Mailing List' <git@vger.kernel.org>,
'Joachim Schmitz' <jojo@schmitz-digital.de>
Subject: Re: t5570 trap use in start/stop_git_daemon
Date: Fri, 13 Feb 2015 02:44:03 -0500 [thread overview]
Message-ID: <20150213074403.GB26775@peff.net> (raw)
In-Reply-To: <013601d04702$d7e721e0$87b565a0$@nexbridge.com>
On Thu, Feb 12, 2015 at 03:31:12PM -0500, Randall S. Becker wrote:
> On the NonStop port, we found that trap was causing an issue with test
> success for t5570. When start_git_daemon completes, the shell (ksh,bash) on
> this platform is sending a signal 0 that is being caught and acted on by the
> trap command within the start_git_daemon and stop_git_daemon functions. I am
> taking this up with the operating system group,
Yeah, that seems wrong. If it were a subshell, even, I could see some
argument for it, but it seems odd to trap 0 when a function returns
(bash does have a RETURN trap, which AFAIK is bash-specific, but it
should not trigger a 0-trap).
> but in any case, it may be
> appropriate to include a trap reset at the end of both functions, as below.
> I verified this change on SUSE Linux.
>
> diff --git a/t/lib-git-daemon.sh b/t/lib-git-daemon.sh
> index bc4b341..543e98a 100644
> --- a/t/lib-git-daemon.sh
> +++ b/t/lib-git-daemon.sh
> @@ -62,6 +62,7 @@ start_git_daemon() {
> test_skip_or_die $GIT_TEST_GIT_DAEMON \
> "git daemon failed to start"
> fi
> + trap '' EXIT
> }
I don't think this is the right thing to do. That trap is meant to live
beyond the function's return. Without it, there is nothing to clean up
the running git-daemon if we exit the test script prematurely (e.g., by
a test failing in immediate-mode). We pollute the environment with a
running process which would cause subsequent test runs to fail.
> stop_git_daemon() {
> @@ -84,4 +85,6 @@ stop_git_daemon() {
> fi
> GIT_DAEMON_PID=
> rm -f git_daemon_output
> +
> + trap '' EXIT
> }
This one is slightly less bad, in that we are dropping our
daemon-specific cleanup here anyway. But the appropriate trap is still:
trap 'die' EXIT
which we set earlier in the function. Without it, the test harness's
ability to detect a premature failure is lost.
So I do not know quite what is going on with your shell, but turning off
the traps in these functions is definitely not an acceptable (general)
workaround; it makes things much worse on working platforms.
-Peff
next prev parent reply other threads:[~2015-02-13 7:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-12 20:31 t5570 trap use in start/stop_git_daemon Randall S. Becker
2015-02-13 7:44 ` Jeff King [this message]
2015-02-13 8:03 ` Jeff King
2015-02-13 8:57 ` Joachim Schmitz
2015-02-13 12:27 ` Randall S. Becker
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=20150213074403.GB26775@peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=jojo@schmitz-digital.de \
--cc=rsbecker@nexbridge.com \
/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