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

40+ second load time when there is no internet connection available #101

Closed
jdgordon opened this issue Dec 6, 2017 · 8 comments · May be fixed by Strykar/SmokePing#2
Closed

40+ second load time when there is no internet connection available #101

jdgordon opened this issue Dec 6, 2017 · 8 comments · May be fixed by Strykar/SmokePing#2

Comments

@jdgordon
Copy link

jdgordon commented Dec 6, 2017

Hi,

I've installed the version of smokeping provided by ubuntu
$ smokeping --version
2.006011

and I'm seeing a really annoying problem.

When the computer running smokeping does not have a working internet connection (i.e ISP drop outs) loading a ?target= page takes 40s to start the initial GET. Loading the same page with the internet working takes <1s to fully render.

I have observed this with both curl and wget on the same machine and chrome and edge over the local LAN.

Happy to provide whatever info is needed to figure this out.

Thanks
Jonathan

@4f96a64d
Copy link

4f96a64d commented Dec 6, 2017

You could try running strace on the apache2 process with and without internet and see what's different. Might give you some idea where to start looking.
Another test might be to remove the DNS servers from resolv.conf with a working internet connection and see if you see the same issue.

B

@mickeyreg
Copy link

I've observed probably the same problem on smokeping 2.006011 on FreeBSD. I've lost the Internet connection and I wanted to enter my local smokeping site to see when it was lost. I saw "internal error" in the browser and I wanted to restart smokeping. The start was impossible because one of the domain addresses in the configuration could not be resolved.

It was first time when the problem appeared, but about two weeks ago I've added some internet host using domain names to my configuration. There was only IPs in the config before.

So it seems that the problem with DNS server causes problem with somkeping run/restart.

@adamcohen
Copy link

adamcohen commented Dec 6, 2018

I'm running into the same issue on SmokePing-2.6.11 on raspbian stretch, which is really annoying, since the entire purpose of running smokeping is to give me insight into when my internet connection has dropped, so if I can't view the smokeping output when this happens, it's not very useful.

I'm going to try set all host= values to ip addresses to see if it makes a difference

Strykar added a commit to Strykar/SmokePing that referenced this issue Mar 13, 2019
Distribution package maintainers should customize username/paths as appropriate.
Should close oetiker#101
Tested on Smokeping version 2.006000 / Arch linux
Some official distro package maintainers should review this once
@llewxam-kache
Copy link

Ran into this issue this morning when our ISP decided to cut out for 5 hours. I wanted to see when it started and couldn't get the Smokeping gui to load, even though the VM it runs on was working fine.
Is there not a timeout for DNS resolution or ping time?

@ertyu
Copy link

ertyu commented Apr 20, 2021

Experienced an outage yesterday and this annoyance once again reared its head, is there any direction as to what causes it or how to avoid it?

@mickeyreg
Copy link

On the server when my smokping instance works I've run also bind9 in forward only mode, and set localhost as DNS server. It looks like problem has gone away for me...

@ertyu
Copy link

ertyu commented Apr 20, 2021

On the server when my smokping instance works I've run also bind9 in forward only mode, and set localhost as DNS server. It looks like problem has gone away for me...

I also have a local bind9 resolver so it's not that specifically, the webpage should have no need to resolve anything anyway

@github-actions
Copy link

This issue has become stale and will be closed automatically within 7 days. Comment on the issue to keep it alive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants