Start a new topic

Monitoring CrushFTP wit Nagios: possible keep-alive problem?

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

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


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

Connection: close

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

[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
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 :-(

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.

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,

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,

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


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,

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

Login to post a comment