From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47565 invoked by alias); 20 Jun 2017 13:30:51 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 42889 invoked by uid 89); 20 Jun 2017 13:30:45 -0000 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 Received: from out3-smtp.messagingengine.com (HELO out3-smtp.messagingengine.com) (66.111.4.27) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 20 Jun 2017 13:30:43 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5B94A20E0D; Tue, 20 Jun 2017 09:30:42 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Tue, 20 Jun 2017 09:30:42 -0400 X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 314C062702; Tue, 20 Jun 2017 09:30:42 -0400 (EDT) Message-Id: <1497965442.2961973.1015365512.64E5C421@webmail.messagingengine.com> From: Ronald Fischer To: cyg Simple , cygwin@cygwin.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Date: Tue, 20 Jun 2017 13:30:00 -0000 Subject: Re: Killing-Process woes References: <1497939835.2871765.1014990544.3396EEF9@webmail.messagingengine.com> In-Reply-To: X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg00243.txt.bz2 > > 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