ctrl-c doesn't reliably kill applications

ctrl-c doesn't reliably kill applications

[Björn Stabel]

The ctrl-c shortcut doesn't reliably kill applications (anymore?).
It has been that way for at least a year now.

------------------------------------------------------------------------

One example is the ruby "rerun" tool (at least when used with a sinatra
app).
The problem can be reproduced using these steps:

 1. Default cygwin install
 2. Install rubygems package
 3. gem install rerun sinatra
 4. Make sure the rerun tool is in PATH (or specify the path to it
    explicitly). I think rubygems installs executables from gems to
    ~/bin by default
 5. rerun "ruby -e 'require(\"sinatra\")'"
 6. ctrl-c
 7. tasklist /fi "IMAGENAME eq ruby.exe"
      * Expected: No process
      * Actual: process is still running

You might have to repeat steps 5 to 7 a few times for the issue to occur.
Another problem is that Q sometimes doesn't exit rerun but only the app
running inside, but that might be a problem with rerun itself or with
the shutdown detection they use.

------------------------------------------------------------------------

Another example is Vagrant.
Although that is not a cygwin application, I usually recommend coworkers
to use it with cygwin, because it benefits from mintty's better console.
The problem there occurs when you invoke a long-running vagrant command
(vagrant provision, for instance) and then cancel it with ctrl-c.
If you do that, you're back at the bash prompt, but the provisioning run
still goes on and spams the console, making it unusable.

------------------------------------------------------------------------

Under Kubuntu Linux 14.04/kde/konsole/bash, neither of these problems exist.
What the two examples seem to have in common is that they're both one
application invoking another:

  * rerun invokes sh -c "$1" (I think)
  * vagrant provision invokes (its bundled?) ssh

I think this is a bug and should be fixed. Is the bug with Cygwin or
should I report it elsewhere?

- Björn Stabel aka. TomyLobo

--
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: ctrl-c doesn't reliably kill applications

[Kaz Kylheku]

On 14.03.2016 10:18, Björn Stabel wrote:
                      ^^^^^^^^^^^^

My eyes blinked there for a second! Nope, not the Xpilot
co-author, Norwegian Bjørn Stabell.

:)


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

ctrl-c doesn't reliably kill ping

[Frank Farance]

I have been having this problem with "ping".  If I "ping" a location that 
doesn't exist, then "ping" just hangs and cannot be killed via "kill -KILL [pid]".

A little digression, so you understand the background ... The workstation I am 
doing this from is connected to a Verizon router to their FIOS network.  Now the 
reason I mention this is that the router's DNS (via DHCP to my workstation) is 
192.168.1.1, which I presume is forwarded from the router upstream to Verizon's 
DNS caches.  So if I type the URL http://something.that.doesnt.exist in my 
browser, rather than getting a Hostname Not Found error (at the name resolution 
level), it actually loads up a page saying "something.that.doesnt.exist" isn't 
found and then I have a Yahoo set of search results on things matching the 
broken hostname.

So all of this is normal ISP stuff: they actually resolve unknown addresses to 
their own website (which is 90.242.140.21).

Ok, ending the digression ....

Back to the problem, so when I type

$ ping some.unknown.host

according to "ping", the hostname resolves to 90.242.140.21 (as per the 
explanation above), but I cannot kill "ping".  I tried "ping" with a limited 
packet size and count so, in theory, "ping" would die on its own after 10 
packets, such as:

$ ping some.unknown.host 50 10

but it still hangs rather than timing out.  If I ping to some actual IP address 
that is unresponsive (route-able to the last subnet, but dies on the floor at 
the end), then I can kill via ctrl-c.  My only solution to the hanging "ping" is 
to kill the terminal window.

Any suggestions on:

- Why "ping" behaves this way?
- How to avoid this problem?

Thanks, in advance.

-FF

-- 
______________________________________________________________________
Frank Farance, Farance Inc.    T: +1 212 486 4700   M: +1 917 751 2900
mailto:frank@farance.com       http://farance.com
Standards/Products/Services for Information/Communication Technologies

