The stats HTML output were barely readable on some browsers such as
firefox on Linux, due to the selected helvetica font which is too
small. Specifying "arial" first fixes the issue without changing the
table size. Also, the default size of 0.8em choosen to get 10px out
of 12px is wrong because it gets 9px when rounded down.
(cherry picked from commit a94f2d2ef944e3f54f50e938ff3c8de1a021f7ff)
This minor harmless bug dates back to v1.1. When fclose() was added,
the close() calls were not removed, so the fds 0,1,2 are closed twice.
(cherry picked from commit 1700b9c3d5f06ac283ab2e254bd64b1bc7a207ca)
[cherry-picked from commit d79e79b436144654d10124de7d5fd4c896ac0487]
epoll, sepoll and kqueue pollers should check that their fd is not
closed before attempting to close it, otherwise we can end up with
multiple closes of fd #0 upon exit, which is harmless but dirty.
The reload operation in the Red Hat init script caused a restart
which is not always the best thing to do. Implement the reload.
(cherry picked from commit 3909a2ab008e9fed1851bc68d5b6ff23c62c0a1e)
[cherry-picked from commit 79e998919660b2ec6d5dc11be9d820c5c1965460]
The response message in the transaction structure was not properly
initialised at session initialisation. In theory it cannot cause any
trouble since the affected field os expected to always remain NULL.
However, in some circumstances, such as building on 64-bit platforms
with certain options, the struct session can be exactly 1024 bytes,
the same size of the requri field, so the pools are merged and the
uninitialised field may contain non-null data, causing crashes if
an invalid response is encountered and archived.
The fix simply consists in correctly initialising the missing fields.
This bug cannot affect architectures where the session pool is not
shared (32-bit architectures), but this is only by pure luck.
A race condition exists in the hot reconfiguration code. It is
theorically possible that the second signal is sent during a free()
in the first list, which can cause crashes or freezes (the later
have been observed). Just set up a counter to ensure we do not
recurse.
(cherry picked from commit b7f9d126e269f3b5b7dc05e39fcf207ba86a330c)
Mainly two sizeof() returning size_t which is not the size of an int
on 64-bit platforms.
(cherry picked from commit 5e4a6f13f4b3c3de0e533284d5fabd9b4bbe00cc)
[cherry-picked from commit 1772ece0252fa517ace6c554ee77ca09c3dda7e8]
Last patch revealed a number of mistakes in printf-like calls, mostly int/long
mismatches, and a few missing arguments.
[cherry-picked from commit b00f9c456c0eadd26abbbf4bb0a3276da9f1844e]
If the accept() is done before checking for global.maxconn, we can
accept too many connections and encounter a lack of file descriptors
when trying to connect to the server. This is the cause of the
"cannot get a server socket" message encountered in debug mode
during injections with low timeouts.
[cherry-picked from commit e38388033f3df181ff6a2ee227789cd743d17dc1]
If server check interval is null, we might end up looping in
process_srv_chk().
Prevent those values from being zero and add some control in
process_srv_chk() against infinite loops.
The example for configuration of "Status report in HTML page"
in haproxy-en.txt/haproxy-fr.txt is incomplete. Gives me the
below error, and had me scratching my head a bit :-)
[ALERT] 074/131807 (26359) : parsing /etc/haproxy/haproxy.cfg : listener
stats has no dispatch address and is not in transparent or balance mode.
[ALERT] 074/131807 (26359) : Errors found in configuration file, aborting.
[ALERT] 074/131807 (26359) : Error reading configuration file :
/etc/haproxy/haproxy.cfg
If adding "balance roundrobin" to the stats stanza is the right fix,
please apply the attached documentation patch to haproxy v1.2 and v1.3.
[w@1wt.eu: this is the right fix up to 1.3.15, not needed in 1.3.16]
If both make parameters USE_PCRE and USE_STATIC_PCRE are set to 1
while building haproxy, pcre gets linked in dynamically.
Therefore we check if USE_STATIC_PCRE was explicitely enabled to
ommit the CFLAGS and LDFLAGS normally set if USE_PCRE is enabled.
(cherry picked from commit c820300adf36700cbbff15249a8629baa63c5f5a)
Here's an selinux policy for haproxy. The patch is built and lightly
tested with haproxy-1.3.15.7-1.fc10.i386 on Fedora9, and haproxy-1.2.18
on RHEL5.
(cherry picked from commit 6b6a53db5f135d8256dd1a8c9dab018963ed6918)
Released version 1.3.15.8 with the following main changes :
- [BUG] Fix listen & more of 2 couples <ip>:<port>
- [DOC] remove buggy comment for use_backend
- [CRITICAL] fix server state tracking: it was O(n!) instead of O(n)
- [BUG] "option transparent" is for backend, not frontend !
- [BUG] we must not exit if protocol binding only returns a warning
- [BUG] inform the user when root is expected but not set
- [DOC] large doc update backported from mainline
- [BUG] the "source" keyword must first clear optional settings
- [BUG] global.tune.maxaccept must be limited even in mono-process mode
- [BUG] typo in timeout error reporting : report *res and not *err
On overloaded systems, it sometimes happens that hundreds or thousands
of incoming connections are queued in the system's backlog, and all get
dequeued at once. The problem is that when haproxy processes them and
does not apply any limit, this can take some time and the internal date
does not progress, resulting in wrong timer measures for all sessions.
The most common effect of this is that all of these sessions report a
large request time (around several hundreds of ms) which is in fact
caused by the time spent accepting other connections. This might happen
on shared systems when the machine swaps.
For this reason, we finally apply a reasonable limit even in mono-process
mode. Accepting 100 connections at once is fast enough for extreme cases
and will not cause that much of a trouble when the system is saturated.
(cherry picked from commit f49d1df25cf794b8801d919fda20266d90981c78)
Problem reported by John Lauro. When "source ... usesrc ..." is
set in the defaults section, it is not possible anymore to remove
the "usesrc" part when declaring a more precise "source" in a
backend. The only workaround was to declare it by server.
We need to clear optional settings when declaring a new "source".
(cherry picked from commit 368480cf4570a0d6448741c704aebd53ac467aa9)
When a plain user runs haproxy as non-root but some options require
root, let's inform him.
(cherry picked from commit 4e30ed73f4b902b076f765c3e2370ef0a034a648)
Right now, protocol binding cannot return a warning, but when this
will happen, we must not exit but just print the warning.
(cherry picked from commit 0a3b9d90d3570cb618c7008cd1d7348d48a3868c)
"option transparent" was set and checked on frontends only while it
is purely a backend thing as it replaces the "balance" mode. For this
reason, it did only work in "listen" sections. This change will then
not affect the rare users of this option.
(cherry picked from commit 4b1f85912c5dfd7e53dfa31d3e9dd3113747c702)
Using the wrong operator (&& instead of &) causes DOWN->UP
transition to take longer than it should and to produce a lot of
redundant logs. With typical "track" usage (1-6 tracking servers) it
shouldn't make a big difference but for heavily tracked servers
this bug leads to hang with 100% CPU usage and extremely big
log spam.
Released version 1.3.15.7 with the following main changes :
- [BUILD] fix MANDIR default location to match documentation
- [BUG] critical errors should be reported even in daemon mode
- [BUG] do not dequeue requests on a dead server
- [BUG] do not dequeue the backend's pending connections on a dead server
Kai Krueger found that previous patch was incomplete, because there is
an unconditionnal call to process_srv_queue() in session_free() which
still causes a dead server to consume pending connections from the
backend.
This call was made unconditionnal so that we don't leave unserved
connections in the server queue, for instance connections coming
in with "option persist" which can bypass the server status check.
However, the server must not touch the backend's queue if it is down.
Another fear was that some connections might remain unserved when
the server is using a dynamic maxconn if the number of connections
to the backend is too low. Right now, srv_dynamic_maxconn() ensures
this cannot happen, so the call can remain conditionnal.
The fix consists in allowing a server to process it own queue whatever
its state, but not to touch the backend's queue if it is down. Its
queue should normally be empty when the server is down because it is
redistributed when the server goes down. The only remaining cases are
precisely the persistent connections with "option persist" set, coming
in after the queue has been redispatched. Those ones must still be
processed when a connection terminates.
Kai Krueger reported a problem when a server goes down with active
connections. A lot of connections were drained by that server. Kai
did an amazing job at tracking this bug down to the dequeuing
mechanism which forgets to check the server state before allowing
a request to be sent to a server.
The problem occurs more often with long requests, which have a chance
to complete after the server is completely marked down, and to find
requests in the global queue which have not yet been fetched by other
servers.
The fix consists in ensuring that a server is up before sending it
any new request from the queue.
Josh Goebel reported that haproxy silently dies when it fails to
chroot. In fact, it does so when in daemon mode, because daemon
mode has been disabling output for ages.
Since the code has been reworked, this could have been changed
because there is no reason for this anymore, hence this patch.
Released version 1.3.15.6 with the following main changes :
- [MINOR] cfgparse: fix off-by 2 in error message size
- [BUG] cookie capture is declared in the frontend but checked on the backend
Cookie capture would only work by pure luck on the request but did
never work on responses since only the backend was checked. The fix
consists in always checking frontend for cookie captures.
(cherry picked from commit a83c5ba9315a7c47cda2698280b7e49a9d3eb374)
Released version 1.3.15.5 with the following main changes :
- [BUG] do not try to pause backends during reload
- [BUG] ensure that listeners from disabled proxies are correctly unbound.
- [BUG] acl-related keywords are not allowed in defaults sections
Using an ACL-related keyword in the defaults section causes a
segfault during parsing because the list headers are not initialized.
We must initialize list headers for default instance and reject
keywords relying on ACLs.
There is a problem when an instance is marked "disabled". Its ports are
still bound but will not be unbound upon termination. This causes processes
to accumulate during soft restarts, and might even cause failures to restart
new ones due to the inability to bind to the same port.
The ideal solution would be to bind all ports at the end of the configuration
parsing. An acceptable workaround is to unbind all listeners of disabled
proxies. This is what the current patch does.
During a configuration reload, haproxy tried to pause all proxies.
Unfortunately, it also tried to pause backends, which would fail
and cause trouble to the new process since the port was still bound.
Released version 1.3.15.4 with the following main changes :
- [BUG] do not release the connection slot during a retry
- [BUG] dynamic connection throttling could return a max of zero conns
srv_dynamic_maxconn() is clearly documented as returning at least 1
possible connection under throttling. But the computation was wrong,
the minimum 1 was divided and got lost in case of very low maxconns.
Apply the MAX(1, max) before returning the result in order to ensure
that a newly appeared server will get some traffic.
A bug was introduced during last queue management fix. If a server
connection fails, the allocated connection slot is released, but it
will be needed again after the turn-around. This also causes more
connections than expected to go to the server because it appears to
have less connections than real.
Many thanks to Rupert Fiasco, Mark Imbriaco, Cody Fauser, Brian
Gupta and Alexander Staubo for promptly providing configuration
and diagnosis elements to help reproduce this problem easily.
Released version 1.3.15.3 with the following main changes :
- [BUG] disable buffer read timeout when reading stats
- [BUILD] change declaration of base64tab to fix build with Intel C++
- [BUILD] silent a warning in unlikely() with gcc 4.x
- [BUG] use_backend would not correctly consider "unless"
- [CLEANUP] remove dependency on obsolete INTBITS macro
- [BUG] fix segfault with url_param + check_post
- [BUG] server timeout was not considered in some circumstances
- [BUG] ev_sepoll: closed file descriptors could persist in the spec list
- [BUG] maintain_proxies must not disable backends
- [BUG] regparm is broken on gcc < 3
- [OPTIM] force inlining of large functions with gcc >= 3
GCC 3 and above do not inline large functions, which is a problem
with ebtree where most core functions are inlined.
This simple patch has both reduced code size and increased speed.
It should be back-ported to ebtree.
(cherry picked from commit 707d3da01f8475d5c172d347a73bd9e947076df6)
Gcc < 3 does not consider regparm declarations for function pointers.
This causes big trouble at least with pollers (and with any function
pointer after all). Disable CONFIG_HAP_USE_REGPARM for gcc < 3.
(cherry picked from commit 61eadc028fb8774ea05d893cd3eca6c671fb511e)
maintain_proxies could disable backends (p->maxconn == 0) which is
wrong (but apparently harmless). Add a check for p->maxconn == 0.
(cherry picked from commit d5382b4aaa099ce5ce2af5828bd4d6dc38e9e8ea)
If __fd_clo() was called on a file descriptor which was previously
disabled, it was not removed from the spec list. This apparently
could not happen on previous code because the TCP states prevented
this, but now it happens regularly. The effects are spec entries
stuck populated, leading to busy loops.
(cherry picked from commit 7a52a5c4680477272b2f34eaf5896b85746e6fd6)
Due to a copy-paste typo, the client timeout was refreshed instead
of the server's when waiting for server response. This means that
the server's timeout remained eternity.
(cherry picked from commit 9f1f24bb7fb8ebd6b43b5fee1bda0afbdbcb768e)
If an HTTP/0.9-like POST request is sent to haproxy while
configured with url_param + check_post, it will crash. The
reason is that the total buffer length was computed based
on req->total (which equals the number of bytes read) and
not req->l (number of bytes in the buffer), thus leading
to wrong size calculations when calling memchr().
The affected code does not look like it could have been
exploited to run arbitrary code, only reads were performed
at wrong locations.
(cherry picked from commit fb0528bd56063e9800c7dd6fbd96b3c5c6a687f2)
The INTBITS macro was found to be already defined on some platforms,
and to equal 32 (while INTBITS was 5 here). Due to pure luck, there
was no declaration conflict, but it's nonetheless a problem to fix.
Looking at the code showed that this macro was only used for left
shifts and nothing else anymore. So the replacement is obvious. The
new macro, BITS_PER_INT is more obviously correct.
(cherry picked from commit 177e2b012723ef65c6c7f850df3e6e0cd2cca2b4)
