Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
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
From: "Dave Korn" <dk AT artimi DOT com>
To: <cygwin AT cygwin DOT com>
Subject: RE: howto register process
Date: Thu, 11 Nov 2004 20:05:07 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <87u0rwury2.fsf@zlatenlist.homelinux.net>
Message-ID: <NUTMEGuOlvX6D96doCe000006ac@NUTMEG.CAM.ARTIMI.COM>
X-OriginalArrivalTime: 11 Nov 2004 20:05:07.0890 (UTC) FILETIME=[BDEDA920:01C4C829]

> -----Original Message-----
> From: kamen On Behalf Of Kamen TOMOV
> Sent: 11 November 2004 19:06
> To: Dave Korn

  Don't know if you just forgot to send this reply to the list as well as to me,
but see the first paragraph of 
http://www.cygwin.com/ml/cygwin/2004-11/msg00424.html
for a list of reasons why to always send replies to the list.

> > > The parent process is started as a windows server. Then it
> > > executes cygwin's fork. When I try to kill any of these with
> > > kill() it returns "No such pid".
> > 
> >   Does your username have sufficient privileges to kill processes
> > belonging to whichever user (perhaps SYSTEM, eh?) that the server is
> > running as?  It might be a slightly bogus error message from kill,
> > when really it should have indicated "access denied".
> 
> I run all these as an Administrator. I tryed calling
> cygwin_winpid_to_pid(), which is part of the cygwin's api and it
> returns -1 when given a process not seen with "ps -ef". -1 means that
> it can't find such pid.
> 
> >   BTW, kill() doesn't return a const char *.  I take it you're
> > referring to the value in errno after the call, and the error
> > message that perror () generates from that?  Or are you referring to
> > the utility program /bin/kill?
> 
> kill() prints int STDERR the error message - it is not returned by it.

  That strikes me as very very wrong indeed for a library function.  A quick
scan through signal.cc doesn't seem to show anything in kill, kill0, or
kill_worker, that would have that effect, though as always with C++, an awful
lot of the detail can be hidden inside implied constructors or overloaded
operators.  Are you _quite_ sure you're calling cygwin's kill?

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


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