From: Ronald Fischer <ynnor@mm.st>
To: cyg Simple <cygsimple@gmail.com>, cygwin@cygwin.com
Subject: Re: Killing-Process woes
Date: Tue, 20 Jun 2017 13:30:00 -0000 [thread overview]
Message-ID: <1497965442.2961973.1015365512.64E5C421@webmail.messagingengine.com> (raw)
In-Reply-To: <f3b72886-7424-7cd6-b160-64a9515bcc36@gmail.com>
> > 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
next prev parent reply other threads:[~2017-06-20 13:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-20 6:24 Ronald Otto Valentin Fischer
2017-06-20 13:18 ` cyg Simple
2017-06-20 13:30 ` Ronald Fischer [this message]
2017-06-24 8:48 ` Csaba Raduly
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=1497965442.2961973.1015365512.64E5C421@webmail.messagingengine.com \
--to=ynnor@mm.st \
--cc=cygsimple@gmail.com \
--cc=cygwin@cygwin.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).