Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Net::Ping croaks on DNS no-record #17

Open
michael-dev opened this issue Oct 8, 2019 · 5 comments
Open

Net::Ping croaks on DNS no-record #17

michael-dev opened this issue Oct 8, 2019 · 5 comments
Assignees
Labels
Milestone

Comments

@michael-dev
Copy link

I've been using Net::Ping 2.43 with the following code:

my $p = Net::Ping->new();
my $r = $p->ping($host);
if ($r) { ... } else { ... }

Though, $host sometimes contains a non-resolvable hostname. With Net::Ping 2.43, this resulted in the else branch being taking. Now the application exists, which is not what I need. Additionally, this is not documented - crashing the application if a dns name does not resolve.

This therefore should be disableable.

@michael-dev
Copy link
Author

error output_
getaddrinfo($host,,AF_INET) failed - Name or service not known at ... line ...

@rurban rurban self-assigned this Oct 9, 2019
@rurban
Copy link
Owner

rurban commented Apr 10, 2020

Are you sure you want a different error result object, when
ping fails? IMHO it's much more natural to return undef.

@michael-dev
Copy link
Author

The problem is not ping returning undef, I'm fine with this. The problem is ping doing croak, which terminates the perl interpreter and thus the application dies instead continuing to the if/else statement.

@rurban
Copy link
Owner

rurban commented Apr 14, 2020

Oh, that's a big problem, agreed

@rurban rurban added the bug label Apr 14, 2020
@rurban
Copy link
Owner

rurban commented Feb 22, 2021

I've added a new test for this problem.
ping does not croak on a wrong hostname, it just warns if the name cannot be resolved, but still returns undef. It only croaks on more severe problems, like wrong family, invalid params and such.

The warning is fair, since ping expects a IP and checks a route to the host. If the error is elsewhere, like in the resolver, this error is unexpected and thus warns. We cannot just silently ignore a resolver failure. We should only silently return undef when the route is off, but not when the DNS is off.

Can you check again where it croaks?

@rurban rurban added invalid and removed bug labels Feb 22, 2021
@rurban rurban added this to the 2.75 milestone Feb 22, 2021
rurban added a commit that referenced this issue Feb 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants