Bug report: Killing a native process may not actually kill it

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug report: Killing a native process may not actually kill it

Quanah Gibson-Mount
As found and reported to the MSYS team back in 2006 by Howard Chu, if a
native process is spawned, control-C, the kill command, etc, may not
actually kill the process.  Details are here:

<http://mingw.5.n7.nabble.com/Re-Ctrl-Break-handler-td28010.html>

as well as here:

<https://sourceforge.net/p/mingw/bugs/1783/>

Given that there is now 64-bit windows, the issue would be a bit more
complex to resolve, as an updated patch would need to query first to see if
the target process is 32-bit or 64-bit, and then a 64-bit version of the
patch needs to be created.

The inability to properly kill such a spawned process can lead to things
like the dreaded "Device or resource busy" error, since the process that is
using the related file has actually never terminated.

It's fairly trivial to reproduce this in the OpenLDAP test suite,
particularly test001, which spawns a slapd process, kills it, then spawns
another slapd process, which will fail because the original slapd never
actually got killed.

Regards,
Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>


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

Reply | Threaded
Open this post in threaded view
|

openldap on Cygwin (was: Bug report: Killing a native process may not actually kill it)

ASSI
Quanah Gibson-Mount writes:
[…]

Sorry for wedging in sideways, but I've looked into building a more
up-to-date openldap and there's missing detection / configuration for
Cygwin.  Specifically, there's code trying to use robust POSIX mutexes,
which Cygwin doesn't have.  As there is no configure option (that I
could find), the solution is a bit invasive: either feeding in a number
of preprocessor defines or patching in the recognition of Cygwin into
libraries/liblmdb/mdb.c to define the correct options there.

Any chance the upcoming release would have a fix for that?


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

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

Reply | Threaded
Open this post in threaded view
|

Re: openldap on Cygwin

Quanah Gibson-Mount
--On Thursday, July 25, 2019 9:30 PM +0200 Achim Gratz <[hidden email]>
wrote:

> Quanah Gibson-Mount writes:
> […]
>
> Sorry for wedging in sideways, but I've looked into building a more
> up-to-date openldap and there's missing detection / configuration for
> Cygwin.  Specifically, there's code trying to use robust POSIX mutexes,
> which Cygwin doesn't have.  As there is no configure option (that I
> could find), the solution is a bit invasive: either feeding in a number
> of preprocessor defines or patching in the recognition of Cygwin into
> libraries/liblmdb/mdb.c to define the correct options there.
>
> Any chance the upcoming release would have a fix for that?

Hi Achim,

I would suggest filing a report in the OpenLDAP issue tracker at:

<https://www.openldap.org/its>

I use MSYS2 for my OpenLDAP on windows builds, so haven't any direct
experience at the moment with building it via cygwin.

Regards,
Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>


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

Reply | Threaded
Open this post in threaded view
|

Re: Bug report: Killing a native process may not actually kill it

Quanah Gibson-Mount
In reply to this post by Quanah Gibson-Mount


--On Thursday, July 25, 2019 11:32 AM -0700 Quanah Gibson-Mount
<[hidden email]> wrote:

> As found and reported to the MSYS team back in 2006 by Howard Chu, if a
> native process is spawned, control-C, the kill command, etc, may not
> actually kill the process.  Details are here:

I haven't seen a reply to this, so I just wanted to confirm that the Cygwin
project is aware and (hopefully) will be able to do something to fix this
in the long term.

Thanks!

Regards,
Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>

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

Reply | Threaded
Open this post in threaded view
|

Re: Bug report: Killing a native process may not actually kill it

Corinna Vinschen-2
On Aug 28 08:18, Quanah Gibson-Mount wrote:

>
>
> --On Thursday, July 25, 2019 11:32 AM -0700 Quanah Gibson-Mount
> <[hidden email]> wrote:
>
> > As found and reported to the MSYS team back in 2006 by Howard Chu, if a
> > native process is spawned, control-C, the kill command, etc, may not
> > actually kill the process.  Details are here:
>
> I haven't seen a reply to this, so I just wanted to confirm that the Cygwin
> project is aware and (hopefully) will be able to do something to fix this in
> the long term.
Not likely.  Cygwin handles Ctrl-C by generating SIGINT.  This only
works reliably with Cygwin processes.  There's

  $ /bin/kill -f <PID>

to call the Win32 function TerminateProcess(pid) on a non-Cygwin
process or an unresponsive Cygwin process.


Corinna

--
Corinna Vinschen
Cygwin Maintainer

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug report: Killing a native process may not actually kill it

Quanah Gibson-Mount


--On Wednesday, August 28, 2019 6:45 PM +0200 Corinna Vinschen
<[hidden email]> wrote:

> Not likely.  Cygwin handles Ctrl-C by generating SIGINT.  This only
> works reliably with Cygwin processes.  There's
>
>   $ /bin/kill -f <PID>
>
> to call the Win32 function TerminateProcess(pid) on a non-Cygwin
> process or an unresponsive Cygwin process.

As I noted, it was not unique to control-C.  In any case, unfortunate to
hear that Cygwin will not address this issue.  kill -f is clearly not
desirable for doing a clean shutdown of a process.

--Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>

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

Reply | Threaded
Open this post in threaded view
|

Re: Bug report: Killing a native process may not actually kill it

Corinna Vinschen-2
On Aug 28 08:59, Quanah Gibson-Mount wrote:

