SIGKILL and TerminateProcess

SIGKILL and TerminateProcess

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

Hello List,

I have a question, as to why CYGWIN does not use the TerminateProcess approach when
dealing with SIGKILL sent to a process (in the manner the CYGWIN's own kill utility
does when invoked with -f)?  Usually SIGKILL is expected to reliably terminate
its victim (let alone it can't be intercepted, hence, does not need any "handling"
provisions).  Yet under CYGWIN, if the point of execution is found as "unsafe" in the
target process, the signal cannot be delivered quickly.  Such as when the process is busy dealing with a time-consuming Windows API (the dumbest example is Sleep() ;-),
then the process will not get killed even with SIGKILL.  Could CYGWIN please consider
special-casing SIGKILL to perform something similar to the force-killing of the
command-line utility?

Thanks,

Anton Lavrentiev
Contractor NIH/NLM/NCBI


--
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

Re: SIGKILL and TerminateProcess

[Christopher Faylor]

On Tue, Oct 29, 2013 at 03:47:47PM +0000, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
>Hello List,
>
>I have a question, as to why CYGWIN does not use the TerminateProcess approach when
>dealing with SIGKILL sent to a process (in the manner the CYGWIN's own kill utility
>does when invoked with -f)?  Usually SIGKILL is expected to reliably terminate
>its victim (let alone it can't be intercepted, hence, does not need any "handling"
>provisions).  Yet under CYGWIN, if the point of execution is found as "unsafe" in the
>target process, the signal cannot be delivered quickly.  Such as when the process is busy dealing with a time-consuming Windows API (the dumbest example is Sleep() ;-),
>then the process will not get killed even with SIGKILL.  Could CYGWIN please consider
>special-casing SIGKILL to perform something similar to the force-killing of the
>command-line utility?

Sorry but we aren't going to redesign the signal delivery mechanism for
your use case.

Cygwin does not guarantee delivery of signals to processes which are
calling Windows API functions directly.  If you do that you should be
prepared to deal with problems.

If you are finding that SIGKILL does not reliably kill a blocking UNIX
function, however, that is a bug.

--
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

RE: SIGKILL and TerminateProcess

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

> Sorry but we aren't going to redesign the signal delivery mechanism for
> your use case.

It wasn't exactly a redesign I was asking about;  rather an addition
(or an improvement, if you will) for only the case of that one KILL
signal, which is already a special thing in all aspects even on UNIX.

> Cygwin does not guarantee delivery of signals to processes which are
> calling Windows API functions directly.  If you do that you should be
> prepared to deal with problems.

Windows Sleep() was just a convenient dummy to demonstrate how SIGKILL does
not kill.  CYGWIN lets me access some Windows-specific APIs (the same way one
would do by using some UNIX-flavor-specific libraries), without having to port them
all to CYGWIN first.  Such code becomes a real problem in pipelining because
it cannot be reliably managed from other processes (which would all require
modifications to do TerminateProcess tricks throughout; or use the special
CYGWIN command-like utility) where just kill(9) would have been sufficient..

Anton Lavrentiev
Contractor NIH/NLM/NCBI


--
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

Re: SIGKILL and TerminateProcess

[Christopher Faylor]

On Tue, Oct 29, 2013 at 06:37:46PM +0000, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
>> Sorry but we aren't going to redesign the signal delivery mechanism for
>> your use case.
>
>It wasn't exactly a redesign I was asking about;  rather an addition
>(or an improvement, if you will) for only the case of that one KILL
>signal, which is already a special thing in all aspects even on UNIX.

As the person who wrote the signal handling code, I think I get to
specify what I consider to be a redesign.

>>Cygwin does not guarantee delivery of signals to processes which are
>>calling Windows API functions directly.  If you do that you should be
>>prepared to deal with problems.
>
>Windows Sleep() was just a convenient dummy to demonstrate how SIGKILL
>does not kill.

You may notice that I didn't specify Sleep() in my explanation.

>CYGWIN lets me access some Windows-specific APIs (the same way one
>would do by using some UNIX-flavor-specific libraries), without having
>to port them all to CYGWIN first.  Such code becomes a real problem in
>pipelining because it cannot be reliably managed from other processes
>(which would all require modifications to do TerminateProcess tricks
>throughout; or use the special CYGWIN command-like utility) where just
>kill(9) would have been sufficient..

To be a broken record: The whole point of Cygwin is to run UNIX based
programs on Windows.  Asking for the addition of special-case code so
that people can use Windows functions in their programs completely
misses the point of this project.

That said, however, the Cygwin "kill" command does have a "-f" option
which forces the termination of a process if it can't be killed with
Cygwin's signal mechanism (I added it so that I could kill processes
that were hung while I was working on Cygwin's signal code).  If it is
essential that you be able to summarily terminate Windows programs then
use that.

Otherwise, I guarantee that continuing to insist that you need this will
avail you naught.  Your suggested change is not going to be implemented.

cgf

--
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

Re: SIGKILL and TerminateProcess

[Charles Wilson]

On 10/29/2013 3:21 PM, Christopher Faylor wrote:
> On Tue, Oct 29, 2013 at 06:37:46PM +0000, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
>> CYGWIN lets me access some Windows-specific APIs (the same way one
>> would do by using some UNIX-flavor-specific libraries), without having
>> to port them all to CYGWIN first.  Such code becomes a real problem in
>> pipelining because it cannot be reliably managed from other processes
>> (which would all require modifications to do TerminateProcess tricks
>> throughout; or use the special CYGWIN command-like utility) where just
>> kill(9) would have been sufficient..
>
> To be a broken record: The whole point of Cygwin is to run UNIX based
> programs on Windows.  Asking for the addition of special-case code so
> that people can use Windows functions in their programs completely
> misses the point of this project.
>
> That said, however, the Cygwin "kill" command does have a "-f" option
> which forces the termination of a process if it can't be killed with
> Cygwin's signal mechanism (I added it so that I could kill processes
> that were hung while I was working on Cygwin's signal code).  If it is
> essential that you be able to summarily terminate Windows programs then
> use that.

What cgf said. However, there is a "cygwin" API you could add, which 
allows to programatically do "TerminateProcess" the "correct way" so 
that (cygwin) pipelines and such Do The Right Thing:

http://cygwin.com/ml/cygwin-patches/2009-q4/msg00028.html

Don't know if this will help in your situation, but I figured it should 
be mentioned.

--
Chuck


--
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

RE: SIGKILL and TerminateProcess

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

> As the person who wrote the signal handling code, I

Believe it or not, I'm well aware of that.

> continuing to insist that you need this will avail you naught

There was no intention to insist on anything;  but to understand why that
has been implemented the way it is.  And the point has been taken..

Anton Lavrentiev
Contractor NIH/NLM/NCBI


--
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

RE: SIGKILL and TerminateProcess

[Lavrentiev, Anton (NIH/NLM/NCBI) [C]]

> http://cygwin.com/ml/cygwin-patches/2009-q4/msg00028.html

> Don't know if this will help in your situation, but I figured it should
> be mentioned.

Thank you for the follow up.

The idea was to use CYGWIN (and hence UNIX scripting) to control (mainly: launch / stop) applications (whether CYGWIN-based or native Windows beasts) on an
unmanned Windows box...

Anton Lavrentiev
Contractor NIH/NLM/NCBI


--
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