--
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: ctrl-c doesn't reliably kill ping

[Andrey Repin]

Greetings, Frank Farance!

> A little digression, so you understand the background ... The workstation I am
> doing this from is connected to a Verizon router to their FIOS network.  Now the
> reason I mention this is that the router's DNS (via DHCP to my workstation) is
> 192.168.1.1, which I presume is forwarded from the router upstream to Verizon's
> DNS caches.  So if I type the URL http://something.that.doesnt.exist in my 
> browser, rather than getting a Hostname Not Found error (at the name resolution
> level), it actually loads up a page saying "something.that.doesnt.exist" isn't
> found and then I have a Yahoo set of search results on things matching the 
> broken hostname.

> So all of this is normal ISP stuff: they actually resolve unknown addresses to
> their own website (which is 90.242.140.21).

This is NOT "normal", this is a violation of protocol.
Whoever encounter such behavior should call their ISP and tell them to stop
doing it.


-- 
With best regards,
Andrey Repin
Tuesday, March 15, 2016 13:59:48

Sorry for my terrible english...


--
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: ctrl-c doesn't reliably kill ping

[Adam Dinwoodie]

On Tue, Mar 15, 2016 at 02:00:38PM +0300, Andrey Repin wrote:
> Greetings, Frank Farance!
> 
> > A little digression, so you understand the background ... The workstation I am
> > doing this from is connected to a Verizon router to their FIOS network.  Now the
> > reason I mention this is that the router's DNS (via DHCP to my workstation) is
> > 192.168.1.1, which I presume is forwarded from the router upstream to Verizon's
> > DNS caches.  So if I type the URL http://something.that.doesnt.exist in my 
> > browser, rather than getting a Hostname Not Found error (at the name resolution
> > level), it actually loads up a page saying "something.that.doesnt.exist" isn't
> > found and then I have a Yahoo set of search results on things matching the 
> > broken hostname.
> 
> > So all of this is normal ISP stuff: they actually resolve unknown addresses to
> > their own website (which is 90.242.140.21).
> 
> This is NOT "normal", this is a violation of protocol.
> Whoever encounter such behavior should call their ISP and tell them to stop
> doing it.

It's both normal and a violation of protocol -- a lot of DNS servers,
will replace an NXDOMAIN response will "hijack" the query and return
something that punts the user onto a search page with advertising.

Regardless of how (non-)compliant the system's DNS servers are with the
relevant RFCs, ping's behaviour should never be to hang in the way Frank
is describing.

--
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: ctrl-c doesn't reliably kill ping

[cyg Simple]

On 3/15/2016 7:43 AM, Adam Dinwoodie wrote:
> On Tue, Mar 15, 2016 at 02:00:38PM +0300, Andrey Repin wrote:
>> Greetings, Frank Farance!
>>
>>> A little digression, so you understand the background ... The workstation I am
>>> doing this from is connected to a Verizon router to their FIOS network.  Now the
>>> reason I mention this is that the router's DNS (via DHCP to my workstation) is
>>> 192.168.1.1, which I presume is forwarded from the router upstream to Verizon's
>>> DNS caches.  So if I type the URL http://something.that.doesnt.exist in my 
>>> browser, rather than getting a Hostname Not Found error (at the name resolution
>>> level), it actually loads up a page saying "something.that.doesnt.exist" isn't
>>> found and then I have a Yahoo set of search results on things matching the 
>>> broken hostname.
>>
>>> So all of this is normal ISP stuff: they actually resolve unknown addresses to
>>> their own website (which is 90.242.140.21).
>>
>> This is NOT "normal", this is a violation of protocol.
>> Whoever encounter such behavior should call their ISP and tell them to stop
>> doing it.
> 
> It's both normal and a violation of protocol -- a lot of DNS servers,
> will replace an NXDOMAIN response will "hijack" the query and return
> something that punts the user onto a search page with advertising.
> 

This should probably be moved to cygwin-talk but ...

If a violation becomes normal then it is no longer a violation but an
accepted practiced exception.  Unless a rule is enforced the accepted
practiced exception becomes the rule.

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

Re: ctrl-c doesn't reliably kill ping

[Kaz Kylheku]

On 15.03.2016 04:00, Andrey Repin wrote:
> Greetings, Frank Farance!
>> So all of this is normal ISP stuff: they actually resolve unknown 
>> addresses to
>> their own website (which is 90.242.140.21).
> 
> This is NOT "normal", this is a violation of protocol.
> Whoever encounter such behavior should call their ISP and tell them to 
> stop
> doing it.

Or don't tell them anything and just find an alternative DNS upstream
for your network.


--
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: ctrl-c doesn't reliably kill ping

[Andrey Repin]

Greetings, Kaz Kylheku!

> On 15.03.2016 04:00, Andrey Repin wrote:
>> Greetings, Frank Farance!
>>> So all of this is normal ISP stuff: they actually resolve unknown 
>>> addresses to
>>> their own website (which is 90.242.140.21).
>> 
>> This is NOT "normal", this is a violation of protocol.
>> Whoever encounter such behavior should call their ISP and tell them to 
>> stop
>> doing it.

> Or don't tell them anything and just find an alternative DNS upstream
> for your network.

"Suck it up" is not an attitude that leads to a better world to live in.


-- 
With best regards,
Andrey Repin
Wednesday, March 16, 2016 14:45:56

Sorry for my terrible english...


--
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: ctrl-c doesn't reliably kill ping

[cyg Simple]

On 3/16/2016 12:56 AM, Kaz Kylheku wrote:
> On 15.03.2016 04:00, Andrey Repin wrote:
>> Greetings, Frank Farance!
>>> So all of this is normal ISP stuff: they actually resolve unknown
>>> addresses to
>>> their own website (which is 90.242.140.21).
>>
>> This is NOT "normal", this is a violation of protocol.
>> Whoever encounter such behavior should call their ISP and tell them to
>> stop
>> doing it.
> 
> Or don't tell them anything and just find an alternative DNS upstream
> for your network.

My ISP for my connection to the WWW is the one that is doing the
inappropriate redirects.  I sometime get these even when using VPN to my
employer's intranet.  My ISP also provides phone and TV Cable and I'm
guessing that the accepted practiced exception is practiced by all such
companies.

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

Re: ctrl-c doesn't reliably kill ping

[Michael Enright]

On Wed, Mar 16, 2016 at 7:51 AM, cyg Simple wrote:
>
> My ISP for my connection to the WWW is the one that is doing the
> inappropriate redirects.  I sometime get these even when using VPN to my
> employer's intranet.  My ISP also provides phone and TV Cable and I'm
> guessing that the accepted practiced exception is practiced by all such
> companies.
>

