Start a new topic

Monitoring CrushFTP wit Nagios: possible keep-alive problem?

Tuxdiver @ Wed Feb 26 05:07:50 EET 2014
Hi,

(CrushFTP Version 6.4.0_139)

I tried to monitor the CrushFTP-Services with Nagios. But the "check_http" always gets a timeout after 10 seconds (the default timeout for this check), so I tried to figure out the problem.

Doing an "telnet crush-server 80" and then "GET / HTTP/1.0", it sends a redirection to the login page but does not terminate the current connection - as it should, if I did not request a "Keep-Alive" Connection.

The connection is then terminated after 30 seconds.

Is it possible, that CrushFTP always assumes a "Keep-Alive", even if the "browser" does not request it?

Best regards,

Dirk

spinkb @ Wed Feb 26 05:38:55 EET 2014
It is the default if the client does not specify:

Connection: close

Thanks,
Ben
Tuxdiver @ Wed Feb 26 06:24:02 EET 2014
Hmm, as far as I know, Keep-Alive was invented with HTTP/1.1 - not HTTP/1.0.

Here is something from http://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-01.html

[quote]The semantics of Connection are defined by HTTP/1.1 in order to provide a safe transition to connection-based features. Connection header fields received in an HTTP/1.0 message, as would be the case if an older proxy mistakenly forwards the field, cannot be trusted and must be discarded except under experimental conditions.[/quote]

So I would expect all HTTP/1.0 connections to not use Keep-Alive, at least, when there is no connection header present, and all HTTP/1.1 with Keep-Alive on by default. Maybe the server could use Keep-Alive under HTTP/1.0 , but only if the client sends a "Connection: Keep-Alive".

And additionally:
[quote]The persistent connection ends when either side closes the connection or after the receipt of a response which lacks the "keep-alive" keyword. The server may close the connection immediately after responding to a request without a "keep-alive" keyword. A client can tell if the connection will be closed by looking for a "keep-alive" in the response.[/quote]

So even if CrushFTP would assume a Keep-Alive, it has to send the "Connection: Keep-Alive" in its respond (which it does not in requesting the "/" url):

[code]blade08:~# telnet XXXXXXX 80
Trying XXXXXXXXXXx...
Connected to XXXXXXXXX.
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.0 302 Redirect
Set-Cookie: mainServerInstance=; path=/
Set-Cookie: CrushAuth=1393417288630_d6HydQPFBY1fG5zo9XNgAu5ufgVatl; path=/
Pragma: no-cache
location: HTTP:///WebInterface/login.html
Content-Length: 0

Connection closed by foreign host.[/code]


Apache2.2 and nginx both do it other (= the way I would expect it) than CrushFTP.

Because of this behavior, CrushFTP is the only HTTP-Server I could not monitor with nagios - which is bad :-(

Regards,
Dirk
spinkb @ Wed Feb 26 06:33:10 EET 2014
You are correct. Latest build now adds the default for the login request to specify close for this scenario.

Update now and it will work for you.

Thanks,
Ben
Tuxdiver @ Wed Feb 26 06:40:17 EET 2014
Hi Ben,

thanks (again!) for your [b]VERY FAST[/b] support! Nagios and I are lucky again :D

With best regards from germany,

Dirk
Tuxdiver @ Sun Oct 12 13:24:20 EEST 2014
Hi Ben,

I just upgraded to 7.1.0 Build 173 and the "bug" is back again :-(

With best regards from germany,

Dirk
spinkb @ Sun Oct 12 17:24:08 EEST 2014
Please try the current build now. Is this fixed for you?

7.1.0_174

Thanks,
Ben
Tuxdiver @ Sun Oct 12 17:39:08 EEST 2014
Hi Ben,

thanks for quick new build - but it is still not working.

But I found a workaround in nagios: the "-N" switch ignores the body of the result and only looks at the headers, so nagios is working again. But I still think it's wrong to use "KeepAlive" in an HTTP/1.0 answer without the client requesting it... :-)

Anyway: If you think, the behavior of crushftp is correct, I (and Nagios) will accept it... :-)

Thanks again!

Best regards,

Dirk.
spinkb @ Mon Oct 13 01:21:36 EEST 2014
Sorry...my mistake. New build now again.

--Ben
Login to post a comment