'Request timed out'

[MasterXX]

On every check, i get a request timed out. After one minute it goes up again, but the website wasn't even off. Is it my server configuration?

[basvdheijden]

I wonder about the same thing..

[basvdheijden]

Maybe it'd be nice to check if uptime is connected to the internet prior to displaying 'offline' messages?

[TheFrogDaddy]

I am also suffering from this issue

[goonoo]

Same here.

[ismaelpuerto]

Same here, Currenly I use vps for app.js and 3 more for monitor.js

[brantje]

Yea same here

[lippoliv]

:+1: I ran 92 Checks, most per Minute, 6 per 10 Minutes and 2 per 30 seconds...

I think as longer as the Monitor is running, as more it is difficult for him to handle multiple checks.. Watch my Screenshot

The Red once was the Monitoring BEFORE an Reboot, running round about 24 Hours (I set up Uptime yesterday), than I rebooted, the checks are highlighted in Green... No timeout.

[brantje]

Should it come because some kind of connection limit?

[lippoliv]

Don't know. Since the Reboot, there where no "false positives" checks, I have just 4 down-checks, and theese once has to be down.

I had read arround and set up "net.core.somaxconn" to 1024, read that the Default value is may to less for an System with much Connections. There are also some additional Parameters to set to a higher value, but currently I just modifyed that one.

To do so I added the line

net.core.somaxconn = 1024

to /etc/sysctl.conf and rebooted the System.

Now I let it run for a cupple of hours.

These false-positives I had for months with "Zabbix" wich I previous ran on that VPS to check my Hosted Websites, may it's really an System-Configuration-Problem. Than it would be good to write an "real" setup-documentation where also the system-modification should be documented.

[mflopez79]

@lippoliv did the "net.core.somaxconn" setting made effect? We're facing a similar problem and want to make sure if the modification of the parameter is worth it

[lippoliv]

@mflopez79 No, the modification didn't Change that Problem. Even if my range is better than yours (wrong Pings all 30 to 120 Minutes)

[traskat]

i made a little change in the file httpPoller.js for the poll function

old one:

HttpPoller.prototype.poll = function() {
  HttpPoller.super_.prototype.poll.call(this);

  this.request = http.get(this.target, this.onResponseCallback.bind(this));
  this.request.on('error', this.onErrorCallback.bind(this));
};

new one:

HttpPoller.prototype.poll = function() {
  HttpPoller.super_.prototype.poll.call(this);
  this.target.agent = false;

  this.request = http.request(this.target, this.onResponseCallback.bind(this));
  this.request.on('error', this.onErrorCallback.bind(this));

  this.request.end();
};

works much better for me. can someone please test also maybe? would be nice to get some feedback.

[soullivaneuh]

@traskat not tested yet but looks great.

What this.target.agent = false; mean?

Maybe you can mare a PR for it.

[lippoliv]

Please Keep this issue up to date. Currently, because of this issue, I don't use uptime...

If an solution is found, I will setup uptime again :)

[basvdheijden]

me too, @lippoliv

[TheFrogDaddy]

@BasVanDerHeijden @lippoliv Me too! The problem is there are 34 outstanding pull requests so I don't think it would get implemented very soon. I did have a nosey at all the forks to see if this was fixed by anybody else or at least find one thats regularly contributed to, I think we should all jump on one of them. This product has great potential but sadly not maintained by fzaninotto any longer.

[brantje]

Looking at the network graph seems that @nerevu merged some forks into his one. Maybe we can use his as base of the 'new' uptime. I've asked @fzaninotto a few month's back if he wants to pickup this project again, he said he was too busy, i can understand that. So now its up to us to pick it up and use a central GIT repo for it.

[booherbg]

Did any of these fixes make a difference? I'm monitoring 20 servers, and each one goes down due to "request timeout" about once or twice per day (or more). Seems to get worse the longer it's running.

I checked the logs on the servers, and the request doesn't make it. Meaning it's some kind of choke on the monitoring server http client, not on the server that is getting checked.

edit: I'm trying the 'request-timeout-fix' branch on this fork: https://github.com/SpringerPE/uptime/tree/request-timeout-fix

I'll report back to see if it makes a difference.

[booherbg]

That fork works OK -- but I still get timeouts. Plus it ignores the headers completely (hard coded GET).

Interestingly, on my laptop I don't get timeouts so I think it boils down to infrastructure or operating system. I'm going to spin up CentOS or BSD and see if it makes a difference.

[traskat]

@booherbg. I tried a bit more. But couldn't verify it. For me it looks like that The polling oft The monitor isn't Wirkung correct. With pooling i mean the timer functions. But i couldn't verify vor test it till now.