Can confirm. Readers may be interested to learn that I tried to set
the DNS manually in the connection properties of my VPN connection (to
the exact same thing the VPN connection would have configured anyway)
but this did not work either. I used my ISP's opt-out page and that
didn't help. I also learned how to empty DNS caches in Windows
(ipconfig /flushdns) and Google Chrome (chrome://net-internals/#dns)
and none of those measures was effective. I couldn't use the wiki with
its IP address because the links apparently are full paths and there's
redirects involved (with full paths) and every complete URL goes to
name resolution. It was as if  (that means I'm speculating here) as if
using the standard DNS port was causing the ISP to DPI my DNS
requests. Or maybe they are just looking in all the packets. Could the
revenue from those bogus links be so high???

--
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: ctrl-c doesn't reliably kill ping

[Kaz Kylheku]

On 16.03.2016 08:57, Michael Enright wrote:
> On Wed, Mar 16, 2016 at 7:51 AM, cyg Simple wrote:
>> 
>> My ISP for my connection to the WWW is the one that is doing the
>> inappropriate redirects.  I sometime get these even when using VPN to 
>> my
>> employer's intranet.  My ISP also provides phone and TV Cable and I'm
>> guessing that the accepted practiced exception is practiced by all 
>> such
>> companies.
>> 
> 
> Can confirm. Readers may be interested to learn that I tried to set
> the DNS manually in the connection properties of my VPN connection (to
> the exact same thing the VPN connection would have configured anyway)
> but this did not work either.

You have to point your local network's router to some alternative DNS
servers. You shouldn't have to do anything in an individual client
workstations and devices.

Example: I have dnmasq running on a Linksys wireless router. All my
machines here obtain their DHCP from that and point their DNS resolvers
to it (because the DHCP tells them to).

If I weren't happy with upstream DNS, I'd go into the router's
configuration and tell dnsmasq to send its queries to some alternative
DNS.


--
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: ctrl-c doesn't reliably kill ping

[Lee]

> If I weren't happy with upstream DNS, I'd go into the router's
> configuration and tell dnsmasq to send its queries to some alternative
> DNS.

Instructions for Verizon customers to opt out of "DNS Assistance" are here:
  https://www.verizon.com/support/consumer/internet/opt-out-of-dns-assist

Lee

--
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: ctrl-c doesn't reliably kill ping

[Frank Farance]

Folks-

Thank you for the thoughtful observations, responses, and suggestions, which I 
will summarize:

- Suggestion #1: Try different DNS settings not using Verizon.
- Suggestion #2: Try different Verizon configuration.
- Suggestion #3: Try Windows version of ping.
- Observation #4: This shouldn't work unless I am administrator (FYI: I've 
configured the cygwin terminal to run as administrator).
- Question #5: Am I running the windows ping?  Answer: Nope, I did "type ping", 
which returned "/usr/bin/ping".

Regarding Verizon, and possibly different settings, my point was not to identify 
flaws in Verizon, I just wanted to give you background on the problem - and I 
believe people understand its nature.  I am well aware of well-known DNS 
servers, such as 8.8.8.8 and 8.8.4.4 -- I am Old School, so I still occasionally 
use the UUNET DNS caches 198.6.1.? to test stuff. :-)

Regarding incompatible ISPs, I believe the program should be robust enough to 
succeed, robust enough to fail, but it shouldn't hang and become non-interruptable.

So from a POSIX compatibility and operating system kernel perspective, I am 
surprised that it is possible to write an application program that gets into an 
non-interruptable state.  In traditional UNIX kernels, it was possible to get 
stuck in a *hard* wait (like local hard drive access), but I don't understand 
how this is possible with ping or any other network application.

Perhaps I don't understand the cygwin signal mechanism and someone can point me 
in the right direction for ping.  Perhaps someone can explain how ping can get 
into this state.

Anyway, as we'd say in standardizing the C programming language, this behavior 
is a "surprise" ... and we should look to eliminate "surprises".

Again, thank you in advance for your help.

-FF


-- 
______________________________________________________________________
Frank Farance, Farance Inc.    T: +1 212 486 4700   M: +1 917 751 2900
mailto:frank@farance.com       http://farance.com
Standards/Products/Services for Information/Communication Technologies

--
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: ctrl-c doesn't reliably kill ping

[Marco Atzeri]

On 17/03/2016 22:10, Frank Farance wrote:
> Folks-
>

>
> Anyway, as we'd say in standardizing the C programming language, this
> behavior is a "surprise" ... and we should look to eliminate "surprises".
>
> Again, thank you in advance for your help.
>
> -FF
>
>

as mentioned on:
https://cygwin.com/ml/cygwin/2016-03/msg00312.html

can you send me a strace to see where the program is stacking ?
No promise to find a solution but I will look on it.

Regards
Marco

--
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: ctrl-c doesn't reliably kill ping

[Warren Young]

On Mar 14, 2016, at 6:45 PM, Frank Farance <frank@farance.com> wrote:
> 
> I have been having this problem with "ping".  If I "ping" a location that doesn't exist, then "ping" just hangs and cannot be killed via "kill -KILL [pid]”.

Are you certain that you’re using the Cygwin ping, and not the native Windows ping?

Cygwin ping requires admin privileges, so you’d definitely know if you were using it.  In a non-Admin shell, you see:

  $ ping gw
  ping: socket: Operation not permitted

You can’t expect native Windows executables to respond in a POSIXy way to POSIX signals.

(As for “why” Cygwin ping requires admin privileges and native ping does not, it’s because native ping uses a special DLL that avoids the need for raw sockets.  Cygwin ping requires raw sockets in order to do things in a POSXYy way.)

> if I type the URL http://something.that.doesnt.exist in my browser, rather than getting a Hostname Not Found error (at the name resolution level), it actually loads up a page saying "something.that.doesnt.exist" isn't found and then I have a Yahoo set of search results on things matching the broken hostname.

Use GRC’s DNS benchmark to find a DNS server that is not only fast but also standards-compliant:

  https://www.grc.com/dns/benchmark.htm

If you can’t be bothered, use Google’s DNS: 8.8.8.8 and 8.8.4.4.
--
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: ctrl-c doesn't reliably kill ping

[Marco Atzeri]

On 15/03/2016 01:45, Frank Farance wrote:
> I have been having this problem with "ping".  If I "ping" a location
> that doesn't exist, then "ping" just hangs and cannot be killed via
> "kill -KILL [pid]".
>
>
> Back to the problem, so when I type
>
> $ ping some.unknown.host
>

I do not succeed to replicate.
CTRL-C works fine for me

$ type ping
ping is hashed (/usr/bin/ping)

$ ping 172.21.1.254
PING 172.21.1.254 (172.21.1.254): 56 data bytes

----172.21.1.254 PING Statistics----
4 packets transmitted, 0 packets received, 100.0% packet loss

or I have not a biased DNS answer.

> according to "ping", the hostname resolves to 90.242.140.21 (as per the
> explanation above), but I cannot kill "ping".  I tried "ping" with a
> limited packet size and count so, in theory, "ping" would die on its own
> after 10 packets, such as:
>
> $ ping some.unknown.host 50 10
>
> but it still hangs rather than timing out.  If I ping to some actual IP
> address that is unresponsive (route-able to the last subnet, but dies on
> the floor at the end), then I can kill via ctrl-c.  My only solution to
> the hanging "ping" is to kill the terminal window.
>
> Any suggestions on:
>
> - Why "ping" behaves this way?
> - How to avoid this problem?
>
> Thanks, in advance.

cygwin ping is based on very old source from a time where people was not
cheating on protocol answer.

http://ftp.arl.mil/mike/ping.html
(the author passed away 16 years ago..)

can you send me a strace to see where the program is stacking ?
No promise to find a solution but I will look on it.

Regards
Marco





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

ctrl-c doesn't reliably kill applications

[Björn Stabel]

I couldn't replicate it either, but the question I started this thread
with is unrelated to either of the ping tools.
Here it is again:

The ctrl-c shortcut doesn't reliably kill applications (anymore?).
It has been that way for at least a year now.

------------------------------------------------------------------------

One example is the ruby "rerun" tool (at least when used with a sinatra
app).
The problem can be reproduced using these steps:

 1. Default cygwin install
 2. Install rubygems package
 3. gem install rerun sinatra
 4. Make sure the rerun tool is in PATH (or specify the path to it
    explicitly). I think rubygems installs executables from gems to
    ~/bin by default
 5. rerun "ruby -e 'require(\"sinatra\")'"
 6. ctrl-c
 7. tasklist /fi "IMAGENAME eq ruby.exe"
      * Expected: No process
      * Actual: process is still running

You might have to repeat steps 5 to 7 a few times for the issue to occur.
Another problem is that Q sometimes doesn't exit rerun but only the app
running inside, but that might be a problem with rerun itself or with
the shutdown detection they use.

------------------------------------------------------------------------

Another example is Vagrant.
Although that is not a cygwin application, I usually recommend coworkers
to use it with cygwin, because it benefits from mintty's better console.
The problem there occurs when you invoke a long-running vagrant command
(vagrant provision, for instance) and then cancel it with ctrl-c.
If you do that, you're back at the bash prompt, but the provisioning run
still goes on and spams the console, making it unusable.

------------------------------------------------------------------------

