X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:from:to:mime-version
	:content-transfer-encoding:content-type:date:subject:references
	:in-reply-to; q=dns; s=default; b=CKKDC+s16pd40W5wLW954LAek8gPWP
	cXg+ESIQPGouBUxhEJAqpsrxIaVR1DHXy/rKp36iw496hgTbRrSxei1Q5g4BCMRz
	9D06JAxGPYn7riBsaq2UIV9FsAnJ+mzW0RSCeMZVYcji57NLGpCvAxZk3Q7+SRLv
	G4k2pwgIYH8yE=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:from:to:mime-version
	:content-transfer-encoding:content-type:date:subject:references
	:in-reply-to; s=default; bh=Y4Enfh5/3v+cayW5pj1UC5oswoo=; b=WVKI
	AjsbqGt9TUhf2gv4UoZQdE5V441BsBZBHui3c6CysJtLdpeC8his8Oayol4lzGWx
	n9XF6y/cr+IWGqUTstiNybOLauZ+5Hh8m1e2hsdQdq+IHUdQ9ba1zTPJp/jrfSt/
	GALQNv/Du4OVfjC/HGrzp4Wk6+HCgY8jkZdccv0=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*f:sk:f3b7288, awful, H*MI:sk:f3b7288, H*i:sk:f3b7288
X-HELO:	out3-smtp.messagingengine.com
X-ME-Sender:	<xms:giNJWXnN-Ogzo4kRkJ9aJhVDwBJNJSetatfzKHD5r__8C3DrFK32hQ>
Message-Id:	<1497965442.2961973.1015365512.64E5C421@webmail.messagingengine.com>
From:	Ronald Fischer <ynnor AT mm DOT st>
To:	cyg Simple <cygsimple AT gmail DOT com>, cygwin AT cygwin DOT com
MIME-Version:	1.0
Date:	Tue, 20 Jun 2017 15:30:42 +0200
Subject:	Re: Killing-Process woes
References:	<1497939835 DOT 2871765 DOT 1014990544 DOT 3396EEF9 AT webmail DOT messagingengine DOT com> <f3b72886-7424-7cd6-b160-64a9515bcc36 AT gmail DOT com>
In-Reply-To:	<f3b72886-7424-7cd6-b160-64a9515bcc36@gmail.com>
X-IsSubscribed:	yes

> > The background processes are actually (zsh-) scripts, which do some
> > setup (basically setting various environment variables), and then invoke
> > a (Cygwin-)Ruby program which does the "real work". The program is
> > executed by something like
> > 
> >     ruby myprog.rb
> > 
> > (Note that this Ruby program is NOT invoked in background).
> > 
> > When my SIGINT trap is entered, I can see from ps indeed the
> > relationship between the processes involved, for instance
> > 
> >     10852    9296    6224      10536  cons3    3672028 08:05:10
> >     /usr/bin/ruby
> >      9296    6224    6224      11236  cons3    3672028 08:05:10
> >      /usr/bin/zsh
> > 
> > The PID of my background process - the zsh wrapper - in this concrete
> > case is 9296, and we can see that this is the parent of the Ruby
> > process, 10852. The problem is that if I just kill 9296, the Ruby
> > process keeps running, orphaned:
> > 
> >     10852       1    6224      10536  cons3    3672028 08:05:10
> >     /usr/bin/ruby
> > 
> > I've found on Stackoverflow the suggestion to treat this as a process
> > group and use negative PIDs. I tried this too, but it didn't work. Here
> > is a similar example:
> > 
> 
> Not implemented as you found out below.  But I don't know that the
> negative process number is in use anywhere.  Are you sure it wasn't a
> signal number as a option to kill?

No, the article refered to a process group (and this indeed would be
done by negative PIDs), but as I said, this didn't work anyway.

> Perhaps use the -f --force switch might help.

No, doesn't help either.

For the time being, I have reverted to analyzing the output of ps. It is
pretty tedious:

# Get the PID of the shell script 
local wrapper_proc=$!
# Give the wrapper some time to start the Ruby process below. Without
this, the
# Ruby process would not be visible yet.
sleep 3
# Find out the PID of the child process of the wrapper
local sub_pid=$(ps |grep -oE "^ *[0-9]+ *$wrapper_proc "|awk ' {print
$1}')
# Sanity check ....
if [[ $sub_pid =~ ^[0-9]+$ ]]
then
  # Add this to the array of these child processes
     additional_pids+=$sub_pid
 else
     echo "Info: Could not extract VP pid from '$sub_pid'"
 fi

Inside my SIGINT trap, I do not only kill the processes found via
$jobstates, but also the processes collected in $additional_pids. An
awful solution, and one which is not easy to maintain and may break!

Ronald

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -