All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [OSSTEST PATCH] standalone-generate-dump-flight-runvars: Handle ^C properly
Date: Mon, 12 Oct 2015 11:26:13 +0100	[thread overview]
Message-ID: <1444645573.1410.489.camel@citrix.com> (raw)
In-Reply-To: <1444410785-1271-1-git-send-email-ian.jackson@eu.citrix.com>

On Fri, 2015-10-09 at 18:13 +0100, Ian Jackson wrote:
> This is all mad.

No kidding!

It doesn't appear to be possible to call setsid() from a shell script
(other than by re-execing oneself), which is a shame.

I wonder at what point we should just rewrite the whole thing in Perl?
Anyway right now:

> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  standalone-generate-dump-flight-runvars |   24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/standalone-generate-dump-flight-runvars b/standalone
> -generate-dump-flight-runvars
> index a1907b0..efedd5c 100755
> --- a/standalone-generate-dump-flight-runvars
> +++ b/standalone-generate-dump-flight-runvars
> @@ -58,8 +58,32 @@ perbranch () {
>      flight=check_${branch//[-._]/_}
>  }
>  
> +# Good grief, handling background proceesses from shell is a pain.

"processes"

> +#
> +# For stupid historical reasons, background processes start with
> +# SIGINT (and QUIT) ignored (SuSv3 2.11).  bash does not offer a
> +# way to ask it not to do this.
> +#
> +# There is no way to reset this in bash (bash 4.2.37 manpage section
> +# on `trap' builtin), so we use perl.  However, there is still a race:
> +# if the signal arrives just after the fork, after the shell has (in
> +# the child) set it to to IGN, but before Perl has put it back, the
> +# child might still escape.  So in the child we check our parent.
> +#
> +# I _think_ that that any signal which arrives before the assignment
> +# to $SIG{} will definitely have caused our parent to vanish and us to
> +# be reparented to pid 1 by the time we do the getppid check.  But TBH
> +# I can't find any clear support for this requirement.  So the result
> +# may still be slightly racy in the case that s-g-d-f-r is ^C'd right
> +# after starting.

Based on your followup I guess you might want to clarify this?

> +
>  for branch in $@; do
>      perbranch
> +    perl -e '
> +        $SIG{$_}=DFL foreach qw(INT QUIT HUP);
> +	kill 1, $$ unless getppid=='$$';
> +	exec @ARGV or die $!;
> +    ' \
>      ./standalone make-flight -f $flight $branch >$log 2>&1 &
>      procs+=" $branch=$!"
>  done

  parent reply	other threads:[~2015-10-12 10:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-09 17:13 [OSSTEST PATCH] standalone-generate-dump-flight-runvars: Handle ^C properly Ian Jackson
2015-10-09 18:06 ` Ian Jackson
2015-10-12 10:26 ` Ian Campbell [this message]
2015-10-13 18:18   ` [OSSTEST PATCH v2] " Ian Jackson

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=1444645573.1410.489.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=xen-devel@lists.xenproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.