HAProxy community

Turn off all timeouts


#1

Is there a way to turn off all timeouts, or set them to be infinite? I have a setup where the traffic is low, but connections can be very long lived. While working on reducing those long lived connections, I’d rather haproxy not timeout anything.

Thanks!


#2

Hi,

Simply don’t set them and they’ll be turned to 0.
That said, I strongly not doing this. You could be DDOSed quickly and easily.
You may want at least to setup client and server side tcp-ut, to let HAProxy and your kernel know when there is definitively nobody at the other side of the connection.


#3

Sorry to wake up an old thread, but I felt it was better to write it here than opening a similar thread.

I’ve set it to 0 now (or just leave it out all together) and it works just as I expect. This is an internal service that expects long connections and I want it to act the same way as it would if I communicated directly with a backend.

Anyway, when having the value 0, you get warnings when starting HAProxy:

Jan 30 11:20:23 my-server haproxy[10860]: [WARNING] 029/112023 (10860) : config : missing timeouts for frontend 'my-backend'.
Jan 30 11:20:23 my-server haproxy[10860]:    | While not properly invalid, you will certainly encounter various problems
Jan 30 11:20:23 my-server haproxy[10860]:    | with such a configuration. To fix this, please ensure that all following
Jan 30 11:20:23 my-server haproxy[10860]:    | timeouts are set to a non-zero value: 'client', 'connect', 'server'.
Jan 30 11:20:23 my-server haproxy[10860]: [WARNING] 029/112023 (10860) : config : missing timeouts for backend 'my-backend'.
Jan 30 11:20:23 my-server haproxy[10860]:    | While not properly invalid, you will certainly encounter various problems
Jan 30 11:20:23 my-server haproxy[10860]:    | with such a configuration. To fix this, please ensure that all following
Jan 30 11:20:23 my-server haproxy[10860]:    | timeouts are set to a non-zero value: 'client', 'connect', 'server'.

Is there a way to supress this warning?


#4

There is no way to suppress this warnings, because it’s a terrible, terrible idea.


#5

In what way is it a terrible idea? Genuinely curious, what could happen that I probably wouldn’t want?


#6

What will happen is that obsolete session will hang in there forever and will never be closed. If those sessions are generic sessions, it will probably be a few weeks or months before you reach the limits. If it is an attack, the instance will likely only last for a few minutes.

When you hit those limits, and maxconn is configured correctly: haproxy won’t accept any new sessions and your service will stop working. If maxconn is miss configured (too high for the available RAM), the out-of-memory killer of your OS will kill haproxy, so the service won’t work anymore.

In every case, you will have a unreliable service that suddenly stops working.