Under Kubuntu Linux 14.04/kde/konsole/bash, neither of these problems exist.
What the two examples seem to have in common is that they're both one
application invoking another:

  * rerun invokes sh -c "$1" (I think)
  * vagrant provision invokes (its bundled?) ssh

I think this is a bug and should be fixed. Is the bug with Cygwin or
should I report it elsewhere?

- Björn Stabel aka. TomyLobo



Am 16.03.2016 um 14:24 schrieb Marco Atzeri:
>
>
> On 15/03/2016 01:45, Frank Farance wrote:
>> I have been having this problem with "ping".  If I "ping" a location
>> that doesn't exist, then "ping" just hangs and cannot be killed via
>> "kill -KILL [pid]".
>>
>>
>> Back to the problem, so when I type
>>
>> $ ping some.unknown.host
>>
>
> I do not succeed to replicate.
> CTRL-C works fine for me
>
> $ type ping
> ping is hashed (/usr/bin/ping)
>
> $ ping 172.21.1.254
> PING 172.21.1.254 (172.21.1.254): 56 data bytes
>
> ----172.21.1.254 PING Statistics----
> 4 packets transmitted, 0 packets received, 100.0% packet loss
>
> or I have not a biased DNS answer.
>
>> according to "ping", the hostname resolves to 90.242.140.21 (as per the
>> explanation above), but I cannot kill "ping".  I tried "ping" with a
>> limited packet size and count so, in theory, "ping" would die on its own
>> after 10 packets, such as:
>>
>> $ ping some.unknown.host 50 10
>>
>> but it still hangs rather than timing out.  If I ping to some actual IP
>> address that is unresponsive (route-able to the last subnet, but dies on
>> the floor at the end), then I can kill via ctrl-c.  My only solution to
>> the hanging "ping" is to kill the terminal window.
>>
>> Any suggestions on:
>>
>> - Why "ping" behaves this way?
>> - How to avoid this problem?
>>
>> Thanks, in advance.
>
> cygwin ping is based on very old source from a time where people was not
> cheating on protocol answer.
>
> http://ftp.arl.mil/mike/ping.html
> (the author passed away 16 years ago..)
>
> can you send me a strace to see where the program is stacking ?
> No promise to find a solution but I will look on it.
>
> Regards
> Marco
>
>
>
>
>
> -- 
> 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

Re: ctrl-c doesn't reliably kill applications

[Aaron Digulla]

On 17.03.2016 21:04, Björn Stabel wrote:
> I couldn't replicate it either, but the question I started this thread
> with is unrelated to either of the ping tools.
> Here it is again:
>
> The ctrl-c shortcut doesn't reliably kill applications (anymore?).
> It has been that way for at least a year now.

I can confirm that. It's worse with native applications. In my case, I
have scripts which invoke Maven (a Java application).

Ctrl+C kills the script but the signal isn't forwarded to the Windows
process, so the Java process is stuck in the background.

To make matters worse, it tries to write to stdout which isn't properly
connected anymore. This can lead to Windows starting to trash the
harddrive until you have to turn off the computer.

Might be related to Ctrl+S/Ctrl+W handling as well (Unix kind of Scroll
Lock) which is also broken for native programs (you can freeze them but
Ctrl+W has no effect anymore until Windows freezes).

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits." 
http://blog.pdark.de/


--
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: ctrl-c doesn't reliably kill applications

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]

On Apr 18 23:38, Aaron Digulla wrote:
> On 17.03.2016 21:04, Björn Stabel wrote:
> > I couldn't replicate it either, but the question I started this thread
> > with is unrelated to either of the ping tools.
> > Here it is again:
> >
> > The ctrl-c shortcut doesn't reliably kill applications (anymore?).
> > It has been that way for at least a year now.
> 
> I can confirm that. It's worse with native applications. In my case, I
> have scripts which invoke Maven (a Java application).
> 
> Ctrl+C kills the script but the signal isn't forwarded to the Windows
> process, so the Java process is stuck in the background.
> 
> To make matters worse, it tries to write to stdout which isn't properly
> connected anymore. This can lead to Windows starting to trash the
> harddrive until you have to turn off the computer.
> 
> Might be related to Ctrl+S/Ctrl+W handling as well (Unix kind of Scroll
> Lock) which is also broken for native programs (you can freeze them but
> Ctrl+W has no effect anymore until Windows freezes).