>
>
> --On Wednesday, August 28, 2019 6:45 PM +0200 Corinna Vinschen
> <[hidden email]> wrote:
>
> > Not likely.  Cygwin handles Ctrl-C by generating SIGINT.  This only
> > works reliably with Cygwin processes.  There's
> >
> >   $ /bin/kill -f <PID>
> >
> > to call the Win32 function TerminateProcess(pid) on a non-Cygwin
> > process or an unresponsive Cygwin process.
>
> As I noted, it was not unique to control-C.  In any case, unfortunate to
> hear that Cygwin will not address this issue.  kill -f is clearly not
> desirable for doing a clean shutdown of a process.
There is no POSIXy way to cleanly shutdown a process if that process
is a native Windows process since said process will not honor any
signal sent to it.

The only way to do that in Windows is to use some kind of IPC to
communicate to the foreign process that it's supposed to shutdown.  If
that process is a Cygwin process, that's handled via sending a signal.
If that process is a native process, Cygwin has no control over it.


Corinna

--
Corinna Vinschen
Cygwin Maintainer

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug report: Killing a native process may not actually kill it

Kaz Kylheku
In reply to this post by Quanah Gibson-Mount
On 2019-08-28 08:59, Quanah Gibson-Mount wrote:

> --On Wednesday, August 28, 2019 6:45 PM +0200 Corinna Vinschen
> <[hidden email]> wrote:
>
>> Not likely.  Cygwin handles Ctrl-C by generating SIGINT.  This only
>> works reliably with Cygwin processes.  There's
>>
>>   $ /bin/kill -f <PID>
>>
>> to call the Win32 function TerminateProcess(pid) on a non-Cygwin
>> process or an unresponsive Cygwin process.
>
> As I noted, it was not unique to control-C.  In any case, unfortunate
> to hear that Cygwin will not address this issue.  kill -f is clearly
> not desirable for doing a clean shutdown of a process.

Cygwin can't introduce Unix-like shutdown mechanisms (like the
handling a non-fatal signal) into non-Cygwin processes which have
no concept of that. It makes no sense.

The Windows way to try to try to obtain a clean shutdown is to send a
message to a window handle (WM_CLOSE or WM_QUIT or whatever); then
if that fails, TerminateProcess rudely.

kill shouldn't try to translate signals to window handle messages;
it makes no sense.



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

Reply | Threaded
Open this post in threaded view
|

Re: Bug report: Killing a native process may not actually kill it

Quanah Gibson-Mount
--On Wednesday, August 28, 2019 2:33 PM -0700 Kaz Kylheku
<[hidden email]> wrote:

> Cygwin can't introduce Unix-like shutdown mechanisms (like the
> handling a non-fatal signal) into non-Cygwin processes which have
> no concept of that. It makes no sense.

My original post contained a link to a patch allowing for Cygwin to
correctly terminate native Windows processes.  I understand it is not the
position of the Cygwin project to deal with situation, so I think we can
just let it drop.

Regards,
Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>

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

Reply | Threaded
Open this post in threaded view
|

Re: Bug report: Killing a native process may not actually kill it

Steven Penny
On Wed, 28 Aug 2019 15:57:23, Quanah Gibson-Mount wrote:
> My original post contained a link to a patch allowing for Cygwin to
> correctly terminate native Windows processes.  I understand it is not the
> position of the Cygwin project to deal with situation, so I think we can
> just let it drop.

I would like to say that I support this, if it can be done in a reasonable way.

Ive been reading this thread carefully, and Ive yet to see anyone comment on the
merits of the patch. Apologies if Ive overlooked it.

To me, the first and only question that matters is "does it solve more problems
than it causes". If the answer is yes, I think the patch should be accepted.
Else I think its unfair to prematurely end the discussion.

Cygwin has a long history of... putting Cygwin first. I dont mean this as a
negative, although I do disagree with the sentiment. Any compiling is with
Cygwin target as first class citizen, then native Windows has always been an
afterthought. I think this is why the MinGW survived as long as it did, and
while the MSYS2 project enjoys the popularity it has today. With MSYS2, the
"Cygwin" mode is still primary, but you can launch "mingw64.exe" and native
Windows becomes the default.

If Cygwin wishes to remain insular in regard to this and other native Windows
issues, thats their choice. It does make development significantly easier I
assume. However I think in doing so it alienates significant portion of the
userbase.


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

Reply | Threaded
Open this post in threaded view
|

Re: Bug report: Killing a native process may not actually kill it

Ray Donnelly
On Thu, 29 Aug 2019, 02:38 Steven Penny, <[hidden email]> wrote:

> On Wed, 28 Aug 2019 15:57:23, Quanah Gibson-Mount wrote:
> > My original post contained a link to a patch allowing for Cygwin to
> > correctly terminate native Windows processes.  I understand it is not
> the
> > position of the Cygwin project to deal with situation, so I think we can
> > just let it drop.
>
> I would like to say that I support this, if it can be done in a reasonable
> way.
>
> Ive been reading this thread carefully, and Ive yet to see anyone comment
> on the
> merits of the patch. Apologies if Ive overlooked it.
>
> To me, the first and only question that matters is "does it solve more
> problems
> than it causes". If the answer is yes, I think the patch should be
> accepted.
> Else I think its unfair to prematurely end the discussion.
>
> Cygwin has a long history of... putting Cygwin first. I dont mean this as a
> negative, although I do disagree with the sentiment. Any compiling is with
> Cygwin target as first class citizen, then native Windows has always been
> an
> afterthought. I think this is why the MinGW survived as long as it did, and
> while the MSYS2 project enjoys the popularity it has today. With MSYS2, the
> "Cygwin" mode is still primary, but you can launch "mingw64.exe" and native
> Windows becomes the default.
>

We can consider the patch at msys2 also if you wish to propose it.

>
> If Cygwin wishes to remain insular in regard to this and other native
> Windows
> issues, thats their choice. It does make development significantly easier I
> assume. However I think in doing so it alienates significant portion of the
> userbase.
>
>
> --
> 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
>
>

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