Shouldn't that be Ctrl-Q?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: ctrl-c doesn't reliably kill applications

[Aaron Digulla]

Am Dienstag, 19. April 2016 10:11 CEST, Corinna Vinschen <corinna-cygwin@cygwin.com> schrieb:

> On Apr 18 23:38, Aaron Digulla wrote:
> > On 17.03.2016 21:04, Björn Stabel wrote:
> > > I couldn't replicate it either, but the question I started this thread
> > > with is unrelated to either of the ping tools.
> > > Here it is again:
> > >
> > > The ctrl-c shortcut doesn't reliably kill applications (anymore?).
> > > It has been that way for at least a year now.
> >
> > I can confirm that. It's worse with native applications. In my case, I
> > have scripts which invoke Maven (a Java application).
> >
> > Ctrl+C kills the script but the signal isn't forwarded to the Windows
> > process, so the Java process is stuck in the background.
> >
> > To make matters worse, it tries to write to stdout which isn't properly
> > connected anymore. This can lead to Windows starting to trash the
> > harddrive until you have to turn off the computer.
> >
> > Might be related to Ctrl+S/Ctrl+W handling as well (Unix kind of Scroll
> > Lock) which is also broken for native programs (you can freeze them but
> > Ctrl+W has no effect anymore until Windows freezes).
>
> Shouldn't that be Ctrl-Q?

I had that feeling while typing the mail ... yes, of course. The key sequence is hardcoded in my fingers, so my brain mostly forgot about which keys have to be pressed :-)

The issue is the same, though. Ctrl+S makes Windows crash if a native process is currently trying to write to the mintty console.

Regards,


--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://blog.pdark.de/


--
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: ctrl-c doesn't reliably kill ping

[Lee]

Hi,

On 3/14/16, Frank Farance wrote:
> I have been having this problem with "ping".  If I "ping" a location that
> doesn't exist, then "ping" just hangs and cannot be killed via "kill -KILL
> [pid]".
>
> A little digression, so you understand the background ... The workstation I
> am
> doing this from is connected to a Verizon router to their FIOS network.  Now
> the
> reason I mention this is that the router's DNS (via DHCP to my workstation)
> is
> 192.168.1.1, which I presume is forwarded from the router upstream to
> Verizon's
> DNS caches.  So if I type the URL http://something.that.doesnt.exist in my
> browser, rather than getting a Hostname Not Found error (at the name
> resolution
> level), it actually loads up a page saying "something.that.doesnt.exist"
> isn't
> found and then I have a Yahoo set of search results on things matching the
> broken hostname.
>
> So all of this is normal ISP stuff: they actually resolve unknown addresses
> to
> their own website (which is 90.242.140.21).

Right.  If you poke around on the Verizon site long enough you'll find
where they list the resolvers that return NXDOMAIN instead of the
address of their ad site.   & sorry, no, I didn't save the url, but
try changing the last octet of the resolver addresses on your fios
router to .14 & see if that works.


> Ok, ending the digression ....
>
> Back to the problem, so when I type
>
> $ ping some.unknown.host
>
> according to "ping", the hostname resolves to 90.242.140.21 (as per the
> explanation above), but I cannot kill "ping".  I tried "ping" with a limited
>
> packet size and count so, in theory, "ping" would die on its own after 10
> packets, such as:
>
> $ ping some.unknown.host 50 10
>
> but it still hangs rather than timing out.  If I ping to some actual IP
> address
> that is unresponsive (route-able to the last subnet, but dies on the floor
> at
> the end), then I can kill via ctrl-c.  My only solution to the hanging
> "ping" is
> to kill the terminal window.
>
> Any suggestions on:
>
> - Why "ping" behaves this way?
> - How to avoid this problem?

The last time I tried the cygwin ping program it didn't return a
failure status - ie
ping whatever
and $? was always 0 -- so it's basically useless.   I'd suggest you
use the windows version of ping:

$ which ping
/cygdrive/c/windows/system32/ping

$ ping www.examle.com

Pinging www.examle.com [69.172.201.208] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 69.172.201.208:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

$ echo $?
1

$ ping does-not-exist.example.com.
Ping request could not find host does-not-exist.example.com.. Please
check the name and try again.

$ echo $?
1

$ ping www.google.com.

Pinging www.google.com [74.125.196.105] with 32 bytes of data:
Reply from 74.125.196.105: bytes=32 time=19ms TTL=45
Reply from 74.125.196.105: bytes=32 time=21ms TTL=45
Reply from 74.125.196.105: bytes=32 time=23ms TTL=45
Reply from 74.125.196.105: bytes=32 time=22ms TTL=45

Ping statistics for 74.125.196.105:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 19ms, Maximum = 23ms, Average = 21ms

$ echo $?
0


Regards,
Lee

--
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: ctrl-c doesn't reliably kill ping

[Warren Young]

On Mar 16, 2016, at 10:07 AM, Lee <ler762@gmail.com> wrote:
> 
> The last time I tried the cygwin ping program it didn't return a
> failure status

It does if you don’t Ctrl-C out of it.  So, if you’re using it from a script, you just ask for one packet:

    # ping does.not.exist 1 1
    ping: unknown host does.not.exist
    # echo $?
    1

Note my fine new # prompt, indicating an admin shell, which has been required for Cygwin ping from the very beginning[1] due to the restrictions on raw sockets added in Windows XP SP2.  Windows ping gets around this by special dispensation of the kernel.[2]

If you want to say Cygwin ping is “useless” because of that, blame Microsoft for not allowing ICMP raw sockets for normal users [3] or for not reinventing suid bits correctly.  (UAC = not correct.)

Older Linuxes and some modern Unixes set the suid bit on the ping program to get around this, and newer Linuxes use getcap/setcap to give the ping program the right to use raw sockets so they don’t need u+s.[4]


[1] https://cygwin.com/ml/cygwin-apps/2005-01/msg00124.html
[2] It loads IPHLPAPI.DLL at run time in order to call IcmpSendEcho()
[3] https://goo.gl/o25d6U
[4] http://linux.die.net/man/8/setcap
--
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: ctrl-c doesn't reliably kill ping

[Lee]

On 3/16/16, Warren Young <wyml@etr-usa.com> wrote:
> On Mar 16, 2016, at 10:07 AM, Lee <ler762@gmail.com> wrote:
>>
>> The last time I tried the cygwin ping program it didn't return a
>> failure status
>
> It does if you don’t Ctrl-C out of it.  So, if you’re using it from a
> script, you just ask for one packet:
>
>     # ping does.not.exist 1 1
>     ping: unknown host does.not.exist
>     # echo $?
>     1

Thanks for the info - nice to know that the cygwin version of ping is
getting better.
Not that it's going to make any difference to me & my scripts, but

$ which ping
/cygdrive/c/windows/system32/ping

$ ping www.examle.com

Pinging www.examle.com [69.172.201.208] with 32 bytes of data:
Request timed out.
Request timed out.
<crtl>C

$ echo $?
130

> Note my fine new # prompt, indicating an admin shell, which has been
> required for Cygwin ping from the very beginning[1] due to the restrictions
> on raw sockets added in Windows XP SP2.

I've had a windows admin account for doing admin type things and a
user account with no special/extra privs for normal use ever since I
started using Win-XP, so the requirement to be running as admin (or
answer a UAC prompt) puts cygwin ping into the "does not meet my
needs" category.

>  Windows ping gets around this by
> special dispensation of the kernel.[2]
>
> If you want to say Cygwin ping is “useless” because of that,

My apologies.  If I offended you or anyone else it wasn't intentional.
I should have done a better job with my wording :(

Best Regards,
Lee

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