upstream/haproxy
1
0
Fork 0
mirror of https://github.com/haproxy/haproxy.git synced 2026-04-15 21:59:41 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions 3
haproxy/src/server.c

7675 lines
231 KiB
C
Raw Normal View History

[MEDIUM] added the new 'stats' keyword with user authentication subsystem. Right now it only validates the user/passwd according to a specified list, and lets the user pass through the proxy if the authentication is OK, and it refuses any invalid access with a 401 Unauthorized response.
2006-05-14 17:06:28 -04:00
/*
[BIGMOVE] exploded the monolithic haproxy.c file into multiple files. The files are now stored under : - include/haproxy for the generic includes - include/types.h for the structures needed within prototypes - include/proto.h for function prototypes and inline functions - src/*.c for the C files Most include files are now covered by LGPL. A last move still needs to be done to put inline functions under GPL and not LGPL. Version has been set to 1.3.0 in the code but some control still needs to be done before releasing.
2006-06-25 20:48:02 -04:00
* Server management functions.
*
MINOR: server: add minimal infrastructure to parse keywords Just like with the "bind" lines, we'll switch the "server" line parsing to keyword registration. The code is essentially the same as for bind keywords, with minor changes such as support for the default-server keywords and support for variable argument count.
2012-10-10 02:27:36 -04:00
* Copyright 2000-2012 Willy Tarreau <w@1wt.eu>
[MEDIUM]: rework checks handling This patch adds two new variables: fastinter and downinter. When server state is: - non-transitionally UP -> inter (no change) - transitionally UP (going down), unchecked or transitionally DOWN (going up) -> fastinter - down -> downinter It allows to set something like: server sr6 127.0.51.61:80 cookie s6 check inter 10000 downinter 20000 fastinter 500 fall 3 weight 40 In the above example haproxy uses 10000ms between checks but as soon as one check fails fastinter (500ms) is used. If server is down downinter (20000) is used or fastinter (500ms) if one check pass. Fastinter is also used when haproxy starts. New "timeout.check" variable was added, if set haproxy uses it as an additional read timeout, but only after a connection has been already established. I was thinking about using "timeout.server" here but most people set this with an addition reserve but still want checks to kick out laggy servers. Please also note that in most cases check request is much simpler and faster to handle than normal requests so this timeout should be smaller. I also changed the timeout used for check connections establishing. Changes from the previous version: - use tv_isset() to check if the timeout is set, - use min("timeout connect", "inter") but only if "timeout check" is set as this min alone may be to short for full (connect + read) check, - debug code (fprintf) commented/removed - documentation Compile tested only (sorry!) as I'm currently traveling but changes are rather small and trivial.
2008-01-20 19:54:06 -05:00
* Copyright 2007-2008 Krzysztof Piotr Oledzki <ole@ans.pl>
[MEDIUM] added the new 'stats' keyword with user authentication subsystem. Right now it only validates the user/passwd according to a specified list, and lets the user pass through the proxy if the authentication is OK, and it refuses any invalid access with a 401 Unauthorized response.
2006-05-14 17:06:28 -04:00
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*
*/
BUILD: include: add sys/types before netinet/tcp.h Apparently Cygwin requires sys/types.h before netinet/tcp.h but doesn't include it by itself, as shown here: https://github.com/haproxy/haproxy/actions/runs/131943890 This patch makes sure it's always present, which is in server.c and the SPOA example.
2020-06-11 05:22:44 -04:00
#include <sys/types.h>
CLEANUP: include: tree-wide alphabetical sort of include files This patch fixes all the leftovers from the include cleanup campaign. There were not that many (~400 entries in ~150 files) but it was definitely worth doing it as it revealed a few duplicates.
2020-06-09 03:07:15 -04:00
#include <netinet/tcp.h>
REORG: cfgparse: move server keyword parsing to server.c The cfgparse.c file becomes huge, and a large part of it comes from the server keyword parser. Since the configuration is a bit more modular now, move this parser to server.c. This patch also moves the check of the "server" keyword earlier in the supported keywords list, resulting in a slightly faster config parsing for configs with large numbers of servers (about 10%). No functional change was made, only the code was moved.
2014-03-31 04:39:59 -04:00
#include <ctype.h>
MINOR: config: new backend directives: load-server-state-from-file and server-state-file-name This directive gives HAProxy the ability to use the either the global server-state-file directive or a local one using server-state-file-name to load server states. The state can be saved right before the reload by the init script, using the "show servers state" command on the stats socket redirecting output into a file.
2015-08-19 10:44:03 -04:00
#include <errno.h>
REORG: cfgparse: move server keyword parsing to server.c The cfgparse.c file becomes huge, and a large part of it comes from the server keyword parser. Since the configuration is a bit more modular now, move this parser to server.c. This patch also moves the check of the "server" keyword earlier in the supported keywords list, resulting in a slightly faster config parsing for configs with large numbers of servers (about 10%). No functional change was made, only the code was moved.
2014-03-31 04:39:59 -04:00
MEDIUM: connection: move idle connection trees to ceb64 Idle connection trees currently require a 56-byte conn_hash_node per connection, which can be reduced to 32 bytes by moving to ceb64. While ceb64 is theoretically slower, in practice here we're essentially dealing with trees that almost always contain a single key and many duplicates. In this case, ceb64 insert and lookup functions become faster than eb64 ones because all duplicates are a list accessed in O(1) while it's a subtree for eb64. In tests it is impossible to tell the difference between the two, so it's worth reducing the memory usage. This commit brings the following memory savings to conn_hash_node (one per backend connection), and to srv_per_thread (one per thread and per server): struct before after delta conn_hash_nodea 56 32 -24 srv_per_thread 96 72 -24 The delicate part is conn_delete_from_tree(), because we need to know the tree root the connection is attached to. But thanks to recent cleanups, it's now clear enough (i.e. idle/safe/avail vs session are easy to distinguish).
2025-09-12 09:28:33 -04:00
#include <import/ceb64_tree.h>
MEDIUM: server: switch addr_node to cebis_tree This contains the text representation of the server's address, for use with stick-tables with "srvkey addr". Switching them to a compact node saves 24 more bytes from this structure. The key was moved to an external pointer "addr_key" right after the node. The server struct is now 3968 bytes (down from 4032) due to alignment, and the proxy struct shrinks by 8 bytes to 3152.
2025-07-07 09:13:15 -04:00
#include <import/cebis_tree.h>
CLEANUP: server: use eb64_entry() not ebmb_entry() to convert an eb64 There were a few leftovers from an earlier version of the conn_hash_node that was using ebmb nodes. A few calls to ebmb_first() and ebmb_entry() were still present while acting on an eb64 tree. These are harmless as one is just eb_first() and the other container_of(), but it's confusing so let's clean them up.
2025-09-12 09:49:48 -04:00
#include <import/eb64tree.h>
REORG: server: uninline the idle conns management functions The following functions are quite heavy and have no reason to be kept inlined: srv_release_conn, srv_lookup_conn, srv_lookup_conn_next, srv_add_to_idle_list They were moved to server.c. It's worth noting that they're a bit at the edge between server and connection and that maybe we could create an idle-conn file for these in the near future.
2021-10-06 12:30:04 -04:00
CLEANUP: include: tree-wide alphabetical sort of include files This patch fixes all the leftovers from the include cleanup campaign. There were not that many (~400 entries in ~150 files) but it was definitely worth doing it as it revealed a few duplicates.
2020-06-09 03:07:15 -04:00
#include <haproxy/api.h>
REORG: move applet.h to haproxy/applet{,-t}.h The type file was slightly tidied. The cli-specific APPCTX_CLI_ST1_* flag definitions were moved to cli.h. The type file was adjusted to include buf-t.h and not the huge buf.h. A few call places were fixed because they did not need this include.
2020-06-04 13:42:41 -04:00
#include <haproxy/applet-t.h>
REORG: include: move backend.h to haproxy/backend{,-t}.h The files remained mostly unchanged since they were OK. However, half of the users didn't need to include them, and about as many actually needed to have it and used to find functions like srv_currently_usable() through a long chain that broke when moving the file.
2020-06-04 16:50:02 -04:00
#include <haproxy/backend.h>
REORG: include: move cfgparse.h to haproxy/cfgparse.h There's no point splitting the file in two since only cfgparse uses the types defined there. A few call places were updated and cleaned up. All of them were in C files which register keywords. There is nothing left in common/ now so this directory must not be used anymore.
2020-06-04 18:00:29 -04:00
#include <haproxy/cfgparse.h>
REORG: include: move checks.h to haproxy/check{,-t}.h All includes that were not absolutely necessary were removed because checks.h happens to very often be part of dependency loops. A warning was added about this in check-t.h. The fields, enums and structs were a bit tidied because it's particularly tedious to find anything there. It would make sense to split this in two or more files (at least extract tcp-checks). The file was renamed to the singular because it was one of the rare exceptions to have an "s" appended to its name compared to the struct name.
2020-06-04 12:21:56 -04:00
#include <haproxy/check.h>
REORG: include: move cli.h to haproxy/cli{,-t}.h Almost no change except moving the cli_kw struct definition after the defines. Almost all users had both types&proto included, which is not surprizing since this code is old and it used to be the norm a decade ago. These places were cleaned.
2020-06-04 14:19:54 -04:00
#include <haproxy/cli.h>
REORG: include: move connection.h to haproxy/connection{,-t}.h The type file is becoming a mess, half of it is for the proxy protocol, another good part describes conn_streams and mux ops, it would deserve being split again. At least it was reordered so that elements are easier to find, with the PP-stuff left at the end. The MAX_SEND_FD macro was moved to compat.h as it's said to be the value for Linux.
2020-06-04 12:02:10 -04:00
#include <haproxy/connection.h>
MEDIUM: counters: manage shared counters using dedicated helpers proxies, listeners and server shared counters are now managed via helpers added in one of the previous commits. When guid is not set (ie: when not yet assigned), shared counters pointer is allocated using calloc() (local memory) and a flag is set on the shared counters struct to know how to manipulate (and free it). Else if guid is set, then it means that the counters may be shared so while for now we don't actually use a shared memory location the API is ready for that. The way it works, for proxies and servers (for which guid is not known during creation), we first call counters_{fe,be}_shared_get with guid not set, which results in local pointer being retrieved (as if we just manually called calloc() to retrieve a pointer). Later (during postparsing) if guid is set we try to upgrade the pointer from local to shared. Lastly, since the memory location for some objects (proxies and servers counters) may change from creation to postparsing, let's update counters->last_change member directly under counters_{fe,be}_shared_get() so we don't miss it. No change of behavior is expected, this is only preparation work.
2025-05-07 17:42:04 -04:00
#include <haproxy/counters.h>
REORG: include: move dict.h to hparoxy/dict{,-t}.h This was entirely free-standing. haproxy/api-t.h was added for size_t.
2020-06-03 12:23:19 -04:00
#include <haproxy/dict-t.h>
REORG: include: move base64.h, errors.h and hash.h from common to to haproxy/ These ones do not depend on any other file. One used to include haproxy/api.h but that was solely for stddef.h.
2020-05-27 10:10:29 -04:00
#include <haproxy/errors.h>
REORG: include: split global.h into haproxy/global{,-t}.h global.h was one of the messiest files, it has accumulated tons of implicit dependencies and declares many globals that make almost all other file include it. It managed to silence a dependency loop between server.h and proxy.h by being well placed to pre-define the required structs, forcing struct proxy and struct server to be forward-declared in a significant number of files. It was split in to, one which is the global struct definition and the few macros and flags, and the rest containing the functions prototypes. The UNIX_MAX_PATH definition was moved to compat.h.
2020-06-04 11:05:57 -04:00
#include <haproxy/global.h>
MINOR: server: implement GUID support This commit is similar to previous one, except that it implements GUID support for server instances. A guid_node field is inserted into server structure. A new "guid" server keyword is defined.
2024-03-26 10:01:35 -04:00
#include <haproxy/guid.h>
REORG: include: move the error reporting functions to from log.h to errors.h Most of the files dealing with error reports have to include log.h in order to access ha_alert(), ha_warning() etc. But while these functions don't depend on anything, log.h depends on a lot of stuff because it deals with log-formats and samples. As a result it's impossible not to embark long dependencies when using ha_warning() or qfprintf(). This patch moves these low-level functions to errors.h, which already defines the error codes used at the same places. About half of the users of log.h could be adjusted, sometimes revealing other issues such as missing tools.h. Interestingly the total preprocessed size shrunk by 4%.
2020-06-05 11:27:29 -04:00
#include <haproxy/log.h>
REORG: check: move the e-mail alerting code to mailers.c check.c is one of the largest file and contains too many things. The e-mail alerting code is stored there while nothing is in mailers.c. Let's move this code out. That's only 4% of the code but a good start. In order to do so, a few tcp-check functions had to be exported.
2020-06-05 05:40:38 -04:00
#include <haproxy/mailers.h>
REORG: include: move common/namespace.h to haproxy/namespace{,-t}.h The type was moved out as it's used by standard.h for netns_entry. Instead of just being a forward declaration when not used, it's an empty struct, which makes gdb happier (the resulting stripped executable is the same).
2020-06-02 11:02:59 -04:00
#include <haproxy/namespace.h>
CLEANUP: include: tree-wide alphabetical sort of include files This patch fixes all the leftovers from the include cleanup campaign. There were not that many (~400 entries in ~150 files) but it was definitely worth doing it as it revealed a few duplicates.
2020-06-09 03:07:15 -04:00
#include <haproxy/port_range.h>
#include <haproxy/protocol.h>
BUILD: server: include missing proxy.h in server.c It's needed for a number of functions and definitions but was missing.
2021-05-08 14:18:59 -04:00
#include <haproxy/proxy.h>
REORG: include: move queue.h to haproxy/queue{,-t}.h Nothing outstanding here. A number of call places were not justified and removed.
2020-06-04 16:59:39 -04:00
#include <haproxy/queue.h>
MINOR: quic-be: QUIC backend XPRT and transport parameters init during parsing Add ->quic_params new member to server struct. Also set the ->xprt member of the server being initialized and initialize asap its transport parameters from _srv_parse_init().
2023-12-18 05:18:45 -05:00
#include <haproxy/quic_tp.h>
MINOR: quic: implement cc-algo server keyword Extend QUIC server configuration so that congestion algorithm and maximum window size can be set on the server line. This can be achieved using quic-cc-algo keyword with a syntax similar to a bind line. This should be backported up to 3.3 as this feature is considered as necessary for full QUIC backend support. Note that this relies on the serie of previous commits which should be picked first.
2025-11-27 10:25:42 -05:00
#include <haproxy/quic_tune.h>
MEDIUM: resolvers/dns: split dns.c into dns.c and resolvers.c This patch splits current dns.c into two files: The first dns.c contains code related to DNS message exchange over UDP and in future other TCP. We try to remove depencies to resolving to make it usable by other stuff as DNS load balancing. The new resolvers.c inherit of the code specific to the actual resolvers. Note: It was really difficult to obtain a clean diff dur to the amount of moved code. Note2: Counters and stuff related to stats is not cleany separated because currently counters for both layers are merged and hard to separate for now.
2021-02-12 13:42:55 -05:00
#include <haproxy/resolvers.h>
REORG: include: move sample.h to haproxy/sample{,-t}.h This one is particularly tricky to move because everyone uses it and it depends on a lot of other types. For example it cannot include arg-t.h and must absolutely only rely on forward declarations to avoid dependency loops between vars -> sample_data -> arg. In order to address this one, it would be nice to split the sample_data part out of sample.h.
2020-06-04 09:33:47 -04:00
#include <haproxy/sample.h>
REORG: rename cs_utils.h to sc_strm.h This file contains all the stream-connector functions that are specific to application layers of type stream. So let's name it accordingly so that it's easier to figure what's located there. The alphabetical ordering of include files was preserved.
2022-05-27 03:25:10 -04:00
#include <haproxy/sc_strm.h>
REORG: include: move server.h to haproxy/server{,-t}.h extern struct dict server_name_dict was moved from the type file to the main file. A handful of inlined functions were moved at the bottom of the file. Call places were updated to use server-t.h when relevant, or to simply drop the entry when not needed.
2020-06-04 17:20:13 -04:00
#include <haproxy/server.h>
MEDIUM: server: implement 'add server' cli command Add a new cli command 'add server'. This command is used to create a new server at runtime attached on an existing backend. The syntax is the following one : $ add server <be_name>/<sv_name> [<kws>...] This command is only available through experimental mode for the moment. Currently, no server keywords are supported. They will be activated individually when deemed properly functional and safe. Another limitation is put on the backend load-balancing algorithm. The algorithm must use consistent hashing to guarantee a minimal reallocation of existing connections on the new server insertion.
2021-03-08 11:13:32 -05:00
#include <haproxy/stats.h>
MINOR: quic-be: Set the backend alpn if not set by conf Simply set the alpn string to "h3,hq_interop" if there is no "alpn" setting for QUIC backends.
2025-07-03 14:53:00 -04:00
#include <haproxy/ssl_sock.h>
REORG: stconn: rename conn_stream.{c,h} to stconn.{c,h} There's no more reason for keepin the code and definitions in conn_stream, let's move all that to stconn. The alphabetical ordering of include files was adjusted.
2022-05-27 03:47:12 -04:00
#include <haproxy/stconn.h>
REORG: include: move stream.h to haproxy/stream{,-t}.h This one was not easy because it was embarking many includes with it, which other files would automatically find. At least global.h, arg.h and tools.h were identified. 93 total locations were identified, 8 additional includes had to be added. In the rare files where it was possible to finalize the sorting of includes by adjusting only one or two extra lines, it was done. But all files would need to be rechecked and cleaned up now. It was the last set of files in types/ and proto/ and these directories must not be reused anymore.
2020-06-04 17:46:14 -04:00
#include <haproxy/stream.h>
MINOR: server: use stress mode for "add server help" Implement stress mode on "add server help". This ensures that the command is fully reentrant on full output buffer. For testing, it requires compilation with USE_STRESS and global setting "stress-level 1".
2025-05-22 11:13:20 -04:00
#include <haproxy/stress.h>
REORG: include: move task.h to haproxy/task{,-t}.h The TASK_IS_TASKLET() macro was moved to the proto file instead of the type one. The proto part was a bit reordered to remove a number of ugly forward declaration of static inline functions. About a tens of C and H files had their dependency dropped since they were not using anything from task.h.
2020-06-04 11:25:40 -04:00
#include <haproxy/task.h>
REORG: check: move tcpchecks away from check.c Checks.c remains one of the largest file of the project and it contains too many things. The tcpchecks code represents half of this file, and both parts are relatively isolated, so let's move it away into its own file. We now have tcpcheck.c, tcpcheck{,-t}.h. Doing so required to export quite a number of functions because check.c has almost everything made static, which really doesn't help to split!
2020-06-05 06:25:38 -04:00
#include <haproxy/tcpcheck.h>
REORG: include: move time.h from common/ to haproxy/ This one is included almost everywhere and used to rely on a few other .h that are not needed (unistd, stdlib, standard.h). It could possibly make sense to split it into multiple parts to distinguish operations performed on timers and the internal time accounting, but at this point it does not appear much important.
2020-06-01 05:05:15 -04:00
#include <haproxy/time.h>
BUILD: server: include tools.h from server.c A lot of functions from tools.h are used there but the file was only inherited via other ones.
2021-05-08 08:09:40 -04:00
#include <haproxy/tools.h>
CLEANUP: Add haproxy/xxhash.h to avoid modifying import/xxhash.h This solves setting XXH_INLINE_ALL in a cleaner way, because the imported header is not modified, easing future updates. see 6f7cc11e6dd0f01b437fba893da2edd2362660a2
2021-09-11 11:51:13 -04:00
#include <haproxy/xxhash.h>
MINOR: server/event_hdl: add support for SERVER_ADD and SERVER_DEL events Basic support for ADD and DEL server events are added through this commit: SERVER_ADD is published on dynamic server addition through cli. SERVER_DEL is published on dynamic server deletion through cli. This work depends on: "MINOR: event_hdl: add event handler base api" "MINOR: server: add srv->rid (revision id) value"
2022-11-17 04:37:58 -05:00
#include <haproxy/event_hdl.h>
[MEDIUM] stats: report server and backend cumulated downtime Hello, This patch implements new statistics for SLA calculation by adding new field 'Dwntime' with total down time since restart (both HTTP/CSV) and extending status field (HTTP) or inserting a new one (CSV) with time showing how long each server/backend is in a current state. Additionaly, down transations are also calculated and displayed for backends, so it is possible to know how many times selected backend was down, generating "No server is available to handle this request." error. New information are presentetd in two different ways: - for HTTP: a "human redable form", one of "100000d 23h", "23h 59m" or "59m 59s" - for CSV: seconds I believe that seconds resolution is enough. As there are more columns in the status page I decided to shrink some names to make more space: - Weight -> Wght - Check -> Chk - Down -> Dwn Making described changes I also made some improvements and fixed some small bugs: - don't increment s->health above 's->rise + s->fall - 1'. Previously it was incremented an then (re)set to 's->rise + s->fall - 1'. - do not set server down if it is down already - do not set server up if it is up already - fix colspan in multiple places (mostly introduced by my previous patch) - add missing "status" header to CSV - fix order of retries/redispatches in server (CSV) - s/Tthen/Then/ - s/server/backend/ in DATA_ST_PX_BE (dumpstats.c) Changes from previous version: - deal with negative time intervales - don't relay on s->state (SRV_RUNNING) - little reworked human_time + compacted format (no spaces). If needed it can be used in the future for other purposes by optionally making "cnt" as an argument - leave set_server_down mostly unchanged - only little reworked "process_chk: 9" - additional fields in CSV are appended to the rigth - fix "SEC" macro - named arguments (human_time, be_downtime, srv_downtime) Hope it is OK. If there are only cosmetic changes needed please fill free to correct it, however if there are some bigger changes required I would like to discuss it first or at last to know what exactly was changed especially since I already put this patch into my production server. :) Thank you, Best regards, Krzysztof Oledzki
2007-10-22 10:21:10 -04:00
MINOR: server: pass adm and op cause to srv_update_status() Operational and administrative state change causes are not propagated through srv_update_status(), instead they are directly consumed within the function to provide additional info during the call when required. Thus, there is no valid reason for keeping adm and op causes within server struct. We are wasting space and keeping uneeded complexity. We now exlicitly pass change type (operational or administrative) and associated cause to srv_update_status() so that no extra storage is needed since those values are only relevant from srv_update_status().
2023-04-18 05:00:17 -04:00
static void srv_update_status(struct server *s, int type, int cause);
MAJOR: server: postpone address resolution Server addresses are not resolved anymore upon the first pass so that we don't fail if an address cannot be resolved by the libc. Instead they are processed all at once after the configuration is fully loaded, by the new function srv_init_addr(). This function only acts on the server's address if this address uses an FQDN, which appears in server->hostname. For now the function does two things, to followup with HAProxy's historical default behavior: 1. apply server IP address found in server-state file if runtime DNS resolution is enabled for this server 2. use the DNS resolver provided by the libc If none of the 2 options above can find an IP address, then an error is returned. All of this will be needed to support the new server parameter "init-addr". For now, the biggest user-visible change is that all server resolution errors are dumped at once instead of causing a startup failure one by one.
2016-11-02 10:34:05 -04:00
static int srv_apply_lastaddr(struct server *srv, int *err_code);
BUG/MEDIUM: connections: force connections cleanup on server changes I've been trying to understand a change of behaviour between v2.2dev5 and v2.2dev6. Indeed our probe is regularly testing to add and remove servers on a given backend such as: # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 263 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 0.0.0.0 0 1 256 256 0 15 3 0 14 0 0 0 - 0 - -> curl on the corresponding frontend: reply from server:31255 # echo "set server be_foo/srv1 addr 10.236.139.34 port 31257" | sudo socat stdio /var/lib/haproxy/stats IP changed from '0.0.0.0' to '10.236.139.34', port changed from '0' to '31257' by 'stats socket command' # echo "set server be_foo/srv1 weight 256" | sudo socat stdio /var/lib/haproxy/stats # echo "set server be_foo/srv1 check-port 8500" | sudo socat stdio /var/lib/haproxy/stats health check port updated. # echo "set server be_foo/srv1 state ready" | sudo socat stdio /var/lib/haproxy/stats # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 105 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 10.236.139.34 2 0 256 256 2319 15 3 2 6 0 0 0 - 31257 - -> curl on the corresponding frontend: reply for server:31257 (notice the difference of weight) # echo "set server be_foo/srv1 state maint" | sudo socat stdio /var/lib/haproxy/stats # echo "set server be_foo/srv1 addr 0.0.0.0 port 0" | sudo socat stdio /var/lib/haproxy/stats IP changed from '10.236.139.34' to '0.0.0.0', port changed from '31257' to '0' by 'stats socket command' # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 263 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 0.0.0.0 0 1 256 256 0 15 3 0 14 0 0 0 - 0 - -> curl on the corresponding frontend: reply from server:31255 # echo "set server be_foo/srv1 addr 10.236.139.34 port 31256" | sudo socat stdio /var/lib/haproxy/stats IP changed from '0.0.0.0' to '10.236.139.34', port changed from '0' to '31256' by 'stats socket command' # echo "set server be_foo/srv1 weight 256" | sudo socat stdio /var/lib/haproxy/stats # echo "set server be_foo/srv1 check-port 8500" | sudo socat stdio /var/lib/haproxy/stats health check port updated. # echo "set server be_foo/srv1 state ready" | sudo socat stdio /var/lib/haproxy/stats # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 105 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 10.236.139.34 2 0 256 256 2319 15 3 2 6 0 0 0 - 31256 - -> curl on the corresponding frontend: reply from server:31257 (!) Here we indeed would expect to get an anver from server:31256. The issue is highly linked to the usage of `pool-purge-delay`, with a value which is higher than the duration of the test, 10s in our case. a git bisect between dev5 and dev6 seems to show commit 079cb9af22da6 ("MEDIUM: connections: Revamp the way idle connections are killed") being the origin of this new behaviour. So if I understand the later correctly, it seems that it was more a matter of chance that we did not saw the issue earlier. My patch proposes to force clean idle connections in the two following cases: - we set a (still running) server to maintenance - we change the ip/port of a server This commit should be backported to 2.1, 2.0, and 1.9. Signed-off-by: William Dauchy <w.dauchy@criteo.com>
2020-05-02 15:52:36 -04:00
static void srv_cleanup_connections(struct server *srv);
[MEDIUM] added the new 'stats' keyword with user authentication subsystem. Right now it only validates the user/passwd according to a specified list, and lets the user pass through the proxy if the authentication is OK, and it refuses any invalid access with a 401 Unauthorized response.
2006-05-14 17:06:28 -04:00
REORG: server: move keywords in srv_kws Move server-keyword hardcoded in parse_server into the srv_kws list of server.c. Now every server keywords is checked through srv_find_kw. This has the effect to reduce the size of parse_server. As a side-effect, common kw list can be reduced. This change has been made to be able to quickly discard these keywords in case of a dynamic server.
2021-03-10 10:36:02 -05:00
/* extra keywords used as value for other arguments. They are used as
* suggestions for mistyped words.
MINOR: cfgparse/server: try to fix spelling mistakes on server lines Let's apply the fuzzy match to server keywords so that we can avoid dumping the huge list of supported keywords each time there is a spelling mistake, and suggest proper spelling instead: $ printf "listen f\nserver s 0 sendpx-v2\n" | ./haproxy -c -f /dev/stdin [NOTICE] 070/095718 (24152) : haproxy version is 2.4-dev11-caa6e3-25 [NOTICE] 070/095718 (24152) : path to executable is ./haproxy [ALERT] 070/095718 (24152) : parsing [/dev/stdin:2] : 'server s' unknown keyword 'sendpx-v2'; did you mean 'send-proxy-v2' maybe ? [ALERT] 070/095718 (24152) : Error(s) found in configuration file : /dev/stdin [ALERT] 070/095718 (24152) : Fatal errors found in configuration.
2021-03-12 03:58:04 -05:00
*/
REORG: server: move keywords in srv_kws Move server-keyword hardcoded in parse_server into the srv_kws list of server.c. Now every server keywords is checked through srv_find_kw. This has the effect to reduce the size of parse_server. As a side-effect, common kw list can be reduced. This change has been made to be able to quickly discard these keywords in case of a dynamic server.
2021-03-10 10:36:02 -05:00
static const char *extra_kw_list[] = {
"ipv4", "ipv6", "legacy", "octet-count",
MINOR: server: remove fastinter from mistyped kw list This keyword is already present in server kw list from checks.c.
2021-03-12 10:04:00 -05:00
"fail-check", "sudden-death", "mark-down",
MINOR: cfgparse/server: try to fix spelling mistakes on server lines Let's apply the fuzzy match to server keywords so that we can avoid dumping the huge list of supported keywords each time there is a spelling mistake, and suggest proper spelling instead: $ printf "listen f\nserver s 0 sendpx-v2\n" | ./haproxy -c -f /dev/stdin [NOTICE] 070/095718 (24152) : haproxy version is 2.4-dev11-caa6e3-25 [NOTICE] 070/095718 (24152) : path to executable is ./haproxy [ALERT] 070/095718 (24152) : parsing [/dev/stdin:2] : 'server s' unknown keyword 'sendpx-v2'; did you mean 'send-proxy-v2' maybe ? [ALERT] 070/095718 (24152) : Error(s) found in configuration file : /dev/stdin [ALERT] 070/095718 (24152) : Fatal errors found in configuration.
2021-03-12 03:58:04 -05:00
NULL /* must be last */
};
MINOR: server: add minimal infrastructure to parse keywords Just like with the "bind" lines, we'll switch the "server" line parsing to keyword registration. The code is essentially the same as for bind keywords, with minor changes such as support for the default-server keywords and support for variable argument count.
2012-10-10 02:27:36 -04:00
/* List head of all known server keywords */
MINOR: config: add a function to dump all known config keywords All registered config keywords that are valid in the config parser are dumped to stdout organized like the regular sections (global, listen, etc). Some keywords that are known to only be valid in frontends or backends will be suffixed with [FE] or [BE]. All regularly registered "bind" and "server" keywords are also dumped, one per "bind" or "server" line. Those depending on ssl are listed after the "ssl" keyword. Doing so required to export the listener and server keyword lists that were static. The function is called from dump_registered_keywords() for keyword class "cfg".
2022-03-29 09:02:44 -04:00
struct srv_kw_list srv_keywords = {
MINOR: server: add minimal infrastructure to parse keywords Just like with the "bind" lines, we'll switch the "server" line parsing to keyword registration. The code is essentially the same as for bind keywords, with minor changes such as support for the default-server keywords and support for variable argument count.
2012-10-10 02:27:36 -04:00
.list = LIST_HEAD_INIT(srv_keywords.list)
};
[MEDIUM] stats: report server and backend cumulated downtime Hello, This patch implements new statistics for SLA calculation by adding new field 'Dwntime' with total down time since restart (both HTTP/CSV) and extending status field (HTTP) or inserting a new one (CSV) with time showing how long each server/backend is in a current state. Additionaly, down transations are also calculated and displayed for backends, so it is possible to know how many times selected backend was down, generating "No server is available to handle this request." error. New information are presentetd in two different ways: - for HTTP: a "human redable form", one of "100000d 23h", "23h 59m" or "59m 59s" - for CSV: seconds I believe that seconds resolution is enough. As there are more columns in the status page I decided to shrink some names to make more space: - Weight -> Wght - Check -> Chk - Down -> Dwn Making described changes I also made some improvements and fixed some small bugs: - don't increment s->health above 's->rise + s->fall - 1'. Previously it was incremented an then (re)set to 's->rise + s->fall - 1'. - do not set server down if it is down already - do not set server up if it is up already - fix colspan in multiple places (mostly introduced by my previous patch) - add missing "status" header to CSV - fix order of retries/redispatches in server (CSV) - s/Tthen/Then/ - s/server/backend/ in DATA_ST_PX_BE (dumpstats.c) Changes from previous version: - deal with negative time intervales - don't relay on s->state (SRV_RUNNING) - little reworked human_time + compacted format (no spaces). If needed it can be used in the future for other purposes by optionally making "cnt" as an argument - leave set_server_down mostly unchanged - only little reworked "process_chk: 9" - additional fields in CSV are appended to the rigth - fix "SEC" macro - named arguments (human_time, be_downtime, srv_downtime) Hope it is OK. If there are only cosmetic changes needed please fill free to correct it, however if there are some bigger changes required I would like to discuss it first or at last to know what exactly was changed especially since I already put this patch into my production server. :) Thank you, Best regards, Krzysztof Oledzki
2007-10-22 10:21:10 -04:00
CLEANUP: thread: rename __decl_hathreads() to __decl_thread() I can never figure whether it takes an "s" or not, and in the end it's better if it matches the file's naming, so let's call it "__decl_thread".
2020-06-05 02:40:51 -04:00
__decl_thread(HA_SPINLOCK_T idle_conn_srv_lock);
MEDIUM: servers: Reorganize the way idle connections are cleaned. Instead of having one task per thread and per server that does clean the idling connections, have only one global task for every servers. That tasks parses all the servers that currently have idling connections, and remove half of them, to put them in a per-thread list of connections to kill. For each thread that does have connections to kill, wake a task to do so, so that the cleaning will be done in the context of said thread.
2019-02-14 12:29:09 -05:00
struct eb_root idle_conn_srv = EB_ROOT;
MINOR: server: move idle_conn_task to read_mostly This pointer is used when adding connections to the idle list and is never changed, let's move it to the read_mostly section.
2021-04-10 11:33:15 -04:00
struct task *idle_conn_task __read_mostly = NULL;
BUG/MEDIUM: server: fix race on servers_list during server deletion Each server is inserted in a global list named servers_list on new_server(). This list is then only used to finalize servers initialization after parsing. On dynamic server creation, there is no issue as new_server() is under thread isolation. However, when a server is deleted after its refcount reached zero, srv_drop() removes it from servers_list without lock protection. In the longterm, this can cause list corruption and crashes, especially if multiple adjacent servers are removed in parallel. To fix this, convert servers_list to a mt_list. This should not impact performance as servers_list is not used during runtime outside of server creation/deletion. This should fix github issue #2733. Thanks to Chris Staite who first found the issue here. This must be backported up to 2.6.
2024-10-23 12:18:48 -04:00
struct mt_list servers_list = MT_LIST_HEAD_INIT(servers_list);
BUG/MAJOR: server/addr: fix a race during server addr:svc_port updates For inet families (IP4/IP6), it is expected that server's addr/port might be updated at runtime from DNS, cli or lua for instance. Such updates were performed under the server's lock. Unfortunately, most readers such as backend.c or sink.c perform the read without taking server's lock because they can't afford slowing down their processing for a type of event which is normally rare. But this could result in bad values being read for the server addr:svc_port tuple (ie: during connection etablishment) as a result of concurrent updates from external components, which can obviously cause some undesirable effects. Instead of slowing the readers down, as we consider server's addr changes are relatively rare, we take another approach and try to update the addr:port atomically by performing changes under full thread isolation when a new change is requested. The changes are performed by a dedicated task which takes care of isolating the current thread and doesn't depend on other threads (independent code path) to protect against dead locks. As such, server's addr:port changes will now be performed atomically, but they will not be processed instantly, they will be translated to events that the dedicated task will pick up from time to time to apply the pending changes. This bug existed for a very long time and has never been reported so far. It was discovered by reading the code during the implementation of log backend ("mode log" in backends). As it involves changes in sensitive areas as well as thread isolation, it is probably not worth considering backporting it for now, unless it is proven that it will help to solve bugs that are actually encountered in the field. This patch depends on: - 24da4d3 ("MINOR: tools: use const for read only pointers in ip{cmp,cpy}") - c886fb5 ("MINOR: server/ip: centralize server ip updates") - event_hdl API (which was first seen on 2.8) + 683b2ae ("MINOR: server/event_hdl: add SERVER_INETADDR event") + BUG/MEDIUM: server/event_hdl: memory overrun in _srv_event_hdl_prepare_inetaddr() + "MINOR: event_hdl: add global tunables" Note that the patch may be reworked so that it doesn't depend on event_hdl API for older versions, the approach would remain the same: this would result in a larger patch due to the need to manually implement a global queue of pending updates with its dedicated task responsible for picking updates and comitting them. An alternative approach could consist in per-server, lock-protected, temporary addr:svc_port storage dedicated to "updaters" were only the most recent values would be kept. The sync task would then use them as source values to atomically update the addr:svc_port members that the runtime readers are actually using.
2023-11-13 12:14:24 -05:00
static struct task *server_atomic_sync_task = NULL;
static event_hdl_async_equeue server_atomic_sync_queue;
MEDIUM: servers: Reorganize the way idle connections are cleaned. Instead of having one task per thread and per server that does clean the idling connections, have only one global task for every servers. That tasks parses all the servers that currently have idling connections, and remove half of them, to put them in a per-thread list of connections to kill. For each thread that does have connections to kill, wake a task to do so, so that the cleaning will be done in the context of said thread.
2019-02-14 12:29:09 -05:00
MINOR: server: add srv->rid (revision id) value With current design, we could not distinguish between previously existing deleted server and a new server reusing the deleted server name/id. This can cause some confusion when auditing stats/events/logs, because the new server will look similar to the old one. To address this, we're adding a new value in server structure: rid rid (revision id) value is an unsigned 32bits value that is set upon server creation. Value is derived from a global counter that starts at 0 and is incremented each time one or multiple server deletions are followed by a server addition (meaning that old name/id reuse could occur). Thanks to this revision id, it is now easy to tell whether the server we're looking at is the same as before or if it has been deleted and re-added in the meantime. (combining server name/id + server revision id yields a process-wide unique identifier)
2022-11-17 10:10:35 -05:00
/* SERVER DELETE(n)->ADD global tracker:
* This is meant to provide srv->rid (revision id) value.
* Revision id allows to differentiate between a previously existing
* deleted server and a new server reusing deleted server name/id.
*
* start value is 0 (even value)
* LSB is used to specify that one or multiple srv delete in a row
* were performed.
* When adding a new server, increment by 1 if current
* value is odd (odd = LSB set),
* because adding a new server after one or
* multiple deletions means we could potentially be reusing old names:
* Increase the revision id to prevent mixups between old and new names.
*
* srv->rid is calculated from cnt even values only.
* sizeof(srv_id_reuse_cnt) must be twice sizeof(srv->rid)
*
* Wraparound is expected and should not cause issues
* (with current design we allow up to 4 billion unique revisions)
*
* Counter is only used under thread_isolate (cli_add/cli_del),
* no need for atomic ops.
*/
static uint64_t srv_id_reuse_cnt = 0;
MINOR: server: Add a dictionary for server names. This patch only declares and defines a dictionary for the server names (stored as ->id member field).
2019-05-20 03:47:07 -04:00
/* The server names dictionary */
MEDIUM: stick-tables: Add srvkey option to stick-table This allows using the address of the server rather than the name of the server for keeping track of servers in a backend for stickiness. The peers code was also extended to support feeding the dictionary using this key instead of the name. Fixes #814
2020-11-20 03:28:26 -05:00
struct dict server_key_dict = {
.name = "server keys",
MINOR: server: Add a dictionary for server names. This patch only declares and defines a dictionary for the server names (stored as ->id member field).
2019-05-20 03:47:07 -04:00
.values = EB_ROOT_UNIQUE,
};
MINOR: server: change adm_st_chg_cause storage type Even though it doesn't look like it at first glance, this is more like a cleanup than an actual code improvement: Given that srv->adm_st_chg_cause has been used to exclusively store static strings ever since it was implemented, we make the choice to store it as an enum instead of a fixed-size string within server struct. This will allow to save some space in server struct, and will make it more easily exportable (ie: event handlers) because of the reduced memory footprint during handling and the ability to later get the corresponding human-readable message when it's explicitly needed.
2023-04-03 11:40:28 -04:00
static const char *srv_adm_st_chg_cause_str[] = {
[SRV_ADM_STCHGC_NONE] = "",
[SRV_ADM_STCHGC_DNS_NOENT] = "entry removed from SRV record",
[SRV_ADM_STCHGC_DNS_NOIP] = "No IP for server ",
[SRV_ADM_STCHGC_DNS_NX] = "DNS NX status",
[SRV_ADM_STCHGC_DNS_TIMEOUT] = "DNS timeout status",
[SRV_ADM_STCHGC_DNS_REFUSED] = "DNS refused status",
[SRV_ADM_STCHGC_DNS_UNSPEC] = "unspecified DNS error",
[SRV_ADM_STCHGC_STATS_DISABLE] = "'disable' on stats page",
[SRV_ADM_STCHGC_STATS_STOP] = "'stop' on stats page"
};
const char *srv_adm_st_chg_cause(enum srv_adm_st_chg_cause cause)
{
return srv_adm_st_chg_cause_str[cause];
}
MINOR: server: change srv_op_st_chg_cause storage type This one is greatly inspired by "MINOR: server: change adm_st_chg_cause storage type". While looking at current srv_op_st_chg_cause usage, it was clear that the struct needed some cleanup since some leftovers from asynchronous server state change updates were left behind and resulted in some useless code duplication, and making the whole thing harder to maintain. Two observations were made: - by tracking down srv_set_{running, stopped, stopping} usage, we can see that the <reason> argument is always a fixed statically allocated string. - check-related state change context (duration, status, code...) is not used anymore since srv_append_status() directly extracts the values from the server->check. This is pure legacy from when the state changes were applied asynchronously. To prevent code duplication, useless string copies and make the reason/cause more exportable, we store it as an enum now, and we provide srv_op_st_chg_cause() function to fetch the related description string. HEALTH and AGENT causes (check related) are now explicitly identified to make consumers like srv_append_op_chg_cause() able to fetch checks info from the server itself if they need to.
2023-04-04 04:17:40 -04:00
static const char *srv_op_st_chg_cause_str[] = {
[SRV_OP_STCHGC_NONE] = "",
[SRV_OP_STCHGC_HEALTH] = "",
[SRV_OP_STCHGC_AGENT] = "",
[SRV_OP_STCHGC_CLI] = "changed from CLI",
[SRV_OP_STCHGC_LUA] = "changed from Lua script",
[SRV_OP_STCHGC_STATS_WEB] = "changed from Web interface",
[SRV_OP_STCHGC_STATEFILE] = "changed from server-state after a reload"
};
MEDIUM: server: Introduce the concept of path parameters Add a new field in struct server, path parameters. It will contain connection informations for the server that are not expected to change. For now, just store the ALPN negociated with the server. Each time an handhskae is done, we'll update it, even though it is not supposed to change. This will be useful when trying to send early data, that way we'll know which mux to use. Each time the server goes down or is disabled, those informations are erased, as we can't be sure those parameters will be the same once the server will be back up.
2025-09-08 16:14:42 -04:00
static void srv_reset_path_parameters(struct server *s)
{
BUG/MEDIUM: server: Add a rwlock to path parameter Add a rwlock to control the server's path_parameter, to make sure multiple threads don't set it at the same time, and it can't be seen in an inconsistent state. Also don't set the parameter every time, only set them if they have changed, to prevent needless writes. This does not need to be backported.
2025-11-04 10:46:50 -05:00
HA_RWLOCK_WRLOCK(SERVER_LOCK, &s->path_params.param_lock);
MEDIUM: server: Introduce the concept of path parameters Add a new field in struct server, path parameters. It will contain connection informations for the server that are not expected to change. For now, just store the ALPN negociated with the server. Each time an handhskae is done, we'll update it, even though it is not supposed to change. This will be useful when trying to send early data, that way we'll know which mux to use. Each time the server goes down or is disabled, those informations are erased, as we can't be sure those parameters will be the same once the server will be back up.
2025-09-08 16:14:42 -04:00
s->path_params.nego_alpn[0] = 0;
BUG/MEDIUM: server: Add a rwlock to path parameter Add a rwlock to control the server's path_parameter, to make sure multiple threads don't set it at the same time, and it can't be seen in an inconsistent state. Also don't set the parameter every time, only set them if they have changed, to prevent needless writes. This does not need to be backported.
2025-11-04 10:46:50 -05:00
HA_RWLOCK_WRUNLOCK(SERVER_LOCK, &s->path_params.param_lock);
MEDIUM: server: Introduce the concept of path parameters Add a new field in struct server, path parameters. It will contain connection informations for the server that are not expected to change. For now, just store the ALPN negociated with the server. Each time an handhskae is done, we'll update it, even though it is not supposed to change. This will be useful when trying to send early data, that way we'll know which mux to use. Each time the server goes down or is disabled, those informations are erased, as we can't be sure those parameters will be the same once the server will be back up.
2025-09-08 16:14:42 -04:00
}
MINOR: server: change srv_op_st_chg_cause storage type This one is greatly inspired by "MINOR: server: change adm_st_chg_cause storage type". While looking at current srv_op_st_chg_cause usage, it was clear that the struct needed some cleanup since some leftovers from asynchronous server state change updates were left behind and resulted in some useless code duplication, and making the whole thing harder to maintain. Two observations were made: - by tracking down srv_set_{running, stopped, stopping} usage, we can see that the <reason> argument is always a fixed statically allocated string. - check-related state change context (duration, status, code...) is not used anymore since srv_append_status() directly extracts the values from the server->check. This is pure legacy from when the state changes were applied asynchronously. To prevent code duplication, useless string copies and make the reason/cause more exportable, we store it as an enum now, and we provide srv_op_st_chg_cause() function to fetch the related description string. HEALTH and AGENT causes (check related) are now explicitly identified to make consumers like srv_append_op_chg_cause() able to fetch checks info from the server itself if they need to.
2023-04-04 04:17:40 -04:00
const char *srv_op_st_chg_cause(enum srv_op_st_chg_cause cause)
{
return srv_op_st_chg_cause_str[cause];
}
CLEANUP: Make parameters of srv_downtime and srv_getinter const The parameters of srv_downtime and srv_getinter are not modified and thus may be const. Signed-off-by: Simon Horman <horms@verge.net.au>
2013-11-01 03:46:15 -04:00
int srv_downtime(const struct server *s)
MINOR: server: add minimal infrastructure to parse keywords Just like with the "bind" lines, we'll switch the "server" line parsing to keyword registration. The code is essentially the same as for bind keywords, with minor changes such as support for the default-server keywords and support for variable argument count.
2012-10-10 02:27:36 -04:00
{
MEDIUM: server: add and use a separate last_change variable for internal use last_change server metric is used for 2 separate purposes. First it is used to report last server state change date for stats and other related metrics. But it is also used internally, including in sensitive paths, such as lb related stuff to take decision or perform computations (ie: in srv_dynamic_maxconn()). Due to last_change counter now being split over thread groups since 16eb0fa ("MAJOR: counters: dispatch counters over thread groups"), reading the aggregated value has a cost, and we cannot afford to consult last_change value from srv_dynamic_maxconn() anymore. Moreover, since the value is used to take decision for the current process we don't wan't the variable to be updated by another process in our back. To prevent performance regression and sharing issues, let's instead add a separate srv->last_change value, which is not updated atomically (given how rare the updates are), and only serves for places where the use of the aggregated last_change counter/stats (split over thread groups) is too costly.
2025-06-30 04:57:29 -04:00
if ((s->cur_state != SRV_ST_STOPPED) || s->last_change >= ns_to_sec(now_ns)) // ignore negative time
[MEDIUM] stats: report server and backend cumulated downtime Hello, This patch implements new statistics for SLA calculation by adding new field 'Dwntime' with total down time since restart (both HTTP/CSV) and extending status field (HTTP) or inserting a new one (CSV) with time showing how long each server/backend is in a current state. Additionaly, down transations are also calculated and displayed for backends, so it is possible to know how many times selected backend was down, generating "No server is available to handle this request." error. New information are presentetd in two different ways: - for HTTP: a "human redable form", one of "100000d 23h", "23h 59m" or "59m 59s" - for CSV: seconds I believe that seconds resolution is enough. As there are more columns in the status page I decided to shrink some names to make more space: - Weight -> Wght - Check -> Chk - Down -> Dwn Making described changes I also made some improvements and fixed some small bugs: - don't increment s->health above 's->rise + s->fall - 1'. Previously it was incremented an then (re)set to 's->rise + s->fall - 1'. - do not set server down if it is down already - do not set server up if it is up already - fix colspan in multiple places (mostly introduced by my previous patch) - add missing "status" header to CSV - fix order of retries/redispatches in server (CSV) - s/Tthen/Then/ - s/server/backend/ in DATA_ST_PX_BE (dumpstats.c) Changes from previous version: - deal with negative time intervales - don't relay on s->state (SRV_RUNNING) - little reworked human_time + compacted format (no spaces). If needed it can be used in the future for other purposes by optionally making "cnt" as an argument - leave set_server_down mostly unchanged - only little reworked "process_chk: 9" - additional fields in CSV are appended to the rigth - fix "SEC" macro - named arguments (human_time, be_downtime, srv_downtime) Hope it is OK. If there are only cosmetic changes needed please fill free to correct it, however if there are some bigger changes required I would like to discuss it first or at last to know what exactly was changed especially since I already put this patch into my production server. :) Thank you, Best regards, Krzysztof Oledzki
2007-10-22 10:21:10 -04:00
return s->down_time;
MEDIUM: server: add and use a separate last_change variable for internal use last_change server metric is used for 2 separate purposes. First it is used to report last server state change date for stats and other related metrics. But it is also used internally, including in sensitive paths, such as lb related stuff to take decision or perform computations (ie: in srv_dynamic_maxconn()). Due to last_change counter now being split over thread groups since 16eb0fa ("MAJOR: counters: dispatch counters over thread groups"), reading the aggregated value has a cost, and we cannot afford to consult last_change value from srv_dynamic_maxconn() anymore. Moreover, since the value is used to take decision for the current process we don't wan't the variable to be updated by another process in our back. To prevent performance regression and sharing issues, let's instead add a separate srv->last_change value, which is not updated atomically (given how rare the updates are), and only serves for places where the use of the aggregated last_change counter/stats (split over thread groups) is too costly.
2025-06-30 04:57:29 -04:00
return ns_to_sec(now_ns) - s->last_change + s->down_time;
[MEDIUM] stats: report server and backend cumulated downtime Hello, This patch implements new statistics for SLA calculation by adding new field 'Dwntime' with total down time since restart (both HTTP/CSV) and extending status field (HTTP) or inserting a new one (CSV) with time showing how long each server/backend is in a current state. Additionaly, down transations are also calculated and displayed for backends, so it is possible to know how many times selected backend was down, generating "No server is available to handle this request." error. New information are presentetd in two different ways: - for HTTP: a "human redable form", one of "100000d 23h", "23h 59m" or "59m 59s" - for CSV: seconds I believe that seconds resolution is enough. As there are more columns in the status page I decided to shrink some names to make more space: - Weight -> Wght - Check -> Chk - Down -> Dwn Making described changes I also made some improvements and fixed some small bugs: - don't increment s->health above 's->rise + s->fall - 1'. Previously it was incremented an then (re)set to 's->rise + s->fall - 1'. - do not set server down if it is down already - do not set server up if it is up already - fix colspan in multiple places (mostly introduced by my previous patch) - add missing "status" header to CSV - fix order of retries/redispatches in server (CSV) - s/Tthen/Then/ - s/server/backend/ in DATA_ST_PX_BE (dumpstats.c) Changes from previous version: - deal with negative time intervales - don't relay on s->state (SRV_RUNNING) - little reworked human_time + compacted format (no spaces). If needed it can be used in the future for other purposes by optionally making "cnt" as an argument - leave set_server_down mostly unchanged - only little reworked "process_chk: 9" - additional fields in CSV are appended to the rigth - fix "SEC" macro - named arguments (human_time, be_downtime, srv_downtime) Hope it is OK. If there are only cosmetic changes needed please fill free to correct it, however if there are some bigger changes required I would like to discuss it first or at last to know what exactly was changed especially since I already put this patch into my production server. :) Thank you, Best regards, Krzysztof Oledzki
2007-10-22 10:21:10 -04:00
}
[MEDIUM] added the new 'stats' keyword with user authentication subsystem. Right now it only validates the user/passwd according to a specified list, and lets the user pass through the proxy if the authentication is OK, and it refuses any invalid access with a 401 Unauthorized response.
2006-05-14 17:06:28 -04:00
MEDIUM: Paramatise functions over the check of a server Paramatise the following functions over the check of a server * set_server_down * set_server_up * srv_getinter * server_status_printf * set_server_check_status * set_server_disabled * set_server_enabled Generally the server parameter of these functions has been removed. Where it is still needed it is obtained using check->server. This is in preparation for associating a agent check with a server which runs as well as the server's existing check. By paramatising these functions they may act on each of the checks without further significant modification. Explanation of the SSP_O_HCHK portion of this change: * Prior to this patch SSP_O_HCHK serves a single purpose which is to tell server_status_printf() weather it should print the details of the check of a server or not. With the paramatisation that this patch adds there are two cases. 1) Printing the details of the check in which case a valid check parameter is needed. 2) Not printing the details of the check in which case the contents check parameter are unused. In case 1) we could pass SSP_O_HCHK and a valid check and; In case 2) we could pass !SSP_O_HCHK and any value for check including NULL. If NULL is used for case 2) then SSP_O_HCHK becomes supurfulous and as NULL is used for case 2) SSP_O_HCHK has been removed. Signed-off-by: Simon Horman <horms@verge.net.au>
2013-02-23 01:35:38 -05:00
int srv_getinter(const struct check *check)
MINOR: server: add minimal infrastructure to parse keywords Just like with the "bind" lines, we'll switch the "server" line parsing to keyword registration. The code is essentially the same as for bind keywords, with minor changes such as support for the default-server keywords and support for variable argument count.
2012-10-10 02:27:36 -04:00
{
MEDIUM: Paramatise functions over the check of a server Paramatise the following functions over the check of a server * set_server_down * set_server_up * srv_getinter * server_status_printf * set_server_check_status * set_server_disabled * set_server_enabled Generally the server parameter of these functions has been removed. Where it is still needed it is obtained using check->server. This is in preparation for associating a agent check with a server which runs as well as the server's existing check. By paramatising these functions they may act on each of the checks without further significant modification. Explanation of the SSP_O_HCHK portion of this change: * Prior to this patch SSP_O_HCHK serves a single purpose which is to tell server_status_printf() weather it should print the details of the check of a server or not. With the paramatisation that this patch adds there are two cases. 1) Printing the details of the check in which case a valid check parameter is needed. 2) Not printing the details of the check in which case the contents check parameter are unused. In case 1) we could pass SSP_O_HCHK and a valid check and; In case 2) we could pass !SSP_O_HCHK and any value for check including NULL. If NULL is used for case 2) then SSP_O_HCHK becomes supurfulous and as NULL is used for case 2) SSP_O_HCHK has been removed. Signed-off-by: Simon Horman <horms@verge.net.au>
2013-02-23 01:35:38 -05:00
const struct server *s = check->server;
BUG/MINOR: checks: restore legacy on-error fastinter behavior With previous commit, 9e080bf ("BUG/MINOR: checks: make sure fastinter is used even on forced transitions"), on-error mark-down|sudden-death|fail-check are now working as expected. However, on-error fastinter remains broken because srv_getinter(), used in the above commit to check the expiration date, won't return fastinter interval if server health is maxed out (which is the case with on-error fastinter mode). To fix this, we introduce a check flag named CHK_ST_FASTINTER. This flag is set when on-error is triggered. This way we can force srv_getinter() to return fastinter interval whenever the flag is set. The flag is automatically cleared as soon as the new check task expiry is recalculated in process_chk_conn(). This restores original behavior prior to d114f4a ("MEDIUM: checks: spread the checks load over random threads"). It must be backported to 2.7 along with the aforementioned commits.
2022-12-07 06:17:24 -05:00
if ((check->state & (CHK_ST_CONFIGURED|CHK_ST_FASTINTER)) == CHK_ST_CONFIGURED &&
(check->health == check->rise + check->fall - 1))
MEDIUM: Paramatise functions over the check of a server Paramatise the following functions over the check of a server * set_server_down * set_server_up * srv_getinter * server_status_printf * set_server_check_status * set_server_disabled * set_server_enabled Generally the server parameter of these functions has been removed. Where it is still needed it is obtained using check->server. This is in preparation for associating a agent check with a server which runs as well as the server's existing check. By paramatising these functions they may act on each of the checks without further significant modification. Explanation of the SSP_O_HCHK portion of this change: * Prior to this patch SSP_O_HCHK serves a single purpose which is to tell server_status_printf() weather it should print the details of the check of a server or not. With the paramatisation that this patch adds there are two cases. 1) Printing the details of the check in which case a valid check parameter is needed. 2) Not printing the details of the check in which case the contents check parameter are unused. In case 1) we could pass SSP_O_HCHK and a valid check and; In case 2) we could pass !SSP_O_HCHK and any value for check including NULL. If NULL is used for case 2) then SSP_O_HCHK becomes supurfulous and as NULL is used for case 2) SSP_O_HCHK has been removed. Signed-off-by: Simon Horman <horms@verge.net.au>
2013-02-23 01:35:38 -05:00
return check->inter;
[MEDIUM]: rework checks handling This patch adds two new variables: fastinter and downinter. When server state is: - non-transitionally UP -> inter (no change) - transitionally UP (going down), unchecked or transitionally DOWN (going up) -> fastinter - down -> downinter It allows to set something like: server sr6 127.0.51.61:80 cookie s6 check inter 10000 downinter 20000 fastinter 500 fall 3 weight 40 In the above example haproxy uses 10000ms between checks but as soon as one check fails fastinter (500ms) is used. If server is down downinter (20000) is used or fastinter (500ms) if one check pass. Fastinter is also used when haproxy starts. New "timeout.check" variable was added, if set haproxy uses it as an additional read timeout, but only after a connection has been already established. I was thinking about using "timeout.server" here but most people set this with an addition reserve but still want checks to kick out laggy servers. Please also note that in most cases check request is much simpler and faster to handle than normal requests so this timeout should be smaller. I also changed the timeout used for check connections establishing. Changes from the previous version: - use tv_isset() to check if the timeout is set, - use min("timeout connect", "inter") but only if "timeout check" is set as this min alone may be to short for full (connect + read) check, - debug code (fprintf) commented/removed - documentation Compile tested only (sorry!) as I'm currently traveling but changes are rather small and trivial.
2008-01-20 19:54:06 -05:00
MEDIUM: check: server states and weight propagation re-work The server state and weight was reworked to handle "pending" values updated by checks/CLI/LUA/agent. These values are commited to be propagated to the LB stack. In further dev related to multi-thread, the commit will be handled into a sync point. Pending values are named using the prefix 'next_' Current values used by the LB stack are named 'cur_'
2017-08-31 08:41:55 -04:00
if ((s->next_state == SRV_ST_STOPPED) && check->health == 0)
MEDIUM: Paramatise functions over the check of a server Paramatise the following functions over the check of a server * set_server_down * set_server_up * srv_getinter * server_status_printf * set_server_check_status * set_server_disabled * set_server_enabled Generally the server parameter of these functions has been removed. Where it is still needed it is obtained using check->server. This is in preparation for associating a agent check with a server which runs as well as the server's existing check. By paramatising these functions they may act on each of the checks without further significant modification. Explanation of the SSP_O_HCHK portion of this change: * Prior to this patch SSP_O_HCHK serves a single purpose which is to tell server_status_printf() weather it should print the details of the check of a server or not. With the paramatisation that this patch adds there are two cases. 1) Printing the details of the check in which case a valid check parameter is needed. 2) Not printing the details of the check in which case the contents check parameter are unused. In case 1) we could pass SSP_O_HCHK and a valid check and; In case 2) we could pass !SSP_O_HCHK and any value for check including NULL. If NULL is used for case 2) then SSP_O_HCHK becomes supurfulous and as NULL is used for case 2) SSP_O_HCHK has been removed. Signed-off-by: Simon Horman <horms@verge.net.au>
2013-02-23 01:35:38 -05:00
return (check->downinter)?(check->downinter):(check->inter);
[MEDIUM]: rework checks handling This patch adds two new variables: fastinter and downinter. When server state is: - non-transitionally UP -> inter (no change) - transitionally UP (going down), unchecked or transitionally DOWN (going up) -> fastinter - down -> downinter It allows to set something like: server sr6 127.0.51.61:80 cookie s6 check inter 10000 downinter 20000 fastinter 500 fall 3 weight 40 In the above example haproxy uses 10000ms between checks but as soon as one check fails fastinter (500ms) is used. If server is down downinter (20000) is used or fastinter (500ms) if one check pass. Fastinter is also used when haproxy starts. New "timeout.check" variable was added, if set haproxy uses it as an additional read timeout, but only after a connection has been already established. I was thinking about using "timeout.server" here but most people set this with an addition reserve but still want checks to kick out laggy servers. Please also note that in most cases check request is much simpler and faster to handle than normal requests so this timeout should be smaller. I also changed the timeout used for check connections establishing. Changes from the previous version: - use tv_isset() to check if the timeout is set, - use min("timeout connect", "inter") but only if "timeout check" is set as this min alone may be to short for full (connect + read) check, - debug code (fprintf) commented/removed - documentation Compile tested only (sorry!) as I'm currently traveling but changes are rather small and trivial.
2008-01-20 19:54:06 -05:00
MEDIUM: Paramatise functions over the check of a server Paramatise the following functions over the check of a server * set_server_down * set_server_up * srv_getinter * server_status_printf * set_server_check_status * set_server_disabled * set_server_enabled Generally the server parameter of these functions has been removed. Where it is still needed it is obtained using check->server. This is in preparation for associating a agent check with a server which runs as well as the server's existing check. By paramatising these functions they may act on each of the checks without further significant modification. Explanation of the SSP_O_HCHK portion of this change: * Prior to this patch SSP_O_HCHK serves a single purpose which is to tell server_status_printf() weather it should print the details of the check of a server or not. With the paramatisation that this patch adds there are two cases. 1) Printing the details of the check in which case a valid check parameter is needed. 2) Not printing the details of the check in which case the contents check parameter are unused. In case 1) we could pass SSP_O_HCHK and a valid check and; In case 2) we could pass !SSP_O_HCHK and any value for check including NULL. If NULL is used for case 2) then SSP_O_HCHK becomes supurfulous and as NULL is used for case 2) SSP_O_HCHK has been removed. Signed-off-by: Simon Horman <horms@verge.net.au>
2013-02-23 01:35:38 -05:00
return (check->fastinter)?(check->fastinter):(check->inter);
[MEDIUM]: rework checks handling This patch adds two new variables: fastinter and downinter. When server state is: - non-transitionally UP -> inter (no change) - transitionally UP (going down), unchecked or transitionally DOWN (going up) -> fastinter - down -> downinter It allows to set something like: server sr6 127.0.51.61:80 cookie s6 check inter 10000 downinter 20000 fastinter 500 fall 3 weight 40 In the above example haproxy uses 10000ms between checks but as soon as one check fails fastinter (500ms) is used. If server is down downinter (20000) is used or fastinter (500ms) if one check pass. Fastinter is also used when haproxy starts. New "timeout.check" variable was added, if set haproxy uses it as an additional read timeout, but only after a connection has been already established. I was thinking about using "timeout.server" here but most people set this with an addition reserve but still want checks to kick out laggy servers. Please also note that in most cases check request is much simpler and faster to handle than normal requests so this timeout should be smaller. I also changed the timeout used for check connections establishing. Changes from the previous version: - use tv_isset() to check if the timeout is set, - use min("timeout connect", "inter") but only if "timeout check" is set as this min alone may be to short for full (connect + read) check, - debug code (fprintf) commented/removed - documentation Compile tested only (sorry!) as I'm currently traveling but changes are rather small and trivial.
2008-01-20 19:54:06 -05:00
}
MINOR: server/ip: centralize server ip updates Add a new helper function named _srv_update_inetaddr() to centralize ip addr and port updates during runtime.
2023-11-13 10:42:56 -05:00
/* Update server's addr:svc_port tuple in INET context
*
CLEANUP: assorted typo fixes in the code and comments This is 38th iteration of typo fixes
2023-12-29 14:05:20 -05:00
* Must be called under thread isolation to ensure consistent readings across
BUG/MAJOR: server/addr: fix a race during server addr:svc_port updates For inet families (IP4/IP6), it is expected that server's addr/port might be updated at runtime from DNS, cli or lua for instance. Such updates were performed under the server's lock. Unfortunately, most readers such as backend.c or sink.c perform the read without taking server's lock because they can't afford slowing down their processing for a type of event which is normally rare. But this could result in bad values being read for the server addr:svc_port tuple (ie: during connection etablishment) as a result of concurrent updates from external components, which can obviously cause some undesirable effects. Instead of slowing the readers down, as we consider server's addr changes are relatively rare, we take another approach and try to update the addr:port atomically by performing changes under full thread isolation when a new change is requested. The changes are performed by a dedicated task which takes care of isolating the current thread and doesn't depend on other threads (independent code path) to protect against dead locks. As such, server's addr:port changes will now be performed atomically, but they will not be processed instantly, they will be translated to events that the dedicated task will pick up from time to time to apply the pending changes. This bug existed for a very long time and has never been reported so far. It was discovered by reading the code during the implementation of log backend ("mode log" in backends). As it involves changes in sensitive areas as well as thread isolation, it is probably not worth considering backporting it for now, unless it is proven that it will help to solve bugs that are actually encountered in the field. This patch depends on: - 24da4d3 ("MINOR: tools: use const for read only pointers in ip{cmp,cpy}") - c886fb5 ("MINOR: server/ip: centralize server ip updates") - event_hdl API (which was first seen on 2.8) + 683b2ae ("MINOR: server/event_hdl: add SERVER_INETADDR event") + BUG/MEDIUM: server/event_hdl: memory overrun in _srv_event_hdl_prepare_inetaddr() + "MINOR: event_hdl: add global tunables" Note that the patch may be reworked so that it doesn't depend on event_hdl API for older versions, the approach would remain the same: this would result in a larger patch due to the need to manually implement a global queue of pending updates with its dedicated task responsible for picking updates and comitting them. An alternative approach could consist in per-server, lock-protected, temporary addr:svc_port storage dedicated to "updaters" were only the most recent values would be kept. The sync task would then use them as source values to atomically update the addr:svc_port members that the runtime readers are actually using.
2023-11-13 12:14:24 -05:00
* all threads (addr:svc_port might be read without srv lock being held).
MINOR: server/ip: centralize server ip updates Add a new helper function named _srv_update_inetaddr() to centralize ip addr and port updates during runtime.
2023-11-13 10:42:56 -05:00
*/
BUG/MINOR: server/event_hdl: propagate map port info through inetaddr event server addr:svc_port updates during runtime might set or clear the SRV_F_MAPPORTS flag. Unfortunately, the flag update is still directly performed by srv_update_addr_port() function while the addr:svc_port update is being scheduled for atomic update. Given that existing readers don't take server's lock to read addr:svc_port, they also check the SRV_F_MAPPORTS flag right after without the lock. So we could cause the readers to incorrectly interpret the svc_port from the server struct because the mapport information is not published atomically, resulting in inconsistencies between svc_port / mapport flag. (MAPPORTS flag causes svc_port to be used differently by the reader) To fix this, we publish the mapport information within the INETADDR server event and we let the task responsible for updating server's addr and port position or clear the flag depending on the mapport hint. This patch depends on: - MINOR: server/event_hdl: add server_inetaddr struct to facilitate event data usage - MINOR: server/event_hdl: update _srv_event_hdl_prepare_inetaddr prototype This should be backported in 2.9 with 683b2ae01 ("MINOR: server/event_hdl: add SERVER_INETADDR event")
2023-12-07 11:08:08 -05:00
static void _srv_set_inetaddr_port(struct server *srv,
const struct sockaddr_storage *addr,
unsigned int svc_port, uint8_t mapped_port)
MINOR: server/ip: centralize server ip updates Add a new helper function named _srv_update_inetaddr() to centralize ip addr and port updates during runtime.
2023-11-13 10:42:56 -05:00
{
ipcpy(addr, &srv->addr);
srv->svc_port = svc_port;
BUG/MINOR: server/event_hdl: propagate map port info through inetaddr event server addr:svc_port updates during runtime might set or clear the SRV_F_MAPPORTS flag. Unfortunately, the flag update is still directly performed by srv_update_addr_port() function while the addr:svc_port update is being scheduled for atomic update. Given that existing readers don't take server's lock to read addr:svc_port, they also check the SRV_F_MAPPORTS flag right after without the lock. So we could cause the readers to incorrectly interpret the svc_port from the server struct because the mapport information is not published atomically, resulting in inconsistencies between svc_port / mapport flag. (MAPPORTS flag causes svc_port to be used differently by the reader) To fix this, we publish the mapport information within the INETADDR server event and we let the task responsible for updating server's addr and port position or clear the flag depending on the mapport hint. This patch depends on: - MINOR: server/event_hdl: add server_inetaddr struct to facilitate event data usage - MINOR: server/event_hdl: update _srv_event_hdl_prepare_inetaddr prototype This should be backported in 2.9 with 683b2ae01 ("MINOR: server/event_hdl: add SERVER_INETADDR event")
2023-12-07 11:08:08 -05:00
if (mapped_port)
srv->flags |= SRV_F_MAPPORTS;
else
srv->flags &= ~SRV_F_MAPPORTS;
BUG/MEDIUM: server/lbprm: fix crash in _srv_set_inetaddr_port() Since faa8c3e ("MEDIUM: lb-chash: Deterministic node hashes based on server address") the following configuration will cause haproxy to crash: backend test1 mode http balance hash int(1) server s1 haproxy.org:80 This is because lbprm.update_server_eweight() method is now systematically called in _srv_set_inetaddr_port() upon srv addr/port change (and with the above config it happens during startup after initial dns resolution). However, depending on the chosen lbprm algo, update_server_eweight function may not be set (it is not a mandatory method, some lb implementations don't define it). Thus, using 'balance hash' with map-based hashing or 'balance sticky' will cause a crash due to a NULL de-reference in _srv_set_inetaddr_port(). To fix the issue, we first check that the update_server_eweight() method is set before using it. No backport needed unless faa8c3e ("MEDIUM: lb-chash: Deterministic node hashes based on server address") gets backported.
2024-04-03 05:41:57 -04:00
if (srv->proxy->lbprm.update_server_eweight) {
/* some balancers (chash in particular) may use the addr in their routing decisions */
srv->proxy->lbprm.update_server_eweight(srv);
}
MEDIUM: lb-chash: Deterministic node hashes based on server address Motivation: When services are discovered through DNS resolution, the order in which DNS records get resolved and assigned to servers is arbitrary. Therefore, even though two HAProxy instances using chash balancing might agree that a particular request should go to server3, it is likely the case that they have assigned different IPs and ports to the server in that slot. This patch adds a server option, "hash-key <key>" which can be set to "id" (the existing behaviour, default), "addr", or "addr-port". By deriving the keys for the chash tree nodes from a server's address and port we ensure that independent HAProxy instances will agree on routing decisions. If an address is not known then the key is derived from the server's puid as it was previously. When adjusting a server's weight, we now check whether the server's hash has changed. If it has, we have to remove all its nodes first, since the node keys will also have to change.
2024-02-16 16:00:35 -05:00
MEDIUM: log/balance: support FQDN for UDP log servers In previous log backend implementation, we created a pseudo log target for each declared log server, and we made the log target's address point to the actual server address to save some time and prevent unecessary copies. But this was done without knowing that when FQDN is involved (more broadly when dns/resolution is involved), the "port" part of server addr should not be relied upon, and we should explicitly use ->svc_port for that purpose. With that in mind and thanks to the previous commit, some changes were required: we allocate a dedicated addr within the log target when target is in DGRAM mode. The addr is first initialized with known values and it is then updated automatically by _srv_set_inetaddr() during runtime. (the change is atomic so readers don't need to worry about it) addr from server "log target" (INET/DGRAM mode) is made of the combination of server's address (lacking the port part) and server's svc_port.
2023-11-09 10:57:01 -05:00
if (srv->log_target && srv->log_target->type == LOG_TARGET_DGRAM) {
/* server is used as a log target, manually update log target addr for DGRAM */
ipcpy(addr, srv->log_target->addr);
set_host_port(srv->log_target->addr, svc_port);
}
MINOR: server/ip: centralize server ip updates Add a new helper function named _srv_update_inetaddr() to centralize ip addr and port updates during runtime.
2023-11-13 10:42:56 -05:00
}
BUG/MINOR: server/event_hdl: propagate map port info through inetaddr event server addr:svc_port updates during runtime might set or clear the SRV_F_MAPPORTS flag. Unfortunately, the flag update is still directly performed by srv_update_addr_port() function while the addr:svc_port update is being scheduled for atomic update. Given that existing readers don't take server's lock to read addr:svc_port, they also check the SRV_F_MAPPORTS flag right after without the lock. So we could cause the readers to incorrectly interpret the svc_port from the server struct because the mapport information is not published atomically, resulting in inconsistencies between svc_port / mapport flag. (MAPPORTS flag causes svc_port to be used differently by the reader) To fix this, we publish the mapport information within the INETADDR server event and we let the task responsible for updating server's addr and port position or clear the flag depending on the mapport hint. This patch depends on: - MINOR: server/event_hdl: add server_inetaddr struct to facilitate event data usage - MINOR: server/event_hdl: update _srv_event_hdl_prepare_inetaddr prototype This should be backported in 2.9 with 683b2ae01 ("MINOR: server/event_hdl: add SERVER_INETADDR event")
2023-12-07 11:08:08 -05:00
/* same as _srv_set_inetaddr_port() but only updates the addr part
*/
static void _srv_set_inetaddr(struct server *srv,
const struct sockaddr_storage *addr)
{
_srv_set_inetaddr_port(srv, addr, srv->svc_port, !!(srv->flags & SRV_F_MAPPORTS));
}
BUG/MAJOR: server/addr: fix a race during server addr:svc_port updates For inet families (IP4/IP6), it is expected that server's addr/port might be updated at runtime from DNS, cli or lua for instance. Such updates were performed under the server's lock. Unfortunately, most readers such as backend.c or sink.c perform the read without taking server's lock because they can't afford slowing down their processing for a type of event which is normally rare. But this could result in bad values being read for the server addr:svc_port tuple (ie: during connection etablishment) as a result of concurrent updates from external components, which can obviously cause some undesirable effects. Instead of slowing the readers down, as we consider server's addr changes are relatively rare, we take another approach and try to update the addr:port atomically by performing changes under full thread isolation when a new change is requested. The changes are performed by a dedicated task which takes care of isolating the current thread and doesn't depend on other threads (independent code path) to protect against dead locks. As such, server's addr:port changes will now be performed atomically, but they will not be processed instantly, they will be translated to events that the dedicated task will pick up from time to time to apply the pending changes. This bug existed for a very long time and has never been reported so far. It was discovered by reading the code during the implementation of log backend ("mode log" in backends). As it involves changes in sensitive areas as well as thread isolation, it is probably not worth considering backporting it for now, unless it is proven that it will help to solve bugs that are actually encountered in the field. This patch depends on: - 24da4d3 ("MINOR: tools: use const for read only pointers in ip{cmp,cpy}") - c886fb5 ("MINOR: server/ip: centralize server ip updates") - event_hdl API (which was first seen on 2.8) + 683b2ae ("MINOR: server/event_hdl: add SERVER_INETADDR event") + BUG/MEDIUM: server/event_hdl: memory overrun in _srv_event_hdl_prepare_inetaddr() + "MINOR: event_hdl: add global tunables" Note that the patch may be reworked so that it doesn't depend on event_hdl API for older versions, the approach would remain the same: this would result in a larger patch due to the need to manually implement a global queue of pending updates with its dedicated task responsible for picking updates and comitting them. An alternative approach could consist in per-server, lock-protected, temporary addr:svc_port storage dedicated to "updaters" were only the most recent values would be kept. The sync task would then use them as source values to atomically update the addr:svc_port members that the runtime readers are actually using.
2023-11-13 12:14:24 -05:00
/*
* Function executed by server_atomic_sync_task to perform atomic updates on
* compatible server struct members that are not guarded by any lock since
* they are not supposed to change often and are subject to being used in
* sensitive codepaths
*
* Some updates may require thread isolation: we start without isolation
* but as soon as we encounter an event that requires isolation, we do so.
* Once the event is processed, we keep the isolation until we've processed
* the whole batch of events and leave isolation once we're done, as it would
* be very costly to try to acquire isolation multiple times in a row.
* The task will limit itself to a number of events per run to prevent
* thread contention (see: "tune.events.max-events-at-once").
*
* TODO: if we find out that enforcing isolation is too costly, we may
* consider adding thread_isolate_try_full(timeout) or equivalent to the
* thread API so that we can do our best not to block harmless threads
* for too long if one or multiple threads are still heavily busy. This
* would mean that the task would be capable of rescheduling itself to
* start again on the current event if it failed to acquire thread
* isolation. This would also imply that the event_hdl API allows us
* to check an event without popping it from the queue first (remove the
* event once it is successfully processed).
*/
static void srv_set_addr_desc(struct server *s, int reattach);
static struct task *server_atomic_sync(struct task *task, void *context, unsigned int state)
{
unsigned int remain = event_hdl_tune.max_events_at_once; // to limit max number of events per batch
struct event_hdl_async_event *event;
MINOR: server: ensure max_events_at_once > 0 in server_atomic_sync() In 8f1fd96 ("BUG/MEDIUM: server/addr: fix tune.events.max-events-at-once event miss and leak"), we added a comment saying that tune.events.max-events-at-once is assumed to be strictly positive. It is so because the keyword parser forces values between 1 and 10000: we don't want less than 1 because it wouldn't make any sense, and 10k max because beyond that we could create contention in server_atomic_sync() Now as the above commit implements a do..while it heavily relies on the fact that the budget is at least 1. Upon soft-stop, we break away from the loop without decrementing the budget. With all that in mind, it is safe to assume that the 'remain' counter will only fall to 0 if the task runs out of budget while doing work, in which case the task still exists and must be rescheduled. As seen in GH #2667 this assumption was ambiguous, so let's make it official by adding a pair of BUG_ON() that make it explicit that it works because remain 'cannot' be 0 unless the entire budget was consumed. No backport needed.
2024-08-07 12:04:08 -04:00
BUG_ON(remain == 0); // event_hdl_tune.max_events_at_once is expected to be > 0
BUG/MAJOR: server/addr: fix a race during server addr:svc_port updates For inet families (IP4/IP6), it is expected that server's addr/port might be updated at runtime from DNS, cli or lua for instance. Such updates were performed under the server's lock. Unfortunately, most readers such as backend.c or sink.c perform the read without taking server's lock because they can't afford slowing down their processing for a type of event which is normally rare. But this could result in bad values being read for the server addr:svc_port tuple (ie: during connection etablishment) as a result of concurrent updates from external components, which can obviously cause some undesirable effects. Instead of slowing the readers down, as we consider server's addr changes are relatively rare, we take another approach and try to update the addr:port atomically by performing changes under full thread isolation when a new change is requested. The changes are performed by a dedicated task which takes care of isolating the current thread and doesn't depend on other threads (independent code path) to protect against dead locks. As such, server's addr:port changes will now be performed atomically, but they will not be processed instantly, they will be translated to events that the dedicated task will pick up from time to time to apply the pending changes. This bug existed for a very long time and has never been reported so far. It was discovered by reading the code during the implementation of log backend ("mode log" in backends). As it involves changes in sensitive areas as well as thread isolation, it is probably not worth considering backporting it for now, unless it is proven that it will help to solve bugs that are actually encountered in the field. This patch depends on: - 24da4d3 ("MINOR: tools: use const for read only pointers in ip{cmp,cpy}") - c886fb5 ("MINOR: server/ip: centralize server ip updates") - event_hdl API (which was first seen on 2.8) + 683b2ae ("MINOR: server/event_hdl: add SERVER_INETADDR event") + BUG/MEDIUM: server/event_hdl: memory overrun in _srv_event_hdl_prepare_inetaddr() + "MINOR: event_hdl: add global tunables" Note that the patch may be reworked so that it doesn't depend on event_hdl API for older versions, the approach would remain the same: this would result in a larger patch due to the need to manually implement a global queue of pending updates with its dedicated task responsible for picking updates and comitting them. An alternative approach could consist in per-server, lock-protected, temporary addr:svc_port storage dedicated to "updaters" were only the most recent values would be kept. The sync task would then use them as source values to atomically update the addr:svc_port members that the runtime readers are actually using.
2023-11-13 12:14:24 -05:00
/* check for new server events that we care about */
BUG/MEDIUM: server/addr: fix tune.events.max-events-at-once event miss and leak An issue has been introduced with cd99440 ("BUG/MAJOR: server/addr: fix a race during server addr:svc_port updates"). Indeed, in the above commit we implemented the atomic_sync task which is responsible for consuming pending server events to apply the changes atomically. For now only server's addr updates are concerned. To prevent the task from causing contention, a budget was assigned to it. It can be controlled with the global tunable 'tune.events.max-events-at-once': the task may not process more than this number of events at once. However, a bug was introduced with this budget logic: each time the task has to be interrupted because it runs out of budget, we reschedule the task to finish where it left off, but the current event which was already removed from the queue wasn't processed yet. This means that this pending event (each tune.events.max-events-at-once) is effectively lost. When the atomic_sync task deals with large number of concurrent events, this bug has 2 known consequences: first a server's addr/port update will be lost every 'tune.events.max-events-at-once'. This can of course cause reliability issues because if the event is not republished periodically, the server could stay in a stale state for indefinite amount of time. This is the case when the DNS server flaps for instance: some servers may not come back UP after the incident as described in GH #2666. Another issue is that the lost event was not cleaned up, resulting in a small memory leak. So in the end, it means that the bug is likely to cause more and more degradation over time until haproxy is restarted. As a workaround, 'tune.events.max-events-at-once' may be set to the maximum number of events expected per batch. Note however that this value cannot exceed 10 000, otherwise it could cause the watchdog to trigger due to the task being busy for too long and preventing other threads from making any progress. Setting higher values may not be optimal for common workloads so it should only be used to mitigate the bug while waiting for this fix. Since tune.events.max-events-at-once defaults to 100, this bug only affects configs that involve more than 100 servers whose addr:port properties are likely to be updated at the same time (batched updates from cli, lua, dns..) To fix the bug, we move the budget check after the current event is fully handled. For that we went from a basic 'while' to 'do..while' loop as we assume from the config that 'tune.events.max-events-at-once' cannot be 0. While at it, we reschedule the task once thread isolation ends (it was not required to perform the reschedule while under isolation) to give the hand back faster to waiting threads. This patch should be backported up to 2.9 with cd99440. It should fix GH #2666.
2024-08-06 08:29:56 -04:00
do {
event = event_hdl_async_equeue_pop(&server_atomic_sync_queue);
if (!event)
break; /* no events in queue */
BUG/MAJOR: server/addr: fix a race during server addr:svc_port updates For inet families (IP4/IP6), it is expected that server's addr/port might be updated at runtime from DNS, cli or lua for instance. Such updates were performed under the server's lock. Unfortunately, most readers such as backend.c or sink.c perform the read without taking server's lock because they can't afford slowing down their processing for a type of event which is normally rare. But this could result in bad values being read for the server addr:svc_port tuple (ie: during connection etablishment) as a result of concurrent updates from external components, which can obviously cause some undesirable effects. Instead of slowing the readers down, as we consider server's addr changes are relatively rare, we take another approach and try to update the addr:port atomically by performing changes under full thread isolation when a new change is requested. The changes are performed by a dedicated task which takes care of isolating the current thread and doesn't depend on other threads (independent code path) to protect against dead locks. As such, server's addr:port changes will now be performed atomically, but they will not be processed instantly, they will be translated to events that the dedicated task will pick up from time to time to apply the pending changes. This bug existed for a very long time and has never been reported so far. It was discovered by reading the code during the implementation of log backend ("mode log" in backends). As it involves changes in sensitive areas as well as thread isolation, it is probably not worth considering backporting it for now, unless it is proven that it will help to solve bugs that are actually encountered in the field. This patch depends on: - 24da4d3 ("MINOR: tools: use const for read only pointers in ip{cmp,cpy}") - c886fb5 ("MINOR: server/ip: centralize server ip updates") - event_hdl API (which was first seen on 2.8) + 683b2ae ("MINOR: server/event_hdl: add SERVER_INETADDR event") + BUG/MEDIUM: server/event_hdl: memory overrun in _srv_event_hdl_prepare_inetaddr() + "MINOR: event_hdl: add global tunables" Note that the patch may be reworked so that it doesn't depend on event_hdl API for older versions, the approach would remain the same: this would result in a larger patch due to the need to manually implement a global queue of pending updates with its dedicated task responsible for picking updates and comitting them. An alternative approach could consist in per-server, lock-protected, temporary addr:svc_port storage dedicated to "updaters" were only the most recent values would be kept. The sync task would then use them as source values to atomically update the addr:svc_port members that the runtime readers are actually using.
2023-11-13 12:14:24 -05:00
if (event_hdl_sub_type_equal(event->type, EVENT_HDL_SUB_END)) {
/* ending event: no more events to come */
event_hdl_async_free_event(event);
task_destroy(task);
task = NULL;
break;
}
/* new event to process */
if (event_hdl_sub_type_equal(event->type, EVENT_HDL_SUB_SERVER_INETADDR)) {
struct sockaddr_storage new_addr;
struct event_hdl_cb_data_server_inetaddr *data = event->data;
struct proxy *px;
struct server *srv;
/* server ip:port changed, we must atomically update data members
* to prevent invalid reads by other threads.
*/
BUG/MEDIUM: server: fix race on server_atomic_sync() The following patch fixes a race condition during server addr/port update : cd994407a9545a8d84e410dc0cc18c30966b70d8 BUG/MAJOR: server/addr: fix a race during server addr:svc_port updates The new update mechanism is implemented via an event update. It uses thread isolation to guarantee that no other thread is accessing server addr/port. Furthermore, to ensure server instance is not deleted just before the event handler, server instance is lookup via its ID in proxy tree. However, thread isolation is only entered after server lookup. This leaves a tiny race condition as the thread will be marked as harmless and a concurrent thread can delete the server in the meantime. This causes server_atomic_sync() to manipulated a deleted server instance to reinsert it in used_server_addr backend tree. This can cause a segfault during this operation or possibly on a future used_server_addr tree access. This issue was detected by criteo. Several backtraces were retrieved, each related to server addr_node insert or delete operation, either in srv_set_addr_desc(), or add/delete dynamic server handlers. To fix this, simply extend thread isolation section to start it before server lookup. This ensures that once retrieved the server cannot be deleted until its addr/port are updated. To ensure this issue won't happen anymore, a new BUG_ON() is added in srv_set_addr_desc(). Also note that ebpt_delete() is now called every time on delete handler as this is a safe idempotent operation. To reproduce these crashes, a script was executed to add then remove different servers every second. In parallel, the following CLI command was issued repeatdly without any delay to force multiple update on servers port : set server <srv> addr 0.0.0.0 port $((1024 + RANDOM % 1024)) This must be backported at least up to 3.0. If above mentionned patch has been selected for previous version, this commit must also be backported on them.
2024-07-02 12:14:57 -04:00
/*
* this requires thread isolation, which is safe since we're the only
* task working for the current subscription and we don't hold locks
* or resources that other threads may depend on to complete a running
* cycle. Note that we do this way because we assume that this event is
* rather rare.
*/
if (!thread_isolated())
thread_isolate_full();
BUG/MAJOR: server/addr: fix a race during server addr:svc_port updates For inet families (IP4/IP6), it is expected that server's addr/port might be updated at runtime from DNS, cli or lua for instance. Such updates were performed under the server's lock. Unfortunately, most readers such as backend.c or sink.c perform the read without taking server's lock because they can't afford slowing down their processing for a type of event which is normally rare. But this could result in bad values being read for the server addr:svc_port tuple (ie: during connection etablishment) as a result of concurrent updates from external components, which can obviously cause some undesirable effects. Instead of slowing the readers down, as we consider server's addr changes are relatively rare, we take another approach and try to update the addr:port atomically by performing changes under full thread isolation when a new change is requested. The changes are performed by a dedicated task which takes care of isolating the current thread and doesn't depend on other threads (independent code path) to protect against dead locks. As such, server's addr:port changes will now be performed atomically, but they will not be processed instantly, they will be translated to events that the dedicated task will pick up from time to time to apply the pending changes. This bug existed for a very long time and has never been reported so far. It was discovered by reading the code during the implementation of log backend ("mode log" in backends). As it involves changes in sensitive areas as well as thread isolation, it is probably not worth considering backporting it for now, unless it is proven that it will help to solve bugs that are actually encountered in the field. This patch depends on: - 24da4d3 ("MINOR: tools: use const for read only pointers in ip{cmp,cpy}") - c886fb5 ("MINOR: server/ip: centralize server ip updates") - event_hdl API (which was first seen on 2.8) + 683b2ae ("MINOR: server/event_hdl: add SERVER_INETADDR event") + BUG/MEDIUM: server/event_hdl: memory overrun in _srv_event_hdl_prepare_inetaddr() + "MINOR: event_hdl: add global tunables" Note that the patch may be reworked so that it doesn't depend on event_hdl API for older versions, the approach would remain the same: this would result in a larger patch due to the need to manually implement a global queue of pending updates with its dedicated task responsible for picking updates and comitting them. An alternative approach could consist in per-server, lock-protected, temporary addr:svc_port storage dedicated to "updaters" were only the most recent values would be kept. The sync task would then use them as source values to atomically update the addr:svc_port members that the runtime readers are actually using.
2023-11-13 12:14:24 -05:00
/* check if related server still exists */
px = proxy_find_by_id(data->server.safe.proxy_uuid, PR_CAP_BE, 0);
if (!px)
continue;
OPTIM: server: ebtree lookups for findserver_unique_* functions 4e5e2664 ("MINOR: proxy: add findserver_unique_id() and findserver_unique_name()") added findserver_unique_id() and findserver_unique_name() functions that were inspired from the historical findserver() function, so unfortunately they don't perform well when used on large backend farms because they scan the whole server list linearly. I was about to provide a patch to optimize such functions when I stumbled on Baptiste's work: 19a106d24 ("MINOR: server: server_find functions: id, name, best_match") It turns out Baptiste already implemented helper functions to supersed the unoptimized findserver() function (at least at runtime when servers have been assigned their final IDs and inserted in the lookup trees): they offer more matching options and rely on eb lookups so they are much more suitable for fast queries. I don't know how I missed that, but they are a perfect base for the server rid matching functions. So in this patch, we essentially revert 4e5e2664 to provide the optimized equivalent functions named server_find_by_id_unique() and server_find_by_name_unique(), then we force existing findserver_unique_*() callers to switch to the new functions. This patch depends on: - "OPTIM: server: eb lookup for server_find_by_name()" This could be backported up to 2.8.
2023-12-04 11:00:18 -05:00
srv = server_find_by_id_unique(px, data->server.safe.puid, data->server.safe.rid);
BUG/MAJOR: server/addr: fix a race during server addr:svc_port updates For inet families (IP4/IP6), it is expected that server's addr/port might be updated at runtime from DNS, cli or lua for instance. Such updates were performed under the server's lock. Unfortunately, most readers such as backend.c or sink.c perform the read without taking server's lock because they can't afford slowing down their processing for a type of event which is normally rare. But this could result in bad values being read for the server addr:svc_port tuple (ie: during connection etablishment) as a result of concurrent updates from external components, which can obviously cause some undesirable effects. Instead of slowing the readers down, as we consider server's addr changes are relatively rare, we take another approach and try to update the addr:port atomically by performing changes under full thread isolation when a new change is requested. The changes are performed by a dedicated task which takes care of isolating the current thread and doesn't depend on other threads (independent code path) to protect against dead locks. As such, server's addr:port changes will now be performed atomically, but they will not be processed instantly, they will be translated to events that the dedicated task will pick up from time to time to apply the pending changes. This bug existed for a very long time and has never been reported so far. It was discovered by reading the code during the implementation of log backend ("mode log" in backends). As it involves changes in sensitive areas as well as thread isolation, it is probably not worth considering backporting it for now, unless it is proven that it will help to solve bugs that are actually encountered in the field. This patch depends on: - 24da4d3 ("MINOR: tools: use const for read only pointers in ip{cmp,cpy}") - c886fb5 ("MINOR: server/ip: centralize server ip updates") - event_hdl API (which was first seen on 2.8) + 683b2ae ("MINOR: server/event_hdl: add SERVER_INETADDR event") + BUG/MEDIUM: server/event_hdl: memory overrun in _srv_event_hdl_prepare_inetaddr() + "MINOR: event_hdl: add global tunables" Note that the patch may be reworked so that it doesn't depend on event_hdl API for older versions, the approach would remain the same: this would result in a larger patch due to the need to manually implement a global queue of pending updates with its dedicated task responsible for picking updates and comitting them. An alternative approach could consist in per-server, lock-protected, temporary addr:svc_port storage dedicated to "updaters" were only the most recent values would be kept. The sync task would then use them as source values to atomically update the addr:svc_port members that the runtime readers are actually using.
2023-11-13 12:14:24 -05:00
if (!srv)
continue;
/* prepare new addr based on event cb data */
memset(&new_addr, 0, sizeof(new_addr));
new_addr.ss_family = data->safe.next.family;
switch (new_addr.ss_family) {
case AF_INET:
((struct sockaddr_in *)&new_addr)->sin_addr.s_addr =
data->safe.next.addr.v4.s_addr;
break;
case AF_INET6:
memcpy(&((struct sockaddr_in6 *)&new_addr)->sin6_addr,
&data->safe.next.addr.v6,
sizeof(struct in6_addr));
break;
BUG/MINOR: server/event_hdl: properly handle AF_UNSPEC for INETADDR event It is possible that a server's addr family is temporarily set to AF_UNSPEC even if we're certain to be in INET context (ipv4, ipv6). Indeed, as soon as IP address resolving is involved, srv->addr family will be set to AF_UNSPEC when the resolution fails (could happen at anytime). However, _srv_event_hdl_prepare_inetaddr() wrongly assumed that it would only be called with AF_INET or AF_INET6 families. Because of that, the function will handle AF_UNSPEC address as an IPV6 address: not only we could risk reading from an unititialized area, but we would then propagate false information when publishing the event. In this patch we make sure to properly handle the AF_UNSPEC family in both the "prev" and the "next" part for SERVER_INETADDR event and that every members are explicitly initialized. This bug was introduced by 6fde37e046 ("MINOR: server/event_hdl: add SERVER_INETADDR event"), no backport needed.
2023-12-01 11:41:40 -05:00
case AF_UNSPEC:
/* addr reset, nothing to do */
break;
BUG/MAJOR: server/addr: fix a race during server addr:svc_port updates For inet families (IP4/IP6), it is expected that server's addr/port might be updated at runtime from DNS, cli or lua for instance. Such updates were performed under the server's lock. Unfortunately, most readers such as backend.c or sink.c perform the read without taking server's lock because they can't afford slowing down their processing for a type of event which is normally rare. But this could result in bad values being read for the server addr:svc_port tuple (ie: during connection etablishment) as a result of concurrent updates from external components, which can obviously cause some undesirable effects. Instead of slowing the readers down, as we consider server's addr changes are relatively rare, we take another approach and try to update the addr:port atomically by performing changes under full thread isolation when a new change is requested. The changes are performed by a dedicated task which takes care of isolating the current thread and doesn't depend on other threads (independent code path) to protect against dead locks. As such, server's addr:port changes will now be performed atomically, but they will not be processed instantly, they will be translated to events that the dedicated task will pick up from time to time to apply the pending changes. This bug existed for a very long time and has never been reported so far. It was discovered by reading the code during the implementation of log backend ("mode log" in backends). As it involves changes in sensitive areas as well as thread isolation, it is probably not worth considering backporting it for now, unless it is proven that it will help to solve bugs that are actually encountered in the field. This patch depends on: - 24da4d3 ("MINOR: tools: use const for read only pointers in ip{cmp,cpy}") - c886fb5 ("MINOR: server/ip: centralize server ip updates") - event_hdl API (which was first seen on 2.8) + 683b2ae ("MINOR: server/event_hdl: add SERVER_INETADDR event") + BUG/MEDIUM: server/event_hdl: memory overrun in _srv_event_hdl_prepare_inetaddr() + "MINOR: event_hdl: add global tunables" Note that the patch may be reworked so that it doesn't depend on event_hdl API for older versions, the approach would remain the same: this would result in a larger patch due to the need to manually implement a global queue of pending updates with its dedicated task responsible for picking updates and comitting them. An alternative approach could consist in per-server, lock-protected, temporary addr:svc_port storage dedicated to "updaters" were only the most recent values would be kept. The sync task would then use them as source values to atomically update the addr:svc_port members that the runtime readers are actually using.
2023-11-13 12:14:24 -05:00
default:
/* should not happen */
break;
}
/* apply new addr:port combination */
BUG/MINOR: server/event_hdl: propagate map port info through inetaddr event server addr:svc_port updates during runtime might set or clear the SRV_F_MAPPORTS flag. Unfortunately, the flag update is still directly performed by srv_update_addr_port() function while the addr:svc_port update is being scheduled for atomic update. Given that existing readers don't take server's lock to read addr:svc_port, they also check the SRV_F_MAPPORTS flag right after without the lock. So we could cause the readers to incorrectly interpret the svc_port from the server struct because the mapport information is not published atomically, resulting in inconsistencies between svc_port / mapport flag. (MAPPORTS flag causes svc_port to be used differently by the reader) To fix this, we publish the mapport information within the INETADDR server event and we let the task responsible for updating server's addr and port position or clear the flag depending on the mapport hint. This patch depends on: - MINOR: server/event_hdl: add server_inetaddr struct to facilitate event data usage - MINOR: server/event_hdl: update _srv_event_hdl_prepare_inetaddr prototype This should be backported in 2.9 with 683b2ae01 ("MINOR: server/event_hdl: add SERVER_INETADDR event")
2023-12-07 11:08:08 -05:00
_srv_set_inetaddr_port(srv, &new_addr,
data->safe.next.port.svc, data->safe.next.port.map);
BUG/MAJOR: server/addr: fix a race during server addr:svc_port updates For inet families (IP4/IP6), it is expected that server's addr/port might be updated at runtime from DNS, cli or lua for instance. Such updates were performed under the server's lock. Unfortunately, most readers such as backend.c or sink.c perform the read without taking server's lock because they can't afford slowing down their processing for a type of event which is normally rare. But this could result in bad values being read for the server addr:svc_port tuple (ie: during connection etablishment) as a result of concurrent updates from external components, which can obviously cause some undesirable effects. Instead of slowing the readers down, as we consider server's addr changes are relatively rare, we take another approach and try to update the addr:port atomically by performing changes under full thread isolation when a new change is requested. The changes are performed by a dedicated task which takes care of isolating the current thread and doesn't depend on other threads (independent code path) to protect against dead locks. As such, server's addr:port changes will now be performed atomically, but they will not be processed instantly, they will be translated to events that the dedicated task will pick up from time to time to apply the pending changes. This bug existed for a very long time and has never been reported so far. It was discovered by reading the code during the implementation of log backend ("mode log" in backends). As it involves changes in sensitive areas as well as thread isolation, it is probably not worth considering backporting it for now, unless it is proven that it will help to solve bugs that are actually encountered in the field. This patch depends on: - 24da4d3 ("MINOR: tools: use const for read only pointers in ip{cmp,cpy}") - c886fb5 ("MINOR: server/ip: centralize server ip updates") - event_hdl API (which was first seen on 2.8) + 683b2ae ("MINOR: server/event_hdl: add SERVER_INETADDR event") + BUG/MEDIUM: server/event_hdl: memory overrun in _srv_event_hdl_prepare_inetaddr() + "MINOR: event_hdl: add global tunables" Note that the patch may be reworked so that it doesn't depend on event_hdl API for older versions, the approach would remain the same: this would result in a larger patch due to the need to manually implement a global queue of pending updates with its dedicated task responsible for picking updates and comitting them. An alternative approach could consist in per-server, lock-protected, temporary addr:svc_port storage dedicated to "updaters" were only the most recent values would be kept. The sync task would then use them as source values to atomically update the addr:svc_port members that the runtime readers are actually using.
2023-11-13 12:14:24 -05:00
MINOR: server: ensure connection cleanup on server addr changes Previously, in srv_update_addr_port(), we forced connection cleanup on server changes. This was done in 6318d33ce ("BUG/MEDIUM: connections: force connections cleanup on server changes"). However, there is no reason we shouldn't have done the same in srv_update_addr() function, because the end goal is the same: perform runtime changes on server's address. The purge_conn hint propagated through the INETADDR server event was simply there to keep the original behavior (only purge the connection for events originating from srv_update_addr_port()), but to ensure the address change is handled the same way for both code paths, we simply ignore this hint.
2023-12-11 03:15:11 -05:00
/* propagate the changes, force connection cleanup */
MEDIUM: server/dns: clear RMAINT when addr resolves again snr_update_srv_status() and srvrq_update_srv_status() will both set or clear the server RMAINT state depending of the result of the current dns resolution. This used to work pretty well in the past, but now that addr:svc_port changes are changed atomically through a dedicated task, the change is performed asynchronously, so this can cause some flapping issues if the server is put out of maintenance while the server's address is still unassigned. To prevent errors, the resolver's code is now only allowed to put the server under maintenance but not to remove it from maintenance: the decision to remove a server from maintenance is performed by the task responsible for updating the server's addr: if the addr resolves again thanks to a valid DNS resolution and the server was previously under RMAINT, then it cleared from RMAINT state. srvrq_update_srv_status() was renamed srvrq_set_srv_down(), since it is only called to put the server in maintenance as a result of a failing SRV entry. snr_update_srv_status() was renamed srv_set_srv_down() and slightly modified so that it only takes care of putting the server under maintenance when needed. The cli command "set server x/y addr" does not need to remove the RMAINT flag anymore.
2023-12-12 08:42:34 -05:00
if (new_addr.ss_family != AF_UNSPEC &&
(srv->next_admin & SRV_ADMF_RMAINT)) {
/* server was previously put under DNS maintenance due
* to DNS error, but addr resolves again, so we must
* put it out of maintenance
*/
srv_clr_admin_flag(srv, SRV_ADMF_RMAINT);
/* thanks to valid DNS resolution? */
if (data->safe.updater.dns) {
chunk_reset(&trash);
chunk_printf(&trash, "Server %s/%s administratively READY thanks to valid DNS answer", srv->proxy->id, srv->id);
ha_warning("%s.\n", trash.area);
send_log(srv->proxy, LOG_NOTICE, "%s.\n", trash.area);
}
}
MINOR: server: ensure connection cleanup on server addr changes Previously, in srv_update_addr_port(), we forced connection cleanup on server changes. This was done in 6318d33ce ("BUG/MEDIUM: connections: force connections cleanup on server changes"). However, there is no reason we shouldn't have done the same in srv_update_addr() function, because the end goal is the same: perform runtime changes on server's address. The purge_conn hint propagated through the INETADDR server event was simply there to keep the original behavior (only purge the connection for events originating from srv_update_addr_port()), but to ensure the address change is handled the same way for both code paths, we simply ignore this hint.
2023-12-11 03:15:11 -05:00
srv_cleanup_connections(srv);
BUG/MAJOR: server/addr: fix a race during server addr:svc_port updates For inet families (IP4/IP6), it is expected that server's addr/port might be updated at runtime from DNS, cli or lua for instance. Such updates were performed under the server's lock. Unfortunately, most readers such as backend.c or sink.c perform the read without taking server's lock because they can't afford slowing down their processing for a type of event which is normally rare. But this could result in bad values being read for the server addr:svc_port tuple (ie: during connection etablishment) as a result of concurrent updates from external components, which can obviously cause some undesirable effects. Instead of slowing the readers down, as we consider server's addr changes are relatively rare, we take another approach and try to update the addr:port atomically by performing changes under full thread isolation when a new change is requested. The changes are performed by a dedicated task which takes care of isolating the current thread and doesn't depend on other threads (independent code path) to protect against dead locks. As such, server's addr:port changes will now be performed atomically, but they will not be processed instantly, they will be translated to events that the dedicated task will pick up from time to time to apply the pending changes. This bug existed for a very long time and has never been reported so far. It was discovered by reading the code during the implementation of log backend ("mode log" in backends). As it involves changes in sensitive areas as well as thread isolation, it is probably not worth considering backporting it for now, unless it is proven that it will help to solve bugs that are actually encountered in the field. This patch depends on: - 24da4d3 ("MINOR: tools: use const for read only pointers in ip{cmp,cpy}") - c886fb5 ("MINOR: server/ip: centralize server ip updates") - event_hdl API (which was first seen on 2.8) + 683b2ae ("MINOR: server/event_hdl: add SERVER_INETADDR event") + BUG/MEDIUM: server/event_hdl: memory overrun in _srv_event_hdl_prepare_inetaddr() + "MINOR: event_hdl: add global tunables" Note that the patch may be reworked so that it doesn't depend on event_hdl API for older versions, the approach would remain the same: this would result in a larger patch due to the need to manually implement a global queue of pending updates with its dedicated task responsible for picking updates and comitting them. An alternative approach could consist in per-server, lock-protected, temporary addr:svc_port storage dedicated to "updaters" were only the most recent values would be kept. The sync task would then use them as source values to atomically update the addr:svc_port members that the runtime readers are actually using.
2023-11-13 12:14:24 -05:00
srv_set_dyncookie(srv);
srv_set_addr_desc(srv, 1);
}
event_hdl_async_free_event(event);
MINOR: server: ensure max_events_at_once > 0 in server_atomic_sync() In 8f1fd96 ("BUG/MEDIUM: server/addr: fix tune.events.max-events-at-once event miss and leak"), we added a comment saying that tune.events.max-events-at-once is assumed to be strictly positive. It is so because the keyword parser forces values between 1 and 10000: we don't want less than 1 because it wouldn't make any sense, and 10k max because beyond that we could create contention in server_atomic_sync() Now as the above commit implements a do..while it heavily relies on the fact that the budget is at least 1. Upon soft-stop, we break away from the loop without decrementing the budget. With all that in mind, it is safe to assume that the 'remain' counter will only fall to 0 if the task runs out of budget while doing work, in which case the task still exists and must be rescheduled. As seen in GH #2667 this assumption was ambiguous, so let's make it official by adding a pair of BUG_ON() that make it explicit that it works because remain 'cannot' be 0 unless the entire budget was consumed. No backport needed.
2024-08-07 12:04:08 -04:00
} while (--remain);
BUG/MAJOR: server/addr: fix a race during server addr:svc_port updates For inet families (IP4/IP6), it is expected that server's addr/port might be updated at runtime from DNS, cli or lua for instance. Such updates were performed under the server's lock. Unfortunately, most readers such as backend.c or sink.c perform the read without taking server's lock because they can't afford slowing down their processing for a type of event which is normally rare. But this could result in bad values being read for the server addr:svc_port tuple (ie: during connection etablishment) as a result of concurrent updates from external components, which can obviously cause some undesirable effects. Instead of slowing the readers down, as we consider server's addr changes are relatively rare, we take another approach and try to update the addr:port atomically by performing changes under full thread isolation when a new change is requested. The changes are performed by a dedicated task which takes care of isolating the current thread and doesn't depend on other threads (independent code path) to protect against dead locks. As such, server's addr:port changes will now be performed atomically, but they will not be processed instantly, they will be translated to events that the dedicated task will pick up from time to time to apply the pending changes. This bug existed for a very long time and has never been reported so far. It was discovered by reading the code during the implementation of log backend ("mode log" in backends). As it involves changes in sensitive areas as well as thread isolation, it is probably not worth considering backporting it for now, unless it is proven that it will help to solve bugs that are actually encountered in the field. This patch depends on: - 24da4d3 ("MINOR: tools: use const for read only pointers in ip{cmp,cpy}") - c886fb5 ("MINOR: server/ip: centralize server ip updates") - event_hdl API (which was first seen on 2.8) + 683b2ae ("MINOR: server/event_hdl: add SERVER_INETADDR event") + BUG/MEDIUM: server/event_hdl: memory overrun in _srv_event_hdl_prepare_inetaddr() + "MINOR: event_hdl: add global tunables" Note that the patch may be reworked so that it doesn't depend on event_hdl API for older versions, the approach would remain the same: this would result in a larger patch due to the need to manually implement a global queue of pending updates with its dedicated task responsible for picking updates and comitting them. An alternative approach could consist in per-server, lock-protected, temporary addr:svc_port storage dedicated to "updaters" were only the most recent values would be kept. The sync task would then use them as source values to atomically update the addr:svc_port members that the runtime readers are actually using.
2023-11-13 12:14:24 -05:00
/* some events possibly required thread_isolation:
* now that we are done, we must leave thread isolation before
* returning
*/
if (thread_isolated())
thread_release();
BUG/MEDIUM: server/addr: fix tune.events.max-events-at-once event miss and leak An issue has been introduced with cd99440 ("BUG/MAJOR: server/addr: fix a race during server addr:svc_port updates"). Indeed, in the above commit we implemented the atomic_sync task which is responsible for consuming pending server events to apply the changes atomically. For now only server's addr updates are concerned. To prevent the task from causing contention, a budget was assigned to it. It can be controlled with the global tunable 'tune.events.max-events-at-once': the task may not process more than this number of events at once. However, a bug was introduced with this budget logic: each time the task has to be interrupted because it runs out of budget, we reschedule the task to finish where it left off, but the current event which was already removed from the queue wasn't processed yet. This means that this pending event (each tune.events.max-events-at-once) is effectively lost. When the atomic_sync task deals with large number of concurrent events, this bug has 2 known consequences: first a server's addr/port update will be lost every 'tune.events.max-events-at-once'. This can of course cause reliability issues because if the event is not republished periodically, the server could stay in a stale state for indefinite amount of time. This is the case when the DNS server flaps for instance: some servers may not come back UP after the incident as described in GH #2666. Another issue is that the lost event was not cleaned up, resulting in a small memory leak. So in the end, it means that the bug is likely to cause more and more degradation over time until haproxy is restarted. As a workaround, 'tune.events.max-events-at-once' may be set to the maximum number of events expected per batch. Note however that this value cannot exceed 10 000, otherwise it could cause the watchdog to trigger due to the task being busy for too long and preventing other threads from making any progress. Setting higher values may not be optimal for common workloads so it should only be used to mitigate the bug while waiting for this fix. Since tune.events.max-events-at-once defaults to 100, this bug only affects configs that involve more than 100 servers whose addr:port properties are likely to be updated at the same time (batched updates from cli, lua, dns..) To fix the bug, we move the budget check after the current event is fully handled. For that we went from a basic 'while' to 'do..while' loop as we assume from the config that 'tune.events.max-events-at-once' cannot be 0. While at it, we reschedule the task once thread isolation ends (it was not required to perform the reschedule while under isolation) to give the hand back faster to waiting threads. This patch should be backported up to 2.9 with cd99440. It should fix GH #2666.
2024-08-06 08:29:56 -04:00
if (!remain) {
/* we stopped because we've already spent all our budget here,
* and considering we possibly were under isolation, we cannot
* keep blocking other threads any longer.
*
* Reschedule the task to finish where we left off if
* there are remaining events in the queue.
*/
MINOR: server: ensure max_events_at_once > 0 in server_atomic_sync() In 8f1fd96 ("BUG/MEDIUM: server/addr: fix tune.events.max-events-at-once event miss and leak"), we added a comment saying that tune.events.max-events-at-once is assumed to be strictly positive. It is so because the keyword parser forces values between 1 and 10000: we don't want less than 1 because it wouldn't make any sense, and 10k max because beyond that we could create contention in server_atomic_sync() Now as the above commit implements a do..while it heavily relies on the fact that the budget is at least 1. Upon soft-stop, we break away from the loop without decrementing the budget. With all that in mind, it is safe to assume that the 'remain' counter will only fall to 0 if the task runs out of budget while doing work, in which case the task still exists and must be rescheduled. As seen in GH #2667 this assumption was ambiguous, so let's make it official by adding a pair of BUG_ON() that make it explicit that it works because remain 'cannot' be 0 unless the entire budget was consumed. No backport needed.
2024-08-07 12:04:08 -04:00
BUG_ON(task == NULL); // ending event doesn't decrement remain
BUG/MEDIUM: server/addr: fix tune.events.max-events-at-once event miss and leak An issue has been introduced with cd99440 ("BUG/MAJOR: server/addr: fix a race during server addr:svc_port updates"). Indeed, in the above commit we implemented the atomic_sync task which is responsible for consuming pending server events to apply the changes atomically. For now only server's addr updates are concerned. To prevent the task from causing contention, a budget was assigned to it. It can be controlled with the global tunable 'tune.events.max-events-at-once': the task may not process more than this number of events at once. However, a bug was introduced with this budget logic: each time the task has to be interrupted because it runs out of budget, we reschedule the task to finish where it left off, but the current event which was already removed from the queue wasn't processed yet. This means that this pending event (each tune.events.max-events-at-once) is effectively lost. When the atomic_sync task deals with large number of concurrent events, this bug has 2 known consequences: first a server's addr/port update will be lost every 'tune.events.max-events-at-once'. This can of course cause reliability issues because if the event is not republished periodically, the server could stay in a stale state for indefinite amount of time. This is the case when the DNS server flaps for instance: some servers may not come back UP after the incident as described in GH #2666. Another issue is that the lost event was not cleaned up, resulting in a small memory leak. So in the end, it means that the bug is likely to cause more and more degradation over time until haproxy is restarted. As a workaround, 'tune.events.max-events-at-once' may be set to the maximum number of events expected per batch. Note however that this value cannot exceed 10 000, otherwise it could cause the watchdog to trigger due to the task being busy for too long and preventing other threads from making any progress. Setting higher values may not be optimal for common workloads so it should only be used to mitigate the bug while waiting for this fix. Since tune.events.max-events-at-once defaults to 100, this bug only affects configs that involve more than 100 servers whose addr:port properties are likely to be updated at the same time (batched updates from cli, lua, dns..) To fix the bug, we move the budget check after the current event is fully handled. For that we went from a basic 'while' to 'do..while' loop as we assume from the config that 'tune.events.max-events-at-once' cannot be 0. While at it, we reschedule the task once thread isolation ends (it was not required to perform the reschedule while under isolation) to give the hand back faster to waiting threads. This patch should be backported up to 2.9 with cd99440. It should fix GH #2666.
2024-08-06 08:29:56 -04:00
if (!event_hdl_async_equeue_isempty(&server_atomic_sync_queue))
task_wakeup(task, TASK_WOKEN_OTHER);
}
BUG/MAJOR: server/addr: fix a race during server addr:svc_port updates For inet families (IP4/IP6), it is expected that server's addr/port might be updated at runtime from DNS, cli or lua for instance. Such updates were performed under the server's lock. Unfortunately, most readers such as backend.c or sink.c perform the read without taking server's lock because they can't afford slowing down their processing for a type of event which is normally rare. But this could result in bad values being read for the server addr:svc_port tuple (ie: during connection etablishment) as a result of concurrent updates from external components, which can obviously cause some undesirable effects. Instead of slowing the readers down, as we consider server's addr changes are relatively rare, we take another approach and try to update the addr:port atomically by performing changes under full thread isolation when a new change is requested. The changes are performed by a dedicated task which takes care of isolating the current thread and doesn't depend on other threads (independent code path) to protect against dead locks. As such, server's addr:port changes will now be performed atomically, but they will not be processed instantly, they will be translated to events that the dedicated task will pick up from time to time to apply the pending changes. This bug existed for a very long time and has never been reported so far. It was discovered by reading the code during the implementation of log backend ("mode log" in backends). As it involves changes in sensitive areas as well as thread isolation, it is probably not worth considering backporting it for now, unless it is proven that it will help to solve bugs that are actually encountered in the field. This patch depends on: - 24da4d3 ("MINOR: tools: use const for read only pointers in ip{cmp,cpy}") - c886fb5 ("MINOR: server/ip: centralize server ip updates") - event_hdl API (which was first seen on 2.8) + 683b2ae ("MINOR: server/event_hdl: add SERVER_INETADDR event") + BUG/MEDIUM: server/event_hdl: memory overrun in _srv_event_hdl_prepare_inetaddr() + "MINOR: event_hdl: add global tunables" Note that the patch may be reworked so that it doesn't depend on event_hdl API for older versions, the approach would remain the same: this would result in a larger patch due to the need to manually implement a global queue of pending updates with its dedicated task responsible for picking updates and comitting them. An alternative approach could consist in per-server, lock-protected, temporary addr:svc_port storage dedicated to "updaters" were only the most recent values would be kept. The sync task would then use them as source values to atomically update the addr:svc_port members that the runtime readers are actually using.
2023-11-13 12:14:24 -05:00
return task;
}
/* Try to start the atomic server sync task.
*
* Returns ERR_NONE on success and a combination of ERR_CODE on failure
*/
static int server_atomic_sync_start()
{
struct event_hdl_sub_type subscriptions = EVENT_HDL_SUB_NONE;
if (server_atomic_sync_task)
return ERR_NONE; // nothing to do
server_atomic_sync_task = task_new_anywhere();
if (!server_atomic_sync_task)
goto fail;
server_atomic_sync_task->process = server_atomic_sync;
event_hdl_async_equeue_init(&server_atomic_sync_queue);
/* task created, now subscribe to relevant server events in the global list */
subscriptions = event_hdl_sub_type_add(subscriptions, EVENT_HDL_SUB_SERVER_INETADDR);
if (!event_hdl_subscribe(NULL, subscriptions,
EVENT_HDL_ASYNC_TASK(&server_atomic_sync_queue,
server_atomic_sync_task,
NULL,
NULL)))
goto fail;
return ERR_NONE;
fail:
task_destroy(server_atomic_sync_task);
server_atomic_sync_task = NULL;
return ERR_ALERT | ERR_FATAL;
}
REGISTER_POST_CHECK(server_atomic_sync_start);
MINOR: server/event_hdl: prepare for server event data wrapper Adding the possibility to publish an event using a struct wrapper around existing SERVER events to provide additional contextual info. Using the specific struct wrapper is not required: it is supported to cast event data as a regular server event data struct so that we don't break the existing API. However, casting event data with a more explicit data type allows to fetch event-only relevant hints.
2023-03-24 12:02:53 -04:00
/* fill common server event data members struct
* must be called with server lock or under thread isolate
*/
static inline void _srv_event_hdl_prepare(struct event_hdl_cb_data_server *cb_data,
struct server *srv, uint8_t thread_isolate)
{
/* safe data assignments */
cb_data->safe.puid = srv->puid;
cb_data->safe.rid = srv->rid;
cb_data->safe.flags = srv->flags;
snprintf(cb_data->safe.name, sizeof(cb_data->safe.name), "%s", srv->id);
cb_data->safe.proxy_name[0] = '\0';
cb_data->safe.proxy_uuid = -1; /* default value */
if (srv->proxy) {
cb_data->safe.proxy_uuid = srv->proxy->uuid;
snprintf(cb_data->safe.proxy_name, sizeof(cb_data->safe.proxy_name), "%s", srv->proxy->id);
}
/* unsafe data assignments */
cb_data->unsafe.ptr = srv;
cb_data->unsafe.thread_isolate = thread_isolate;
cb_data->unsafe.srv_lock = !thread_isolate;
}
MINOR: server/event_hdl: add SERVER_STATE event Adding a new SERVER event in the event_hdl API. SERVER_STATE is implemented as an advanced server event. It is published each time the server's effective state changes. (when s->cur_state changes) SERVER_STATE data is an event_hdl_cb_data_server_state struct that provides additional info related to the server state change, but can be casted as a regular event_hdl_cb_data_server struct if additional info is not needed.
2023-04-04 15:28:07 -04:00
/* take an event-check snapshot from a live check */
void _srv_event_hdl_prepare_checkres(struct event_hdl_cb_data_server_checkres *checkres,
struct check *check)
{
checkres->agent = !!(check->state & CHK_ST_AGENT);
checkres->result = check->result;
checkres->duration = check->duration;
checkres->reason.status = check->status;
checkres->reason.code = check->code;
checkres->health.cur = check->health;
checkres->health.rise = check->rise;
checkres->health.fall = check->fall;
}
/* Prepare SERVER_STATE event
*
* This special event will contain extra hints related to the state change
*
* Must be called with server lock held
*/
void _srv_event_hdl_prepare_state(struct event_hdl_cb_data_server_state *cb_data,
struct server *srv, int type, int cause,
enum srv_state prev_state, int requeued)
{
/* state event provides additional info about the server state change */
cb_data->safe.type = type;
cb_data->safe.new_state = srv->cur_state;
cb_data->safe.old_state = prev_state;
cb_data->safe.requeued = requeued;
if (type) {
/* administrative */
cb_data->safe.adm_st_chg.cause = cause;
}
else {
/* operational */
cb_data->safe.op_st_chg.cause = cause;
if (cause == SRV_OP_STCHGC_HEALTH || cause == SRV_OP_STCHGC_AGENT) {
struct check *check = (cause == SRV_OP_STCHGC_HEALTH) ? &srv->check : &srv->agent;
/* provide additional check-related state change result */
_srv_event_hdl_prepare_checkres(&cb_data->safe.op_st_chg.check, check);
}
}
}
MINOR: server/event_hdl: update _srv_event_hdl_prepare_inetaddr prototype Slightly change _srv_event_hdl_prepare_inetaddr() function prototype to reduce the input arguments by learning some settings directly from the server. Also taking this opportunity to make the function static inline since it's relatively simple and not meant to be used directly.
2023-12-07 10:39:32 -05:00
/* Prepare SERVER_INETADDR event, prev data is learned from the current
* server settings.
MINOR: server/event_hdl: add SERVER_INETADDR event In this patch we add the support for a new SERVER event in the event_hdl API. SERVER_INETADDR is implemented as an advanced server event. It is published each time the server's ip address or port is about to change. (ie: from the cli, dns, lua...) SERVER_INETADDR data is an event_hdl_cb_data_server_inetaddr struct that provides additional info related to the server inet addr change, but can be casted as a regular event_hdl_cb_data_server struct if additional info is not needed.
2023-11-10 14:12:00 -05:00
*
* This special event will contain extra hints related to the addr change
*
MINOR: server/event_hdl: update _srv_event_hdl_prepare_inetaddr prototype Slightly change _srv_event_hdl_prepare_inetaddr() function prototype to reduce the input arguments by learning some settings directly from the server. Also taking this opportunity to make the function static inline since it's relatively simple and not meant to be used directly.
2023-12-07 10:39:32 -05:00
* Must be called with the server lock held.
MINOR: server/event_hdl: add SERVER_INETADDR event In this patch we add the support for a new SERVER event in the event_hdl API. SERVER_INETADDR is implemented as an advanced server event. It is published each time the server's ip address or port is about to change. (ie: from the cli, dns, lua...) SERVER_INETADDR data is an event_hdl_cb_data_server_inetaddr struct that provides additional info related to the server inet addr change, but can be casted as a regular event_hdl_cb_data_server struct if additional info is not needed.
2023-11-10 14:12:00 -05:00
*/
MINOR: server/event_hdl: update _srv_event_hdl_prepare_inetaddr prototype Slightly change _srv_event_hdl_prepare_inetaddr() function prototype to reduce the input arguments by learning some settings directly from the server. Also taking this opportunity to make the function static inline since it's relatively simple and not meant to be used directly.
2023-12-07 10:39:32 -05:00
static void _srv_event_hdl_prepare_inetaddr(struct event_hdl_cb_data_server_inetaddr *cb_data,
struct server *srv,
MINOR: server/event_hdl: expose updater info through INETADDR event Thanks to the previous commit, we can now expose updater info through INETADDR event.
2023-12-11 11:14:24 -05:00
const struct server_inetaddr *next_inetaddr,
struct server_inetaddr_updater updater)
MINOR: server/event_hdl: add SERVER_INETADDR event In this patch we add the support for a new SERVER event in the event_hdl API. SERVER_INETADDR is implemented as an advanced server event. It is published each time the server's ip address or port is about to change. (ie: from the cli, dns, lua...) SERVER_INETADDR data is an event_hdl_cb_data_server_inetaddr struct that provides additional info related to the server inet addr change, but can be casted as a regular event_hdl_cb_data_server struct if additional info is not needed.
2023-11-10 14:12:00 -05:00
{
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
struct server_inetaddr prev_inetaddr;
server_get_inetaddr(srv, &prev_inetaddr);
MINOR: server/event_hdl: update _srv_event_hdl_prepare_inetaddr prototype Slightly change _srv_event_hdl_prepare_inetaddr() function prototype to reduce the input arguments by learning some settings directly from the server. Also taking this opportunity to make the function static inline since it's relatively simple and not meant to be used directly.
2023-12-07 10:39:32 -05:00
MINOR: server/event_hdl: add SERVER_INETADDR event In this patch we add the support for a new SERVER event in the event_hdl API. SERVER_INETADDR is implemented as an advanced server event. It is published each time the server's ip address or port is about to change. (ie: from the cli, dns, lua...) SERVER_INETADDR data is an event_hdl_cb_data_server_inetaddr struct that provides additional info related to the server inet addr change, but can be casted as a regular event_hdl_cb_data_server struct if additional info is not needed.
2023-11-10 14:12:00 -05:00
/* only INET families are supported */
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
BUG_ON((next_inetaddr->family != AF_UNSPEC &&
next_inetaddr->family != AF_INET && next_inetaddr->family != AF_INET6));
MINOR: server/event_hdl: add SERVER_INETADDR event In this patch we add the support for a new SERVER event in the event_hdl API. SERVER_INETADDR is implemented as an advanced server event. It is published each time the server's ip address or port is about to change. (ie: from the cli, dns, lua...) SERVER_INETADDR data is an event_hdl_cb_data_server_inetaddr struct that provides additional info related to the server inet addr change, but can be casted as a regular event_hdl_cb_data_server struct if additional info is not needed.
2023-11-10 14:12:00 -05:00
/* prev */
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
cb_data->safe.prev = prev_inetaddr;
MINOR: server/event_hdl: add SERVER_INETADDR event In this patch we add the support for a new SERVER event in the event_hdl API. SERVER_INETADDR is implemented as an advanced server event. It is published each time the server's ip address or port is about to change. (ie: from the cli, dns, lua...) SERVER_INETADDR data is an event_hdl_cb_data_server_inetaddr struct that provides additional info related to the server inet addr change, but can be casted as a regular event_hdl_cb_data_server struct if additional info is not needed.
2023-11-10 14:12:00 -05:00
/* next */
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
cb_data->safe.next = *next_inetaddr;
MINOR: server/event_hdl: expose updater info through INETADDR event Thanks to the previous commit, we can now expose updater info through INETADDR event.
2023-12-11 11:14:24 -05:00
/* updater */
cb_data->safe.updater = updater;
MINOR: server/event_hdl: add SERVER_INETADDR event In this patch we add the support for a new SERVER event in the event_hdl API. SERVER_INETADDR is implemented as an advanced server event. It is published each time the server's ip address or port is about to change. (ie: from the cli, dns, lua...) SERVER_INETADDR data is an event_hdl_cb_data_server_inetaddr struct that provides additional info related to the server inet addr change, but can be casted as a regular event_hdl_cb_data_server struct if additional info is not needed.
2023-11-10 14:12:00 -05:00
}
MINOR: server/event_hdl: publish macro helper add a macro helper to help publish server events to global and per-server subscription list at once since all server events support both subscription modes.
2023-04-25 04:44:41 -04:00
/* server event publishing helper: publish in both global and
* server dedicated subscription list.
*/
#define _srv_event_hdl_publish(e, d, s) \
({ \
/* publish in server dedicated sub list */ \
event_hdl_publish(&s->e_subs, e, EVENT_HDL_CB_DATA(&d));\
/* publish in global subscription list */ \
event_hdl_publish(NULL, e, EVENT_HDL_CB_DATA(&d)); \
})
/* General server event publishing:
MINOR: server/event_hdl: add support for SERVER_ADD and SERVER_DEL events Basic support for ADD and DEL server events are added through this commit: SERVER_ADD is published on dynamic server addition through cli. SERVER_DEL is published on dynamic server deletion through cli. This work depends on: "MINOR: event_hdl: add event handler base api" "MINOR: server: add srv->rid (revision id) value"
2022-11-17 04:37:58 -05:00
* Use this to publish EVENT_HDL_SUB_SERVER family type event
MINOR: server/event_hdl: publish macro helper add a macro helper to help publish server events to global and per-server subscription list at once since all server events support both subscription modes.
2023-04-25 04:44:41 -04:00
* from srv facility.
*
* server ptr must be valid.
* Must be called with srv lock or under thread_isolate.
MINOR: server/event_hdl: add support for SERVER_ADD and SERVER_DEL events Basic support for ADD and DEL server events are added through this commit: SERVER_ADD is published on dynamic server addition through cli. SERVER_DEL is published on dynamic server deletion through cli. This work depends on: "MINOR: event_hdl: add event handler base api" "MINOR: server: add srv->rid (revision id) value"
2022-11-17 04:37:58 -05:00
*/
MINOR: server/event_hdl: prepare for server event data wrapper Adding the possibility to publish an event using a struct wrapper around existing SERVER events to provide additional contextual info. Using the specific struct wrapper is not required: it is supported to cast event data as a regular server event data struct so that we don't break the existing API. However, casting event data with a more explicit data type allows to fetch event-only relevant hints.
2023-03-24 12:02:53 -04:00
static void srv_event_hdl_publish(struct event_hdl_sub_type event,
struct server *srv, uint8_t thread_isolate)
MINOR: server/event_hdl: add support for SERVER_ADD and SERVER_DEL events Basic support for ADD and DEL server events are added through this commit: SERVER_ADD is published on dynamic server addition through cli. SERVER_DEL is published on dynamic server deletion through cli. This work depends on: "MINOR: event_hdl: add event handler base api" "MINOR: server: add srv->rid (revision id) value"
2022-11-17 04:37:58 -05:00
{
struct event_hdl_cb_data_server cb_data;
MINOR: server/event_hdl: prepare for server event data wrapper Adding the possibility to publish an event using a struct wrapper around existing SERVER events to provide additional contextual info. Using the specific struct wrapper is not required: it is supported to cast event data as a regular server event data struct so that we don't break the existing API. However, casting event data with a more explicit data type allows to fetch event-only relevant hints.
2023-03-24 12:02:53 -04:00
/* prepare event data */
_srv_event_hdl_prepare(&cb_data, srv, thread_isolate);
MINOR: server/event_hdl: publish macro helper add a macro helper to help publish server events to global and per-server subscription list at once since all server events support both subscription modes.
2023-04-25 04:44:41 -04:00
_srv_event_hdl_publish(event, cb_data, srv);
MINOR: server/event_hdl: add support for SERVER_ADD and SERVER_DEL events Basic support for ADD and DEL server events are added through this commit: SERVER_ADD is published on dynamic server addition through cli. SERVER_DEL is published on dynamic server deletion through cli. This work depends on: "MINOR: event_hdl: add event handler base api" "MINOR: server: add srv->rid (revision id) value"
2022-11-17 04:37:58 -05:00
}
MINOR: checks/event_hdl: SERVER_CHECK event Adding a new event type: SERVER_CHECK. This event is published when a server's check state ought to be reported. (check status change or check result) SERVER_CHECK event is provided as a server event with additional data carrying relevant check's context such as check's result and health.
2023-03-30 04:19:08 -04:00
/* Publish SERVER_CHECK event
*
* This special event will contain extra hints related to the check itself
*
* Must be called with server lock held
*/
void srv_event_hdl_publish_check(struct server *srv, struct check *check)
{
struct event_hdl_cb_data_server_check cb_data;
/* check event provides additional info about the server check */
_srv_event_hdl_prepare_checkres(&cb_data.safe.res, check);
cb_data.unsafe.ptr = check;
/* prepare event data (common server data) */
_srv_event_hdl_prepare((struct event_hdl_cb_data_server *)&cb_data, srv, 0);
_srv_event_hdl_publish(EVENT_HDL_SUB_SERVER_CHECK, cb_data, srv);
}
MINOR: servers: Don't report duplicate dyncookies for disabled servers. Especially with server-templates, it can happen servers starts with a placeholder IP, in the disabled state. In this case, we don't want to report that the same cookie was generated for multiple servers. So defer the test until the server is enabled. This should be backported to 1.8.
2018-01-17 11:39:34 -05:00
/*
* Check that we did not get a hash collision.
MINOR: server: read-lock the cookie during srv_set_dyncookie() No need to use an exclusive lock on the proxy anymore when reading its setting, a read lock is enough. A few other places continue to use a write-lock when modifying simple flags only in order to let this function see a consistent value all along. This might be changed in the future using barriers and local copies.
2020-10-20 11:30:08 -04:00
* Unlikely, but it can happen. The server's proxy must be at least
* read-locked.
MINOR: servers: Don't report duplicate dyncookies for disabled servers. Especially with server-templates, it can happen servers starts with a placeholder IP, in the disabled state. In this case, we don't want to report that the same cookie was generated for multiple servers. So defer the test until the server is enabled. This should be backported to 1.8.
2018-01-17 11:39:34 -05:00
*/
static inline void srv_check_for_dup_dyncookie(struct server *s)
MINOR: server: Add dynamic session cookies. This adds a new "dynamic" keyword for the cookie option. If set, a cookie will be generated for each server (assuming one isn't already provided on the "server" line), from the IP of the server, the TCP port, and a secret key provided. To provide the secret key, a new keyword as been added, "dynamic-cookie-key", for backends. Example : backend bk_web balance roundrobin dynamic-cookie-key "bla" cookie WEBSRV insert dynamic server s1 127.0.0.1:80 check server s2 192.168.56.1:80 check This is a first step to be able to dynamically add and remove servers, without modifying the configuration file, and still have all the load balancers redirect the traffic to the right server. Provide a way to generate session cookies, based on the IP address of the server, the TCP port, and a secret key provided.
2017-03-14 15:01:29 -04:00
{
struct proxy *p = s->proxy;
struct server *tmpserv;
MINOR: servers: Don't report duplicate dyncookies for disabled servers. Especially with server-templates, it can happen servers starts with a placeholder IP, in the disabled state. In this case, we don't want to report that the same cookie was generated for multiple servers. So defer the test until the server is enabled. This should be backported to 1.8.
2018-01-17 11:39:34 -05:00
for (tmpserv = p->srv; tmpserv != NULL;
tmpserv = tmpserv->next) {
if (tmpserv == s)
continue;
if (tmpserv->next_admin & SRV_ADMF_FMAINT)
continue;
if (tmpserv->cookie &&
strcmp(tmpserv->cookie, s->cookie) == 0) {
ha_warning("We generated two equal cookies for two different servers.\n"
"Please change the secret key for '%s'.\n",
s->proxy->id);
}
}
}
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
/*
MINOR: server: read-lock the cookie during srv_set_dyncookie() No need to use an exclusive lock on the proxy anymore when reading its setting, a read lock is enough. A few other places continue to use a write-lock when modifying simple flags only in order to let this function see a consistent value all along. This might be changed in the future using barriers and local copies.
2020-10-20 11:30:08 -04:00
* Must be called with the server lock held, and will read-lock the proxy.
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
*/
MINOR: servers: Don't report duplicate dyncookies for disabled servers. Especially with server-templates, it can happen servers starts with a placeholder IP, in the disabled state. In this case, we don't want to report that the same cookie was generated for multiple servers. So defer the test until the server is enabled. This should be backported to 1.8.
2018-01-17 11:39:34 -05:00
void srv_set_dyncookie(struct server *s)
{
struct proxy *p = s->proxy;
MINOR: server: Add dynamic session cookies. This adds a new "dynamic" keyword for the cookie option. If set, a cookie will be generated for each server (assuming one isn't already provided on the "server" line), from the IP of the server, the TCP port, and a secret key provided. To provide the secret key, a new keyword as been added, "dynamic-cookie-key", for backends. Example : backend bk_web balance roundrobin dynamic-cookie-key "bla" cookie WEBSRV insert dynamic server s1 127.0.0.1:80 check server s2 192.168.56.1:80 check This is a first step to be able to dynamically add and remove servers, without modifying the configuration file, and still have all the load balancers redirect the traffic to the right server. Provide a way to generate session cookies, based on the IP address of the server, the TCP port, and a secret key provided.
2017-03-14 15:01:29 -04:00
char *tmpbuf;
unsigned long long hash_value;
BUG/MEDIUM server: Fix crash when dynamic is defined, but not key is provided. Wait until we're sure we have a key before trying to calculate its length. [wt: no backport needed, was just merged]
2017-03-15 10:11:06 -04:00
size_t key_len;
MINOR: server: Add dynamic session cookies. This adds a new "dynamic" keyword for the cookie option. If set, a cookie will be generated for each server (assuming one isn't already provided on the "server" line), from the IP of the server, the TCP port, and a secret key provided. To provide the secret key, a new keyword as been added, "dynamic-cookie-key", for backends. Example : backend bk_web balance roundrobin dynamic-cookie-key "bla" cookie WEBSRV insert dynamic server s1 127.0.0.1:80 check server s2 192.168.56.1:80 check This is a first step to be able to dynamically add and remove servers, without modifying the configuration file, and still have all the load balancers redirect the traffic to the right server. Provide a way to generate session cookies, based on the IP address of the server, the TCP port, and a secret key provided.
2017-03-14 15:01:29 -04:00
size_t buffer_len;
int addr_len;
int port;
MINOR: server: read-lock the cookie during srv_set_dyncookie() No need to use an exclusive lock on the proxy anymore when reading its setting, a read lock is enough. A few other places continue to use a write-lock when modifying simple flags only in order to let this function see a consistent value all along. This might be changed in the future using barriers and local copies.
2020-10-20 11:30:08 -04:00
HA_RWLOCK_RDLOCK(PROXY_LOCK, &p->lock);
BUG/MAJOR: queue/threads: avoid an AB/BA locking issue in process_srv_queue() A problem involving server slowstart was reported by @max2k1 in issue #197. The problem is that pendconn_grab_from_px() takes the proxy lock while already under the server's lock while process_srv_queue() first takes the proxy's lock then the server's lock. While the latter seems more natural, it is fundamentally incompatible with mayn other operations performed on servers, namely state change propagation, where the proxy is only known after the server and cannot be locked around the servers. Howwever reversing the lock in process_srv_queue() is trivial and only the few functions related to dynamic cookies need to be adjusted for this so that the proxy's lock is taken for each server operation. This is possible because the proxy's server list is built once at boot time and remains stable. So this is what this patch does. The comments in the proxy and server structs were updated to mention this rule that the server's lock may not be taken under the proxy's lock but may enclose it. Another approach could consist in using a second lock for the proxy's queue which would be different from the regular proxy's lock, but given that the operations above are rare and operate on small servers list, there is no reason for overdesigning a solution. This fix was successfully tested with 10000 servers in a backend where adjusting the dyncookies in loops over the CLI didn't have a measurable impact on the traffic. The only workaround without the fix is to disable any occurrence of "slowstart" on server lines, or to disable threads using "nbthread 1". This must be backported as far as 1.8.
2019-07-30 05:59:34 -04:00
MINOR: server: Add dynamic session cookies. This adds a new "dynamic" keyword for the cookie option. If set, a cookie will be generated for each server (assuming one isn't already provided on the "server" line), from the IP of the server, the TCP port, and a secret key provided. To provide the secret key, a new keyword as been added, "dynamic-cookie-key", for backends. Example : backend bk_web balance roundrobin dynamic-cookie-key "bla" cookie WEBSRV insert dynamic server s1 127.0.0.1:80 check server s2 192.168.56.1:80 check This is a first step to be able to dynamically add and remove servers, without modifying the configuration file, and still have all the load balancers redirect the traffic to the right server. Provide a way to generate session cookies, based on the IP address of the server, the TCP port, and a secret key provided.
2017-03-14 15:01:29 -04:00
if ((s->flags & SRV_F_COOKIESET) ||
!(s->proxy->ck_opts & PR_CK_DYNAMIC) ||
s->proxy->dyncookie_key == NULL)
BUG/MAJOR: queue/threads: avoid an AB/BA locking issue in process_srv_queue() A problem involving server slowstart was reported by @max2k1 in issue #197. The problem is that pendconn_grab_from_px() takes the proxy lock while already under the server's lock while process_srv_queue() first takes the proxy's lock then the server's lock. While the latter seems more natural, it is fundamentally incompatible with mayn other operations performed on servers, namely state change propagation, where the proxy is only known after the server and cannot be locked around the servers. Howwever reversing the lock in process_srv_queue() is trivial and only the few functions related to dynamic cookies need to be adjusted for this so that the proxy's lock is taken for each server operation. This is possible because the proxy's server list is built once at boot time and remains stable. So this is what this patch does. The comments in the proxy and server structs were updated to mention this rule that the server's lock may not be taken under the proxy's lock but may enclose it. Another approach could consist in using a second lock for the proxy's queue which would be different from the regular proxy's lock, but given that the operations above are rare and operate on small servers list, there is no reason for overdesigning a solution. This fix was successfully tested with 10000 servers in a backend where adjusting the dyncookies in loops over the CLI didn't have a measurable impact on the traffic. The only workaround without the fix is to disable any occurrence of "slowstart" on server lines, or to disable threads using "nbthread 1". This must be backported as far as 1.8.
2019-07-30 05:59:34 -04:00
goto out;
BUG/MEDIUM server: Fix crash when dynamic is defined, but not key is provided. Wait until we're sure we have a key before trying to calculate its length. [wt: no backport needed, was just merged]
2017-03-15 10:11:06 -04:00
key_len = strlen(p->dyncookie_key);
MINOR: server: Add dynamic session cookies. This adds a new "dynamic" keyword for the cookie option. If set, a cookie will be generated for each server (assuming one isn't already provided on the "server" line), from the IP of the server, the TCP port, and a secret key provided. To provide the secret key, a new keyword as been added, "dynamic-cookie-key", for backends. Example : backend bk_web balance roundrobin dynamic-cookie-key "bla" cookie WEBSRV insert dynamic server s1 127.0.0.1:80 check server s2 192.168.56.1:80 check This is a first step to be able to dynamically add and remove servers, without modifying the configuration file, and still have all the load balancers redirect the traffic to the right server. Provide a way to generate session cookies, based on the IP address of the server, the TCP port, and a secret key provided.
2017-03-14 15:01:29 -04:00
if (s->addr.ss_family != AF_INET &&
s->addr.ss_family != AF_INET6)
BUG/MAJOR: queue/threads: avoid an AB/BA locking issue in process_srv_queue() A problem involving server slowstart was reported by @max2k1 in issue #197. The problem is that pendconn_grab_from_px() takes the proxy lock while already under the server's lock while process_srv_queue() first takes the proxy's lock then the server's lock. While the latter seems more natural, it is fundamentally incompatible with mayn other operations performed on servers, namely state change propagation, where the proxy is only known after the server and cannot be locked around the servers. Howwever reversing the lock in process_srv_queue() is trivial and only the few functions related to dynamic cookies need to be adjusted for this so that the proxy's lock is taken for each server operation. This is possible because the proxy's server list is built once at boot time and remains stable. So this is what this patch does. The comments in the proxy and server structs were updated to mention this rule that the server's lock may not be taken under the proxy's lock but may enclose it. Another approach could consist in using a second lock for the proxy's queue which would be different from the regular proxy's lock, but given that the operations above are rare and operate on small servers list, there is no reason for overdesigning a solution. This fix was successfully tested with 10000 servers in a backend where adjusting the dyncookies in loops over the CLI didn't have a measurable impact on the traffic. The only workaround without the fix is to disable any occurrence of "slowstart" on server lines, or to disable threads using "nbthread 1". This must be backported as far as 1.8.
2019-07-30 05:59:34 -04:00
goto out;
MINOR: server: Add dynamic session cookies. This adds a new "dynamic" keyword for the cookie option. If set, a cookie will be generated for each server (assuming one isn't already provided on the "server" line), from the IP of the server, the TCP port, and a secret key provided. To provide the secret key, a new keyword as been added, "dynamic-cookie-key", for backends. Example : backend bk_web balance roundrobin dynamic-cookie-key "bla" cookie WEBSRV insert dynamic server s1 127.0.0.1:80 check server s2 192.168.56.1:80 check This is a first step to be able to dynamically add and remove servers, without modifying the configuration file, and still have all the load balancers redirect the traffic to the right server. Provide a way to generate session cookies, based on the IP address of the server, the TCP port, and a secret key provided.
2017-03-14 15:01:29 -04:00
/*
* Buffer to calculate the cookie value.
* The buffer contains the secret key + the server IP address
* + the TCP port.
*/
addr_len = (s->addr.ss_family == AF_INET) ? 4 : 16;
/*
* The TCP port should use only 2 bytes, but is stored in
* an unsigned int in struct server, so let's use 4, to be
* on the safe side.
*/
buffer_len = key_len + addr_len + 4;
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
tmpbuf = trash.area;
MINOR: server: Add dynamic session cookies. This adds a new "dynamic" keyword for the cookie option. If set, a cookie will be generated for each server (assuming one isn't already provided on the "server" line), from the IP of the server, the TCP port, and a secret key provided. To provide the secret key, a new keyword as been added, "dynamic-cookie-key", for backends. Example : backend bk_web balance roundrobin dynamic-cookie-key "bla" cookie WEBSRV insert dynamic server s1 127.0.0.1:80 check server s2 192.168.56.1:80 check This is a first step to be able to dynamically add and remove servers, without modifying the configuration file, and still have all the load balancers redirect the traffic to the right server. Provide a way to generate session cookies, based on the IP address of the server, the TCP port, and a secret key provided.
2017-03-14 15:01:29 -04:00
memcpy(tmpbuf, p->dyncookie_key, key_len);
memcpy(&(tmpbuf[key_len]),
s->addr.ss_family == AF_INET ?
(void *)&((struct sockaddr_in *)&s->addr)->sin_addr.s_addr :
(void *)&(((struct sockaddr_in6 *)&s->addr)->sin6_addr.s6_addr),
addr_len);
/*
* Make sure it's the same across all the load balancers,
* no matter their endianness.
*/
port = htonl(s->svc_port);
memcpy(&tmpbuf[key_len + addr_len], &port, 4);
hash_value = XXH64(tmpbuf, buffer_len, 0);
memprintf(&s->cookie, "%016llx", hash_value);
if (!s->cookie)
BUG/MAJOR: queue/threads: avoid an AB/BA locking issue in process_srv_queue() A problem involving server slowstart was reported by @max2k1 in issue #197. The problem is that pendconn_grab_from_px() takes the proxy lock while already under the server's lock while process_srv_queue() first takes the proxy's lock then the server's lock. While the latter seems more natural, it is fundamentally incompatible with mayn other operations performed on servers, namely state change propagation, where the proxy is only known after the server and cannot be locked around the servers. Howwever reversing the lock in process_srv_queue() is trivial and only the few functions related to dynamic cookies need to be adjusted for this so that the proxy's lock is taken for each server operation. This is possible because the proxy's server list is built once at boot time and remains stable. So this is what this patch does. The comments in the proxy and server structs were updated to mention this rule that the server's lock may not be taken under the proxy's lock but may enclose it. Another approach could consist in using a second lock for the proxy's queue which would be different from the regular proxy's lock, but given that the operations above are rare and operate on small servers list, there is no reason for overdesigning a solution. This fix was successfully tested with 10000 servers in a backend where adjusting the dyncookies in loops over the CLI didn't have a measurable impact on the traffic. The only workaround without the fix is to disable any occurrence of "slowstart" on server lines, or to disable threads using "nbthread 1". This must be backported as far as 1.8.
2019-07-30 05:59:34 -04:00
goto out;
MINOR: server: Add dynamic session cookies. This adds a new "dynamic" keyword for the cookie option. If set, a cookie will be generated for each server (assuming one isn't already provided on the "server" line), from the IP of the server, the TCP port, and a secret key provided. To provide the secret key, a new keyword as been added, "dynamic-cookie-key", for backends. Example : backend bk_web balance roundrobin dynamic-cookie-key "bla" cookie WEBSRV insert dynamic server s1 127.0.0.1:80 check server s2 192.168.56.1:80 check This is a first step to be able to dynamically add and remove servers, without modifying the configuration file, and still have all the load balancers redirect the traffic to the right server. Provide a way to generate session cookies, based on the IP address of the server, the TCP port, and a secret key provided.
2017-03-14 15:01:29 -04:00
s->cklen = 16;
MINOR: servers: Don't report duplicate dyncookies for disabled servers. Especially with server-templates, it can happen servers starts with a placeholder IP, in the disabled state. In this case, we don't want to report that the same cookie was generated for multiple servers. So defer the test until the server is enabled. This should be backported to 1.8.
2018-01-17 11:39:34 -05:00
/* Don't bother checking if the dyncookie is duplicated if
* the server is marked as "disabled", maybe it doesn't have
* its real IP yet, but just a place holder.
MINOR: server: Add dynamic session cookies. This adds a new "dynamic" keyword for the cookie option. If set, a cookie will be generated for each server (assuming one isn't already provided on the "server" line), from the IP of the server, the TCP port, and a secret key provided. To provide the secret key, a new keyword as been added, "dynamic-cookie-key", for backends. Example : backend bk_web balance roundrobin dynamic-cookie-key "bla" cookie WEBSRV insert dynamic server s1 127.0.0.1:80 check server s2 192.168.56.1:80 check This is a first step to be able to dynamically add and remove servers, without modifying the configuration file, and still have all the load balancers redirect the traffic to the right server. Provide a way to generate session cookies, based on the IP address of the server, the TCP port, and a secret key provided.
2017-03-14 15:01:29 -04:00
*/
MINOR: servers: Don't report duplicate dyncookies for disabled servers. Especially with server-templates, it can happen servers starts with a placeholder IP, in the disabled state. In this case, we don't want to report that the same cookie was generated for multiple servers. So defer the test until the server is enabled. This should be backported to 1.8.
2018-01-17 11:39:34 -05:00
if (!(s->next_admin & SRV_ADMF_FMAINT))
srv_check_for_dup_dyncookie(s);
BUG/MAJOR: queue/threads: avoid an AB/BA locking issue in process_srv_queue() A problem involving server slowstart was reported by @max2k1 in issue #197. The problem is that pendconn_grab_from_px() takes the proxy lock while already under the server's lock while process_srv_queue() first takes the proxy's lock then the server's lock. While the latter seems more natural, it is fundamentally incompatible with mayn other operations performed on servers, namely state change propagation, where the proxy is only known after the server and cannot be locked around the servers. Howwever reversing the lock in process_srv_queue() is trivial and only the few functions related to dynamic cookies need to be adjusted for this so that the proxy's lock is taken for each server operation. This is possible because the proxy's server list is built once at boot time and remains stable. So this is what this patch does. The comments in the proxy and server structs were updated to mention this rule that the server's lock may not be taken under the proxy's lock but may enclose it. Another approach could consist in using a second lock for the proxy's queue which would be different from the regular proxy's lock, but given that the operations above are rare and operate on small servers list, there is no reason for overdesigning a solution. This fix was successfully tested with 10000 servers in a backend where adjusting the dyncookies in loops over the CLI didn't have a measurable impact on the traffic. The only workaround without the fix is to disable any occurrence of "slowstart" on server lines, or to disable threads using "nbthread 1". This must be backported as far as 1.8.
2019-07-30 05:59:34 -04:00
out:
MINOR: server: read-lock the cookie during srv_set_dyncookie() No need to use an exclusive lock on the proxy anymore when reading its setting, a read lock is enough. A few other places continue to use a write-lock when modifying simple flags only in order to let this function see a consistent value all along. This might be changed in the future using barriers and local copies.
2020-10-20 11:30:08 -04:00
HA_RWLOCK_RDUNLOCK(PROXY_LOCK, &p->lock);
MINOR: server: Add dynamic session cookies. This adds a new "dynamic" keyword for the cookie option. If set, a cookie will be generated for each server (assuming one isn't already provided on the "server" line), from the IP of the server, the TCP port, and a secret key provided. To provide the secret key, a new keyword as been added, "dynamic-cookie-key", for backends. Example : backend bk_web balance roundrobin dynamic-cookie-key "bla" cookie WEBSRV insert dynamic server s1 127.0.0.1:80 check server s2 192.168.56.1:80 check This is a first step to be able to dynamically add and remove servers, without modifying the configuration file, and still have all the load balancers redirect the traffic to the right server. Provide a way to generate session cookies, based on the IP address of the server, the TCP port, and a secret key provided.
2017-03-14 15:01:29 -04:00
}
MEDIUM: server/backend: implement websocket protocol selection Handle properly websocket streams if the server uses an ALPN with both h1 and h2. Add a new field h2_ws in the server structure. If set to off, reuse is automatically disable on backend and ALPN is forced to http1.x if possible. Nothing is done if on. Implement a mechanism to be able to use a different http version for websocket streams. A new server member <ws> represents the algorithm to select the protocol. This can overrides the server <proto> configuration. If the connection uses ALPN for proto selection, it is updated for websocket streams to select the right protocol. Three mode of selection are implemented : - auto : use the same protocol between non-ws and ws streams. If ALPN is use, try to update it to "http/1.1"; this is only done if the server ALPN contains "http/1.1". - h1 : use http/1.1 - h2 : use http/2.0; this requires the server to support RFC8441 or an error will be returned by haproxy.
2021-10-18 08:39:57 -04:00
/* Returns true if it's possible to reuse an idle connection from server <srv>
* for a websocket stream. This is the case if server is configured to use the
* same protocol for both HTTP and websocket streams. This depends on the value
* of "proto", "alpn" and "ws" keywords.
*/
int srv_check_reuse_ws(struct server *srv)
{
if (srv->mux_proto || srv->use_ssl != 1 || !srv->ssl_ctx.alpn_str) {
/* explicit srv.mux_proto or no ALPN : srv.mux_proto is used
* for mux selection.
*/
const struct ist srv_mux = srv->mux_proto ?
srv->mux_proto->token : IST_NULL;
switch (srv->ws) {
/* "auto" means use the same protocol : reuse is possible. */
case SRV_WS_AUTO:
return 1;
/* "h2" means use h2 for websocket : reuse is possible if
* server mux is h2.
*/
case SRV_WS_H2:
if (srv->mux_proto && isteq(srv_mux, ist("h2")))
return 1;
break;
/* "h1" means use h1 for websocket : reuse is possible if
* server mux is h1.
*/
case SRV_WS_H1:
if (!srv->mux_proto || isteq(srv_mux, ist("h1")))
return 1;
break;
}
}
else {
/* ALPN selection.
* Based on the assumption that only "h2" and "http/1.1" token
* are used on server ALPN.
*/
const struct ist alpn = ist2(srv->ssl_ctx.alpn_str,
srv->ssl_ctx.alpn_len);
switch (srv->ws) {
case SRV_WS_AUTO:
/* for auto mode, consider reuse as possible if the
* server uses a single protocol ALPN
*/
if (!istchr(alpn, ','))
return 1;
break;
case SRV_WS_H2:
return isteq(alpn, ist("\x02h2"));
case SRV_WS_H1:
return isteq(alpn, ist("\x08http/1.1"));
}
}
return 0;
}
/* Return the proto to used for a websocket stream on <srv> without ALPN. NULL
* is a valid value indicating to use the fallback mux.
*/
const struct mux_ops *srv_get_ws_proto(struct server *srv)
{
const struct mux_proto_list *mux = NULL;
switch (srv->ws) {
case SRV_WS_AUTO:
mux = srv->mux_proto;
break;
case SRV_WS_H1:
mux = get_mux_proto(ist("h1"));
break;
case SRV_WS_H2:
mux = get_mux_proto(ist("h2"));
break;
}
return mux ? mux->mux : NULL;
}
MEDIUM: stick-tables: Add srvkey option to stick-table This allows using the address of the server rather than the name of the server for keeping track of servers in a backend for stickiness. The peers code was also extended to support feeding the dictionary using this key instead of the name. Fixes #814
2020-11-20 03:28:26 -05:00
/*
BUG/MEDIUM: server: do not auto insert a dynamic server in px addr_node Until then, the servers were automatically attached on their creation into the proxy addr_node tree via _srv_parse_init. In case of an invalid dynamic server which is instantly freed, no detach operation was made leaving a NULL server in the tree. Change this mode of operation by marking the attach operation as optional in _srv_parse_init. This operation is not conduct for a dynamic server. The server is attached only at the end of the CLI handler when it is marked as valid. This must be backported up to 2.4.
2021-06-08 09:19:51 -04:00
* Must be called with the server lock held. The server is first removed from
* the proxy tree if it was already attached. If <reattach> is true, the server
* will then be attached in the proxy tree. The proxy lock is held to
* manipulate the tree.
MEDIUM: stick-tables: Add srvkey option to stick-table This allows using the address of the server rather than the name of the server for keeping track of servers in a backend for stickiness. The peers code was also extended to support feeding the dictionary using this key instead of the name. Fixes #814
2020-11-20 03:28:26 -05:00
*/
BUG/MEDIUM: server: do not auto insert a dynamic server in px addr_node Until then, the servers were automatically attached on their creation into the proxy addr_node tree via _srv_parse_init. In case of an invalid dynamic server which is instantly freed, no detach operation was made leaving a NULL server in the tree. Change this mode of operation by marking the attach operation as optional in _srv_parse_init. This operation is not conduct for a dynamic server. The server is attached only at the end of the CLI handler when it is marked as valid. This must be backported up to 2.4.
2021-06-08 09:19:51 -04:00
static void srv_set_addr_desc(struct server *s, int reattach)
MEDIUM: stick-tables: Add srvkey option to stick-table This allows using the address of the server rather than the name of the server for keeping track of servers in a backend for stickiness. The peers code was also extended to support feeding the dictionary using this key instead of the name. Fixes #814
2020-11-20 03:28:26 -05:00
{
struct proxy *p = s->proxy;
char *key;
BUG/MEDIUM: server: fix race on server_atomic_sync() The following patch fixes a race condition during server addr/port update : cd994407a9545a8d84e410dc0cc18c30966b70d8 BUG/MAJOR: server/addr: fix a race during server addr:svc_port updates The new update mechanism is implemented via an event update. It uses thread isolation to guarantee that no other thread is accessing server addr/port. Furthermore, to ensure server instance is not deleted just before the event handler, server instance is lookup via its ID in proxy tree. However, thread isolation is only entered after server lookup. This leaves a tiny race condition as the thread will be marked as harmless and a concurrent thread can delete the server in the meantime. This causes server_atomic_sync() to manipulated a deleted server instance to reinsert it in used_server_addr backend tree. This can cause a segfault during this operation or possibly on a future used_server_addr tree access. This issue was detected by criteo. Several backtraces were retrieved, each related to server addr_node insert or delete operation, either in srv_set_addr_desc(), or add/delete dynamic server handlers. To fix this, simply extend thread isolation section to start it before server lookup. This ensures that once retrieved the server cannot be deleted until its addr/port are updated. To ensure this issue won't happen anymore, a new BUG_ON() is added in srv_set_addr_desc(). Also note that ebpt_delete() is now called every time on delete handler as this is a safe idempotent operation. To reproduce these crashes, a script was executed to add then remove different servers every second. In parallel, the following CLI command was issued repeatdly without any delay to force multiple update on servers port : set server <srv> addr 0.0.0.0 port $((1024 + RANDOM % 1024)) This must be backported at least up to 3.0. If above mentionned patch has been selected for previous version, this commit must also be backported on them.
2024-07-02 12:14:57 -04:00
/* Risk of used_server_addr tree corruption if server is already deleted. */
BUG_ON(s->flags & SRV_F_DELETED);
MEDIUM: stick-tables: Add srvkey option to stick-table This allows using the address of the server rather than the name of the server for keeping track of servers in a backend for stickiness. The peers code was also extended to support feeding the dictionary using this key instead of the name. Fixes #814
2020-11-20 03:28:26 -05:00
key = sa2str(&s->addr, s->svc_port, s->flags & SRV_F_MAPPORTS);
MEDIUM: server: switch addr_node to cebis_tree This contains the text representation of the server's address, for use with stick-tables with "srvkey addr". Switching them to a compact node saves 24 more bytes from this structure. The key was moved to an external pointer "addr_key" right after the node. The server struct is now 3968 bytes (down from 4032) due to alignment, and the proxy struct shrinks by 8 bytes to 3152.
2025-07-07 09:13:15 -04:00
if (s->addr_key) {
if (key && strcmp(key, s->addr_key) == 0) {
MEDIUM: stick-tables: Add srvkey option to stick-table This allows using the address of the server rather than the name of the server for keeping track of servers in a backend for stickiness. The peers code was also extended to support feeding the dictionary using this key instead of the name. Fixes #814
2020-11-20 03:28:26 -05:00
free(key);
return;
}
HA_RWLOCK_WRLOCK(PROXY_LOCK, &p->lock);
MEDIUM: server: switch addr_node to cebis_tree This contains the text representation of the server's address, for use with stick-tables with "srvkey addr". Switching them to a compact node saves 24 more bytes from this structure. The key was moved to an external pointer "addr_key" right after the node. The server struct is now 3968 bytes (down from 4032) due to alignment, and the proxy struct shrinks by 8 bytes to 3152.
2025-07-07 09:13:15 -04:00
cebuis_item_delete(&p->used_server_addr, addr_node, addr_key, s);
MEDIUM: stick-tables: Add srvkey option to stick-table This allows using the address of the server rather than the name of the server for keeping track of servers in a backend for stickiness. The peers code was also extended to support feeding the dictionary using this key instead of the name. Fixes #814
2020-11-20 03:28:26 -05:00
HA_RWLOCK_WRUNLOCK(PROXY_LOCK, &p->lock);
MEDIUM: server: switch addr_node to cebis_tree This contains the text representation of the server's address, for use with stick-tables with "srvkey addr". Switching them to a compact node saves 24 more bytes from this structure. The key was moved to an external pointer "addr_key" right after the node. The server struct is now 3968 bytes (down from 4032) due to alignment, and the proxy struct shrinks by 8 bytes to 3152.
2025-07-07 09:13:15 -04:00
free(s->addr_key);
MEDIUM: stick-tables: Add srvkey option to stick-table This allows using the address of the server rather than the name of the server for keeping track of servers in a backend for stickiness. The peers code was also extended to support feeding the dictionary using this key instead of the name. Fixes #814
2020-11-20 03:28:26 -05:00
}
MEDIUM: server: switch addr_node to cebis_tree This contains the text representation of the server's address, for use with stick-tables with "srvkey addr". Switching them to a compact node saves 24 more bytes from this structure. The key was moved to an external pointer "addr_key" right after the node. The server struct is now 3968 bytes (down from 4032) due to alignment, and the proxy struct shrinks by 8 bytes to 3152.
2025-07-07 09:13:15 -04:00
s->addr_key = key;
MEDIUM: stick-tables: Add srvkey option to stick-table This allows using the address of the server rather than the name of the server for keeping track of servers in a backend for stickiness. The peers code was also extended to support feeding the dictionary using this key instead of the name. Fixes #814
2020-11-20 03:28:26 -05:00
BUG/MEDIUM: server: do not auto insert a dynamic server in px addr_node Until then, the servers were automatically attached on their creation into the proxy addr_node tree via _srv_parse_init. In case of an invalid dynamic server which is instantly freed, no detach operation was made leaving a NULL server in the tree. Change this mode of operation by marking the attach operation as optional in _srv_parse_init. This operation is not conduct for a dynamic server. The server is attached only at the end of the CLI handler when it is marked as valid. This must be backported up to 2.4.
2021-06-08 09:19:51 -04:00
if (reattach) {
MEDIUM: server: switch addr_node to cebis_tree This contains the text representation of the server's address, for use with stick-tables with "srvkey addr". Switching them to a compact node saves 24 more bytes from this structure. The key was moved to an external pointer "addr_key" right after the node. The server struct is now 3968 bytes (down from 4032) due to alignment, and the proxy struct shrinks by 8 bytes to 3152.
2025-07-07 09:13:15 -04:00
if (s->addr_key) {
BUG/MEDIUM: server: do not auto insert a dynamic server in px addr_node Until then, the servers were automatically attached on their creation into the proxy addr_node tree via _srv_parse_init. In case of an invalid dynamic server which is instantly freed, no detach operation was made leaving a NULL server in the tree. Change this mode of operation by marking the attach operation as optional in _srv_parse_init. This operation is not conduct for a dynamic server. The server is attached only at the end of the CLI handler when it is marked as valid. This must be backported up to 2.4.
2021-06-08 09:19:51 -04:00
HA_RWLOCK_WRLOCK(PROXY_LOCK, &p->lock);
MEDIUM: server: switch addr_node to cebis_tree This contains the text representation of the server's address, for use with stick-tables with "srvkey addr". Switching them to a compact node saves 24 more bytes from this structure. The key was moved to an external pointer "addr_key" right after the node. The server struct is now 3968 bytes (down from 4032) due to alignment, and the proxy struct shrinks by 8 bytes to 3152.
2025-07-07 09:13:15 -04:00
cebuis_item_insert(&p->used_server_addr, addr_node, addr_key, s);
BUG/MEDIUM: server: do not auto insert a dynamic server in px addr_node Until then, the servers were automatically attached on their creation into the proxy addr_node tree via _srv_parse_init. In case of an invalid dynamic server which is instantly freed, no detach operation was made leaving a NULL server in the tree. Change this mode of operation by marking the attach operation as optional in _srv_parse_init. This operation is not conduct for a dynamic server. The server is attached only at the end of the CLI handler when it is marked as valid. This must be backported up to 2.4.
2021-06-08 09:19:51 -04:00
HA_RWLOCK_WRUNLOCK(PROXY_LOCK, &p->lock);
}
BUG/MEDIUM: server: srv_set_addr_desc() crashes when a server has no address GitHub Issue #1026 reported a crash during configuration check for the following example config: backend 0 server 0 0 server 0 0 HAProxy crashed in srv_set_addr_desc() due to a NULL pointer dereference caused by `sa2str` returning NULL for an `AF_UNSPEC` address (`0`). Check to make sure the address key is non-null before using it for comparison or inserting it into the tree. The crash was introduced in commit 92149f9a8 ("MEDIUM: stick-tables: Add srvkey option to stick-table") which not in any released version so no backport is needed. Cc: Tim Duesterhus <tim@bastelstu.be>
2021-01-06 01:10:09 -05:00
}
MEDIUM: stick-tables: Add srvkey option to stick-table This allows using the address of the server rather than the name of the server for keeping track of servers in a backend for stickiness. The peers code was also extended to support feeding the dictionary using this key instead of the name. Fixes #814
2020-11-20 03:28:26 -05:00
}
MINOR: server: add minimal infrastructure to parse keywords Just like with the "bind" lines, we'll switch the "server" line parsing to keyword registration. The code is essentially the same as for bind keywords, with minor changes such as support for the default-server keywords and support for variable argument count.
2012-10-10 02:27:36 -04:00
/*
* Registers the server keyword list <kwl> as a list of valid keywords for next
* parsing sessions.
*/
void srv_register_keywords(struct srv_kw_list *kwl)
{
CLEANUP: lists/tree-wide: rename some list operations to avoid some confusion The current "ADD" vs "ADDQ" is confusing because when thinking in terms of appending at the end of a list, "ADD" naturally comes to mind, but here it does the opposite, it inserts. Several times already it's been incorrectly used where ADDQ was expected, the latest of which was a fortunate accident explained in 6fa922562 ("CLEANUP: stream: explain why we queue the stream at the head of the server list"). Let's use more explicit (but slightly longer) names now: LIST_ADD -> LIST_INSERT LIST_ADDQ -> LIST_APPEND LIST_ADDED -> LIST_INLIST LIST_DEL -> LIST_DELETE The same is true for MT_LISTs, including their "TRY" variant. LIST_DEL_INIT keeps its short name to encourage to use it instead of the lazier LIST_DELETE which is often less safe. The change is large (~674 non-comment entries) but is mechanical enough to remain safe. No permutation was performed, so any out-of-tree code can easily map older names to new ones. The list doc was updated.
2021-04-21 01:32:39 -04:00
LIST_APPEND(&srv_keywords.list, &kwl->list);
MINOR: server: add minimal infrastructure to parse keywords Just like with the "bind" lines, we'll switch the "server" line parsing to keyword registration. The code is essentially the same as for bind keywords, with minor changes such as support for the default-server keywords and support for variable argument count.
2012-10-10 02:27:36 -04:00
}
/* Return a pointer to the server keyword <kw>, or NULL if not found. If the
* keyword is found with a NULL ->parse() function, then an attempt is made to
* find one with a valid ->parse() function. This way it is possible to declare
* platform-dependant, known keywords as NULL, then only declare them as valid
* if some options are met. Note that if the requested keyword contains an
* opening parenthesis, everything from this point is ignored.
*/
struct srv_kw *srv_find_kw(const char *kw)
{
int index;
const char *kwend;
struct srv_kw_list *kwl;
struct srv_kw *ret = NULL;
kwend = strchr(kw, '(');
if (!kwend)
kwend = kw + strlen(kw);
list_for_each_entry(kwl, &srv_keywords.list, list) {
for (index = 0; kwl->kw[index].kw != NULL; index++) {
if ((strncmp(kwl->kw[index].kw, kw, kwend - kw) == 0) &&
kwl->kw[index].kw[kwend-kw] == 0) {
if (kwl->kw[index].parse)
return &kwl->kw[index]; /* found it !*/
else
ret = &kwl->kw[index]; /* may be OK */
}
}
}
return ret;
}
/* Dumps all registered "server" keywords to the <out> string pointer. The
* unsupported keywords are only dumped if their supported form was not
* found.
*/
void srv_dump_kws(char **out)
{
struct srv_kw_list *kwl;
int index;
MINOR: config: Don't dump keywords if argument is NULL Helper functions are used to dump bind, server or filter keywords. These functions are used to report errors during the configuration parsing. To have a coherent API, these functions are now prepared to handle a null pointer as argument. If so, no action is performed and functions immediately return. This patch should fix the issue #631. It is not a bug. There is no reason to backport it.
2020-05-18 06:14:18 -04:00
if (!out)
return;
MINOR: server: add minimal infrastructure to parse keywords Just like with the "bind" lines, we'll switch the "server" line parsing to keyword registration. The code is essentially the same as for bind keywords, with minor changes such as support for the default-server keywords and support for variable argument count.
2012-10-10 02:27:36 -04:00
*out = NULL;
list_for_each_entry(kwl, &srv_keywords.list, list) {
for (index = 0; kwl->kw[index].kw != NULL; index++) {
if (kwl->kw[index].parse ||
srv_find_kw(kwl->kw[index].kw) == &kwl->kw[index]) {
memprintf(out, "%s[%4s] %s%s%s%s\n", *out ? *out : "",
kwl->scope,
kwl->kw[index].kw,
kwl->kw[index].skip ? " <arg>" : "",
kwl->kw[index].default_ok ? " [dflt_ok]" : "",
kwl->kw[index].parse ? "" : " (not supported)");
}
}
}
}
[MEDIUM]: rework checks handling This patch adds two new variables: fastinter and downinter. When server state is: - non-transitionally UP -> inter (no change) - transitionally UP (going down), unchecked or transitionally DOWN (going up) -> fastinter - down -> downinter It allows to set something like: server sr6 127.0.51.61:80 cookie s6 check inter 10000 downinter 20000 fastinter 500 fall 3 weight 40 In the above example haproxy uses 10000ms between checks but as soon as one check fails fastinter (500ms) is used. If server is down downinter (20000) is used or fastinter (500ms) if one check pass. Fastinter is also used when haproxy starts. New "timeout.check" variable was added, if set haproxy uses it as an additional read timeout, but only after a connection has been already established. I was thinking about using "timeout.server" here but most people set this with an addition reserve but still want checks to kick out laggy servers. Please also note that in most cases check request is much simpler and faster to handle than normal requests so this timeout should be smaller. I also changed the timeout used for check connections establishing. Changes from the previous version: - use tv_isset() to check if the timeout is set, - use min("timeout connect", "inter") but only if "timeout check" is set as this min alone may be to short for full (connect + read) check, - debug code (fprintf) commented/removed - documentation Compile tested only (sorry!) as I'm currently traveling but changes are rather small and trivial.
2008-01-20 19:54:06 -05:00
MINOR: cfgparse/server: try to fix spelling mistakes on server lines Let's apply the fuzzy match to server keywords so that we can avoid dumping the huge list of supported keywords each time there is a spelling mistake, and suggest proper spelling instead: $ printf "listen f\nserver s 0 sendpx-v2\n" | ./haproxy -c -f /dev/stdin [NOTICE] 070/095718 (24152) : haproxy version is 2.4-dev11-caa6e3-25 [NOTICE] 070/095718 (24152) : path to executable is ./haproxy [ALERT] 070/095718 (24152) : parsing [/dev/stdin:2] : 'server s' unknown keyword 'sendpx-v2'; did you mean 'send-proxy-v2' maybe ? [ALERT] 070/095718 (24152) : Error(s) found in configuration file : /dev/stdin [ALERT] 070/095718 (24152) : Fatal errors found in configuration.
2021-03-12 03:58:04 -05:00
/* Try to find in srv_keyword the word that looks closest to <word> by counting
* transitions between letters, digits and other characters. Will return the
* best matching word if found, otherwise NULL. An optional array of extra
* words to compare may be passed in <extra>, but it must then be terminated
* by a NULL entry. If unused it may be NULL.
*/
static const char *srv_find_best_kw(const char *word)
{
uint8_t word_sig[1024];
uint8_t list_sig[1024];
const struct srv_kw_list *kwl;
const char *best_ptr = NULL;
int dist, best_dist = INT_MAX;
const char **extra;
int index;
make_word_fingerprint(word_sig, word);
list_for_each_entry(kwl, &srv_keywords.list, list) {
for (index = 0; kwl->kw[index].kw != NULL; index++) {
make_word_fingerprint(list_sig, kwl->kw[index].kw);
dist = word_fingerprint_distance(word_sig, list_sig);
if (dist < best_dist) {
best_dist = dist;
best_ptr = kwl->kw[index].kw;
}
}
}
REORG: server: move keywords in srv_kws Move server-keyword hardcoded in parse_server into the srv_kws list of server.c. Now every server keywords is checked through srv_find_kw. This has the effect to reduce the size of parse_server. As a side-effect, common kw list can be reduced. This change has been made to be able to quickly discard these keywords in case of a dynamic server.
2021-03-10 10:36:02 -05:00
for (extra = extra_kw_list; *extra; extra++) {
MINOR: cfgparse/server: try to fix spelling mistakes on server lines Let's apply the fuzzy match to server keywords so that we can avoid dumping the huge list of supported keywords each time there is a spelling mistake, and suggest proper spelling instead: $ printf "listen f\nserver s 0 sendpx-v2\n" | ./haproxy -c -f /dev/stdin [NOTICE] 070/095718 (24152) : haproxy version is 2.4-dev11-caa6e3-25 [NOTICE] 070/095718 (24152) : path to executable is ./haproxy [ALERT] 070/095718 (24152) : parsing [/dev/stdin:2] : 'server s' unknown keyword 'sendpx-v2'; did you mean 'send-proxy-v2' maybe ? [ALERT] 070/095718 (24152) : Error(s) found in configuration file : /dev/stdin [ALERT] 070/095718 (24152) : Fatal errors found in configuration.
2021-03-12 03:58:04 -05:00
make_word_fingerprint(list_sig, *extra);
dist = word_fingerprint_distance(word_sig, list_sig);
if (dist < best_dist) {
best_dist = dist;
best_ptr = *extra;
}
}
if (best_dist > 2 * strlen(word) || (best_ptr && best_dist > 2 * strlen(best_ptr)))
best_ptr = NULL;
return best_ptr;
}
MINOR: server: add server_get_next_id() to find next free server ID This was previously achieved via the generic get_next_id() but we'll soon get rid of generic ID trees so let's have a dedicated server_get_next_id(). As a bonus it reduces the exposure of the tree's root outside of the functions.
2025-08-23 13:26:08 -04:00
/* This function returns the first unused server ID greater than or equal to
* <from> in the proxy <px>. Zero is returned if no spare one is found (should
* never happen).
*/
uint server_get_next_id(const struct proxy *px, uint from)
{
MEDIUM: server: index server ID using compact trees The server ID is currently stored as a 32-bit int using an eb32 tree. It's used essentially to find holes in order to automatically assign IDs, and to detect duplicates. Let's change this to use compact trees instead in order to save 24 bytes in struct server for this node, plus 8 bytes in struct proxy. The server struct is still 3904 bytes large (due to alignment) and the proxy struct is 3072.
2025-08-24 05:21:02 -04:00
const struct server *sv;
MINOR: server: add server_get_next_id() to find next free server ID This was previously achieved via the generic get_next_id() but we'll soon get rid of generic ID trees so let's have a dedicated server_get_next_id(). As a bonus it reduces the exposure of the tree's root outside of the functions.
2025-08-23 13:26:08 -04:00
do {
MEDIUM: server: index server ID using compact trees The server ID is currently stored as a 32-bit int using an eb32 tree. It's used essentially to find holes in order to automatically assign IDs, and to detect duplicates. Let's change this to use compact trees instead in order to save 24 bytes in struct server for this node, plus 8 bytes in struct proxy. The server struct is still 3904 bytes large (due to alignment) and the proxy struct is 3072.
2025-08-24 05:21:02 -04:00
sv = ceb32_item_lookup_ge(&px->conf.used_server_id, conf.puid_node, puid, from, struct server);
if (!sv || sv->puid > from)
MINOR: server: add server_get_next_id() to find next free server ID This was previously achieved via the generic get_next_id() but we'll soon get rid of generic ID trees so let's have a dedicated server_get_next_id(). As a bonus it reduces the exposure of the tree's root outside of the functions.
2025-08-23 13:26:08 -04:00
return from; /* available */
from++;
} while (from);
return from;
}
MINOR: server: Make 'default-server' support 'backup' keyword. At this time, only 'server' supported 'backup' keyword. This patch makes also 'default-server' directive support this keyword. A new keyword 'no-backup' has been added so that to disable 'backup' setting both in 'server' and 'default-server' directives. For instance, provided the following sequence of directives: default-server backup server srv1 server srv2 no-backup default-server no-backup server srv3 server srv4 backup srv1 and srv4 are declared as backup servers, srv2 and srv3 are declared as non-backup servers.
2017-03-10 05:51:05 -05:00
/* Parse the "backup" server keyword */
static int srv_parse_backup(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
newsrv->flags |= SRV_F_BACKUP;
return 0;
}
MEDIUM: connection: Upstream SOCKS4 proxy support Have "socks4" and "check-via-socks4" server keyword added. Implement handshake with SOCKS4 proxy server for tcp stream connection. See issue #82. I have the "SOCKS: A protocol for TCP proxy across firewalls" doc found at "https://www.openssh.com/txt/socks4.protocol". Please reference to it. [wt: for now connecting to the SOCKS4 proxy over unix sockets is not supported, and mixing IPv4/IPv6 is discouraged; indeed, the control layer is unique for a connection and will be used both for connecting and for target address manipulation. As such it may for example report incorrect destination addresses in logs if the proxy is reached over IPv6]
2019-05-22 07:44:48 -04:00
MINOR: server: Make 'default-server' support 'cookie' keyword. Before this patch, 'cookie' setting was only supported by 'server' directives. This patch makes 'default-server' directive also support 'cookie' setting. Should not break anything.
2017-03-15 04:13:33 -04:00
/* Parse the "cookie" server keyword */
static int srv_parse_cookie(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
char *arg;
arg = args[*cur_arg + 1];
if (!*arg) {
memprintf(err, "'%s' expects <value> as argument.\n", args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
}
free(newsrv->cookie);
newsrv->cookie = strdup(arg);
newsrv->cklen = strlen(arg);
newsrv->flags |= SRV_F_COOKIESET;
return 0;
}
MINOR: server: Make 'default-server' support 'disabled' keyword. Before this patch, only 'server' directives could support 'disabled' setting. This patch makes also 'default-server' directives support this setting. It is used to disable a list of servers declared after a 'defaut-server' directive. 'enabled' new keyword has been added, both supported as 'default-server' and 'server' setting, to enable again a list of servers (so, declared after a 'default-server enabled' directive) or to explicitly enable a specific server declared after a 'default-server disabled' directive. For instance provided this configuration: default-server disabled server srv1... server srv2... server srv3... enabled server srv4... enabled srv1 and srv2 are disabled and srv3 and srv4 enabled. This is equivalent to this configuration: default-server disabled server srv1... server srv2... default-server enabled server srv3... server srv4... even if it would have been preferable/shorter to declare: server srv3... server srv4... default-server disabled server srv1... server srv2... as 'enabled' is the default server state.
2017-03-21 06:53:54 -04:00
/* Parse the "disabled" server keyword */
static int srv_parse_disabled(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
MEDIUM: check: server states and weight propagation re-work The server state and weight was reworked to handle "pending" values updated by checks/CLI/LUA/agent. These values are commited to be propagated to the LB stack. In further dev related to multi-thread, the commit will be handled into a sync point. Pending values are named using the prefix 'next_' Current values used by the LB stack are named 'cur_'
2017-08-31 08:41:55 -04:00
newsrv->next_admin |= SRV_ADMF_CMAINT | SRV_ADMF_FMAINT;
newsrv->next_state = SRV_ST_STOPPED;
MINOR: server: Make 'default-server' support 'disabled' keyword. Before this patch, only 'server' directives could support 'disabled' setting. This patch makes also 'default-server' directives support this setting. It is used to disable a list of servers declared after a 'defaut-server' directive. 'enabled' new keyword has been added, both supported as 'default-server' and 'server' setting, to enable again a list of servers (so, declared after a 'default-server enabled' directive) or to explicitly enable a specific server declared after a 'default-server disabled' directive. For instance provided this configuration: default-server disabled server srv1... server srv2... server srv3... enabled server srv4... enabled srv1 and srv2 are disabled and srv3 and srv4 enabled. This is equivalent to this configuration: default-server disabled server srv1... server srv2... default-server enabled server srv3... server srv4... even if it would have been preferable/shorter to declare: server srv3... server srv4... default-server disabled server srv1... server srv2... as 'enabled' is the default server state.
2017-03-21 06:53:54 -04:00
newsrv->check.state |= CHK_ST_PAUSED;
newsrv->check.health = 0;
return 0;
}
/* Parse the "enabled" server keyword */
static int srv_parse_enabled(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
MEDIUM: check: server states and weight propagation re-work The server state and weight was reworked to handle "pending" values updated by checks/CLI/LUA/agent. These values are commited to be propagated to the LB stack. In further dev related to multi-thread, the commit will be handled into a sync point. Pending values are named using the prefix 'next_' Current values used by the LB stack are named 'cur_'
2017-08-31 08:41:55 -04:00
newsrv->next_admin &= ~SRV_ADMF_CMAINT & ~SRV_ADMF_FMAINT;
newsrv->next_state = SRV_ST_RUNNING;
MINOR: server: Make 'default-server' support 'disabled' keyword. Before this patch, only 'server' directives could support 'disabled' setting. This patch makes also 'default-server' directives support this setting. It is used to disable a list of servers declared after a 'defaut-server' directive. 'enabled' new keyword has been added, both supported as 'default-server' and 'server' setting, to enable again a list of servers (so, declared after a 'default-server enabled' directive) or to explicitly enable a specific server declared after a 'default-server disabled' directive. For instance provided this configuration: default-server disabled server srv1... server srv2... server srv3... enabled server srv4... enabled srv1 and srv2 are disabled and srv3 and srv4 enabled. This is equivalent to this configuration: default-server disabled server srv1... server srv2... default-server enabled server srv3... server srv4... even if it would have been preferable/shorter to declare: server srv3... server srv4... default-server disabled server srv1... server srv2... as 'enabled' is the default server state.
2017-03-21 06:53:54 -04:00
newsrv->check.state &= ~CHK_ST_PAUSED;
newsrv->check.health = newsrv->check.rise;
return 0;
}
REORG: server: move keywords in srv_kws Move server-keyword hardcoded in parse_server into the srv_kws list of server.c. Now every server keywords is checked through srv_find_kw. This has the effect to reduce the size of parse_server. As a side-effect, common kw list can be reduced. This change has been made to be able to quickly discard these keywords in case of a dynamic server.
2021-03-10 10:36:02 -05:00
/* Parse the "error-limit" server keyword */
static int srv_parse_error_limit(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
if (!*args[*cur_arg + 1]) {
memprintf(err, "'%s' expects an integer argument.",
args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
}
newsrv->consecutive_errors_limit = atoi(args[*cur_arg + 1]);
if (newsrv->consecutive_errors_limit <= 0) {
memprintf(err, "%s has to be > 0.",
args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
}
return 0;
}
MINOR: server: implement GUID support This commit is similar to previous one, except that it implements GUID support for server instances. A guid_node field is inserted into server structure. A new "guid" server keyword is defined.
2024-03-26 10:01:35 -04:00
/* Parse the "guid" keyword */
static int srv_parse_guid(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
const char *guid;
char *guid_err = NULL;
if (!*args[*cur_arg + 1]) {
memprintf(err, "'%s' : expects an argument", args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
}
guid = args[*cur_arg + 1];
if (guid_insert(&newsrv->obj_type, guid, &guid_err)) {
memprintf(err, "'%s': %s", args[*cur_arg], guid_err);
ha_free(&guid_err);
return ERR_ALERT | ERR_FATAL;
}
return 0;
}
MINOR: server: add ws keyword Implement parsing for the server keyword 'ws'. This is used to configure the mode of selection for websocket protocol. The configuration documentation has been updated. A new regtest has been created to test the proper behavior of the keyword.
2021-10-18 08:40:29 -04:00
/* Parse the "ws" keyword */
static int srv_parse_ws(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
if (!args[*cur_arg + 1]) {
memprintf(err, "'%s' expects 'auto', 'h1' or 'h2' value", args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
}
if (strcmp(args[*cur_arg + 1], "h1") == 0) {
newsrv->ws = SRV_WS_H1;
}
else if (strcmp(args[*cur_arg + 1], "h2") == 0) {
newsrv->ws = SRV_WS_H2;
}
else if (strcmp(args[*cur_arg + 1], "auto") == 0) {
newsrv->ws = SRV_WS_AUTO;
}
else {
memprintf(err, "'%s' has to be 'auto', 'h1' or 'h2'", args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
}
return 0;
}
MEDIUM: lb-chash: Deterministic node hashes based on server address Motivation: When services are discovered through DNS resolution, the order in which DNS records get resolved and assigned to servers is arbitrary. Therefore, even though two HAProxy instances using chash balancing might agree that a particular request should go to server3, it is likely the case that they have assigned different IPs and ports to the server in that slot. This patch adds a server option, "hash-key <key>" which can be set to "id" (the existing behaviour, default), "addr", or "addr-port". By deriving the keys for the chash tree nodes from a server's address and port we ensure that independent HAProxy instances will agree on routing decisions. If an address is not known then the key is derived from the server's puid as it was previously. When adjusting a server's weight, we now check whether the server's hash has changed. If it has, we have to remove all its nodes first, since the node keys will also have to change.
2024-02-16 16:00:35 -05:00
/* Parse the "hash-key" server keyword */
static int srv_parse_hash_key(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
if (!args[*cur_arg + 1]) {
memprintf(err, "'%s expects 'id', 'addr', or 'addr-port' value", args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
}
if (strcmp(args[*cur_arg + 1], "id") == 0) {
newsrv->hash_key = SRV_HASH_KEY_ID;
}
else if (strcmp(args[*cur_arg + 1], "addr") == 0) {
newsrv->hash_key = SRV_HASH_KEY_ADDR;
}
else if (strcmp(args[*cur_arg + 1], "addr-port") == 0) {
newsrv->hash_key = SRV_HASH_KEY_ADDR_PORT;
}
else {
memprintf(err, "'%s' has to be 'id', 'addr', or 'addr-port'", args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
}
return 0;
}
MEDIUM: server/mux-h2: implement idle-ping on backend side This commit implements support for idle-ping on the backend side. First, a new server keyword "idle-ping" is defined in configuration parsing. It is used to set the corresponding new server member. The second part of this commit implements idle-ping support on H2 MUX. A new inlined function conn_idle_ping() is defined to access connection idle-ping value. Two new connection flags are defined H2_CF_IDL_PING and H2_CF_IDL_PING_SENT. The first one is set for idle connections via h2c_update_timeout(). On h2_timeout_task() handler, if first flag is set, instead of releasing the connection as before, the second flag is set and tasklet is scheduled. As both flags are now set, h2_process_mux() will proceed to PING emission. The timer has also been rearmed to the idle-ping value. If a PING ACK is received before next timeout, connection timer is refreshed. Else, the connection is released, as with timer expiration. Also of importance, special care is needed when a backend connection is going to idle. In this case, idle-ping timer must be rearmed. Thus a new invokation of h2c_update_timeout() is performed on h2_detach().
2025-04-08 05:09:06 -04:00
/* Parse the "idle-ping" server keyword */
static int srv_parse_idle_ping(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
const char *res;
unsigned int value;
if (!*(args[*cur_arg+1])) {
memprintf(err, "'%s' expects an argument.", args[*cur_arg]);
goto error;
}
res = parse_time_err(args[*cur_arg+1], &value, TIME_UNIT_MS);
if (res == PARSE_TIME_OVER) {
memprintf(err, "timer overflow in argument <%s> to <%s> of server %s, maximum value is 2147483647 ms (~24.8 days).",
args[*cur_arg+1], args[*cur_arg], newsrv->id);
goto error;
}
else if (res == PARSE_TIME_UNDER) {
memprintf(err, "timer underflow in argument <%s> to <%s> of server %s, minimum non-null value is 1 ms.",
args[*cur_arg+1], args[*cur_arg], newsrv->id);
goto error;
}
else if (res) {
memprintf(err, "unexpected character '%c' in '%s' argument of server %s.",
*res, args[*cur_arg], newsrv->id);
goto error;
}
newsrv->idle_ping = value;
return 0;
error:
return ERR_ALERT | ERR_FATAL;
}
REORG: server: move keywords in srv_kws Move server-keyword hardcoded in parse_server into the srv_kws list of server.c. Now every server keywords is checked through srv_find_kw. This has the effect to reduce the size of parse_server. As a side-effect, common kw list can be reduced. This change has been made to be able to quickly discard these keywords in case of a dynamic server.
2021-03-10 10:36:02 -05:00
/* Parse the "init-addr" server keyword */
static int srv_parse_init_addr(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
char *p, *end;
int done;
struct sockaddr_storage sa;
newsrv->init_addr_methods = 0;
memset(&newsrv->init_addr, 0, sizeof(newsrv->init_addr));
for (p = args[*cur_arg + 1]; *p; p = end) {
/* cut on next comma */
for (end = p; *end && *end != ','; end++);
if (*end)
*(end++) = 0;
memset(&sa, 0, sizeof(sa));
if (strcmp(p, "libc") == 0) {
done = srv_append_initaddr(&newsrv->init_addr_methods, SRV_IADDR_LIBC);
}
else if (strcmp(p, "last") == 0) {
done = srv_append_initaddr(&newsrv->init_addr_methods, SRV_IADDR_LAST);
}
else if (strcmp(p, "none") == 0) {
done = srv_append_initaddr(&newsrv->init_addr_methods, SRV_IADDR_NONE);
}
else if (str2ip2(p, &sa, 0)) {
if (is_addr(&newsrv->init_addr)) {
memprintf(err, "'%s' : initial address already specified, cannot add '%s'.",
args[*cur_arg], p);
return ERR_ALERT | ERR_FATAL;
}
newsrv->init_addr = sa;
done = srv_append_initaddr(&newsrv->init_addr_methods, SRV_IADDR_IP);
}
else {
memprintf(err, "'%s' : unknown init-addr method '%s', supported methods are 'libc', 'last', 'none'.",
args[*cur_arg], p);
return ERR_ALERT | ERR_FATAL;
}
if (!done) {
memprintf(err, "'%s' : too many init-addr methods when trying to add '%s'",
args[*cur_arg], p);
return ERR_ALERT | ERR_FATAL;
}
}
return 0;
}
MEDIUM: server: add init-state Allow the user to set the "initial state" of a server. Context: Servers are always set in an UP status by default. In some cases, further checks are required to determine if the server is ready to receive client traffic. This introduces the "init-state {up|down}" configuration parameter to the server. - when set to 'fully-up', the server is considered immediately available and can turn to the DOWN sate when ALL health checks fail. - when set to 'up' (the default), the server is considered immediately available and will initiate a health check that can turn it to the DOWN state immediately if it fails. - when set to 'down', the server initially is considered unavailable and will initiate a health check that can turn it to the UP state immediately if it succeeds. - when set to 'fully-down', the server is initially considered unavailable and can turn to the UP state when ALL health checks succeed. The server's init-state is considered when the HAProxy instance is (re)started, a new server is detected (for example via service discovery / DNS resolution), a server exits maintenance, etc. Link: https://github.com/haproxy/haproxy/issues/51
2024-09-04 18:27:35 -04:00
/* Parse the "init-state" server keyword */
static int srv_parse_init_state(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
if (strcmp(args[*cur_arg + 1], "fully-up") == 0)
newsrv->init_state= SRV_INIT_STATE_FULLY_UP;
else if (strcmp(args[*cur_arg + 1], "up") == 0)
newsrv->init_state = SRV_INIT_STATE_UP;
else if (strcmp(args[*cur_arg + 1], "down") == 0)
newsrv->init_state= SRV_INIT_STATE_DOWN;
else if (strcmp(args[*cur_arg + 1], "fully-down") == 0)
newsrv->init_state= SRV_INIT_STATE_FULLY_DOWN;
else {
memprintf(err, "'%s' expects one of 'fully-up', 'up', 'down', or 'fully-down' but got '%s'",
args[*cur_arg], args[*cur_arg + 1]);
return ERR_ALERT | ERR_FATAL;
}
return 0;
}
MINOR: server: introduce "log-bufsize" kw "log-bufsize" may now be used for a log server (in a log backend) to configure the bufsize of implicit ring associated to the server (which defaults to BUFSIZE).
2023-10-04 04:32:45 -04:00
/* Parse the "log-bufsize" server keyword */
static int srv_parse_log_bufsize(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
if (!*args[*cur_arg + 1]) {
memprintf(err, "'%s' expects an integer argument.",
args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
}
newsrv->log_bufsize = atoi(args[*cur_arg + 1]);
if (newsrv->log_bufsize <= 0) {
memprintf(err, "%s has to be > 0.",
args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
}
return 0;
}
REORG: server: move keywords in srv_kws Move server-keyword hardcoded in parse_server into the srv_kws list of server.c. Now every server keywords is checked through srv_find_kw. This has the effect to reduce the size of parse_server. As a side-effect, common kw list can be reduced. This change has been made to be able to quickly discard these keywords in case of a dynamic server.
2021-03-10 10:36:02 -05:00
/* Parse the "log-proto" server keyword */
static int srv_parse_log_proto(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
if (strcmp(args[*cur_arg + 1], "legacy") == 0)
newsrv->log_proto = SRV_LOG_PROTO_LEGACY;
else if (strcmp(args[*cur_arg + 1], "octet-count") == 0)
newsrv->log_proto = SRV_LOG_PROTO_OCTET_COUNTING;
else {
memprintf(err, "'%s' expects one of 'legacy' or 'octet-count' but got '%s'",
args[*cur_arg], args[*cur_arg + 1]);
return ERR_ALERT | ERR_FATAL;
}
return 0;
}
/* Parse the "maxconn" server keyword */
static int srv_parse_maxconn(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
newsrv->maxconn = atol(args[*cur_arg + 1]);
return 0;
}
/* Parse the "maxqueue" server keyword */
static int srv_parse_maxqueue(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
newsrv->maxqueue = atol(args[*cur_arg + 1]);
return 0;
}
/* Parse the "minconn" server keyword */
static int srv_parse_minconn(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
newsrv->minconn = atol(args[*cur_arg + 1]);
return 0;
}
MINOR: server: add a max-reuse parameter Some servers may wish to limit the total number of requests they execute over a connection because some of their components might leak resources. In HTTP/1 it was easy, they just had to emit a "connection: close" header field with the last response. In HTTP/2, it's less easy because the info is not always shared with the component dealing with the H2 protocol and it could be harder to advertise a GOAWAY with a stream limit. This patch provides a solution to this by adding a new "max-reuse" parameter to the server keyword. This parameter indicates how many times an idle connection may be reused for new requests. The information is made available and the underlying muxes will be able to use it at will. This patch should be backported to 1.9.
2019-01-23 04:21:49 -05:00
static int srv_parse_max_reuse(char **args, int *cur_arg, struct proxy *curproxy, struct server *newsrv, char **err)
{
char *arg;
arg = args[*cur_arg + 1];
if (!*arg) {
memprintf(err, "'%s' expects <value> as argument.\n", args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
}
newsrv->max_reuse = atoi(arg);
return 0;
}
MEDIUM: servers: Replace idle-timeout with pool-purge-delay. Instead of the old "idle-timeout" mechanism, add a new option, "pool-purge-delay", that sets the delay before purging idle connections. Each time the delay happens, we destroy half of the idle connections.
2018-12-14 12:15:36 -05:00
static int srv_parse_pool_purge_delay(char **args, int *cur_arg, struct proxy *curproxy, struct server *newsrv, char **err)
MEDIUM: servers: Add a way to keep idle connections alive. Add a new keyword for servers, "idle-timeout". If set, unused connections are kept alive until the timeout happens, and will be picked for reuse if no other connection is available.
2018-12-02 08:11:41 -05:00
{
const char *res;
char *arg;
unsigned int time;
arg = args[*cur_arg + 1];
if (!*arg) {
memprintf(err, "'%s' expects <value> as argument.\n", args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
}
res = parse_time_err(arg, &time, TIME_UNIT_MS);
MEDIUM: tools: improve time format error detection As reported in GH issue #109 and in discourse issue https://discourse.haproxy.org/t/haproxy-returns-408-or-504-error-when-timeout-client-value-is-every-25d the time parser doesn't error on overflows nor underflows. This is a recurring problem which additionally has the bad taste of taking a long time before hitting the user. This patch makes parse_time_err() return special error codes for overflows and underflows, and adds the control in the call places to report suitable errors depending on the requested unit. In practice, underflows are almost never returned as the parsing function takes care of rounding values up, so this might possibly happen on 64-bit overflows returning exactly zero after rounding though. It is not really possible to cut the patch into pieces as it changes the function's API, hence all callers. Tests were run on about every relevant part (cookie maxlife/maxidle, server inter, stats timeout, timeout*, cli's set timeout command, tcp-request/response inspect-delay).
2019-06-07 13:00:37 -04:00
if (res == PARSE_TIME_OVER) {
memprintf(err, "timer overflow in argument '%s' to '%s' (maximum value is 2147483647 ms or ~24.8 days)",
args[*cur_arg+1], args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
}
else if (res == PARSE_TIME_UNDER) {
memprintf(err, "timer underflow in argument '%s' to '%s' (minimum non-null value is 1 ms)",
args[*cur_arg+1], args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
}
else if (res) {
MEDIUM: servers: Add a way to keep idle connections alive. Add a new keyword for servers, "idle-timeout". If set, unused connections are kept alive until the timeout happens, and will be picked for reuse if no other connection is available.
2018-12-02 08:11:41 -05:00
memprintf(err, "unexpected character '%c' in argument to <%s>.\n",
*res, args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
}
MEDIUM: servers: Replace idle-timeout with pool-purge-delay. Instead of the old "idle-timeout" mechanism, add a new option, "pool-purge-delay", that sets the delay before purging idle connections. Each time the delay happens, we destroy half of the idle connections.
2018-12-14 12:15:36 -05:00
newsrv->pool_purge_delay = time;
MEDIUM: servers: Add a way to keep idle connections alive. Add a new keyword for servers, "idle-timeout". If set, unused connections are kept alive until the timeout happens, and will be picked for reuse if no other connection is available.
2018-12-02 08:11:41 -05:00
return 0;
}
MINOR: server: define pool-conn-name keyword Define a new server keyword pool-conn-name. The purpose of this keyword will be to identify connections inside the idle connections pool, replacing SNI in case SSL is not wanted. This keyword uses a sample expression argument. It thus can reuse existing function parse_srv_expr() for parsing. In the future, it may be necessary to define a keyword variant which uses a logformat for extensability. This patch only implement parsing. Argument is stored inside new server field <pool_conn_name> and expression is generated in _srv_parse_finalize() into <pool_conn_name_expr>. If pool-conn-name is not set but SNI is, the latter is reused automatically as pool-conn-name via _srv_parse_finalize(). This ensures current reuse behavior remains compatible and idle connection reuse will not mix connections with different SNIs by mistake. Main usage will be for rhttp when SSL is not wanted between the two haproxy instances. Previously, it was possible to use "sni" keyword even without SSL on a server line which have a similar effect. However, having a dedicated "pool-conn-name" keyword is deemed clearer. Besides, it would allow for more complex configuration where pool-conn-name and SNI are use in parallel with different values.
2024-05-23 05:14:13 -04:00
static int srv_parse_pool_conn_name(char **args, int *cur_arg, struct proxy *curproxy, struct server *newsrv, char **err)
{
char *arg;
arg = args[*cur_arg + 1];
if (!*arg) {
memprintf(err, "'%s' expects <value> as argument", args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
}
ha_free(&newsrv->pool_conn_name);
newsrv->pool_conn_name = strdup(arg);
if (!newsrv->pool_conn_name) {
memprintf(err, "'%s' : out of memory", args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
}
return 0;
}
MEDIUM: server: add a new pool-low-conn server setting The problem with the way idle connections currently work is that it's easy for a thread to steal all of its siblings' connections, then release them, then it's done by another one, etc. This happens even more easily due to scheduling latencies, or merged events inside the same pool loop, which, when dealing with a fast server responding in sub-millisecond delays, can really result in one thread being fully at work at a time. In such a case, we perform a huge amount of takeover() which consumes CPU and requires quite some locking, sometimes resulting in lower performance than expected. In order to fight against this problem, this patch introduces a new server setting "pool-low-conn", whose purpose is to dictate when it is allowed to steal connections from a sibling. As long as the number of idle connections remains at least as high as this value, it is permitted to take over another connection. When the idle connection count becomes lower, a thread may only use its own connections or create a new one. By proceeding like this even with a low number (typically 2*nbthreads), we quickly end up in a situation where all active threads have a few connections. It then becomes possible to connect to a server without bothering other threads the vast majority of the time, while still being able to use these connections when the number of available FDs becomes low. We also use this threshold instead of global.nbthread in the connection release logic, allowing to keep more extra connections if needed. A test performed with 10000 concurrent HTTP/1 connections, 16 threads and 210 servers with 1 millisecond of server response time showed the following numbers: haproxy 2.1.7: 185000 requests per second haproxy 2.2: 314000 requests per second haproxy 2.2 lowconn 32: 352000 requests per second The takeover rate goes down from 300k/s to 13k/s. The difference is further amplified as the response time shrinks.
2020-07-01 01:43:51 -04:00
static int srv_parse_pool_low_conn(char **args, int *cur_arg, struct proxy *curproxy, struct server *newsrv, char **err)
{
char *arg;
arg = args[*cur_arg + 1];
if (!*arg) {
memprintf(err, "'%s' expects <value> as argument.\n", args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
}
newsrv->low_idle_conns = atoi(arg);
return 0;
}
MEDIUM: servers: Add a command to limit the number of idling connections. Add a new command, "pool-max-conn" that sets the maximum number of connections waiting in the orphan idling connections list (as activated with idle-timeout). Using "-1" means unlimited. Using pools is now dependant on this.
2018-12-10 12:30:32 -05:00
static int srv_parse_pool_max_conn(char **args, int *cur_arg, struct proxy *curproxy, struct server *newsrv, char **err)
{
char *arg;
arg = args[*cur_arg + 1];
if (!*arg) {
memprintf(err, "'%s' expects <value> as argument.\n", args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
}
MINOR: server: make sure pool-max-conn is >= -1 The keyword parser doesn't check the value range, but supported values are -1 and positive values, thus we should check it. This can be backported to 1.9.
2019-01-23 04:39:27 -05:00
MEDIUM: servers: Add a command to limit the number of idling connections. Add a new command, "pool-max-conn" that sets the maximum number of connections waiting in the orphan idling connections list (as activated with idle-timeout). Using "-1" means unlimited. Using pools is now dependant on this.
2018-12-10 12:30:32 -05:00
newsrv->max_idle_conns = atoi(arg);
MINOR: server: make sure pool-max-conn is >= -1 The keyword parser doesn't check the value range, but supported values are -1 and positive values, thus we should check it. This can be backported to 1.9.
2019-01-23 04:39:27 -05:00
if ((int)newsrv->max_idle_conns < -1) {
memprintf(err, "'%s' must be >= -1", args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
}
MEDIUM: servers: Add a command to limit the number of idling connections. Add a new command, "pool-max-conn" that sets the maximum number of connections waiting in the orphan idling connections list (as activated with idle-timeout). Using "-1" means unlimited. Using pools is now dependant on this.
2018-12-10 12:30:32 -05:00
return 0;
}
MEDIUM: server: move parsing of keyword "id" to server.c This is the first keyword to be moved to server.c.
2012-10-10 11:51:05 -04:00
/* parse the "id" server keyword */
static int srv_parse_id(char **args, int *cur_arg, struct proxy *curproxy, struct server *newsrv, char **err)
{
CLEANUP: server: use server_find_by_id() when looking for already used IDs In srv_parse_id(), there's no point doing all the low-level work with the tree functions to check for the existence of an ID, we already have server_find_by_id() which does exactly this, so let's use it.
2025-08-23 13:26:54 -04:00
struct server *target;
MEDIUM: server: move parsing of keyword "id" to server.c This is the first keyword to be moved to server.c.
2012-10-10 11:51:05 -04:00
if (!*args[*cur_arg + 1]) {
memprintf(err, "'%s' : expects an integer argument", args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
}
newsrv->puid = atol(args[*cur_arg + 1]);
if (newsrv->puid <= 0) {
memprintf(err, "'%s' : custom id has to be > 0", args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
}
CLEANUP: server: use server_find_by_id() when looking for already used IDs In srv_parse_id(), there's no point doing all the low-level work with the tree functions to check for the existence of an ID, we already have server_find_by_id() which does exactly this, so let's use it.
2025-08-23 13:26:54 -04:00
target = server_find_by_id(curproxy, newsrv->puid);
if (target) {
MEDIUM: server: move parsing of keyword "id" to server.c This is the first keyword to be moved to server.c.
2012-10-10 11:51:05 -04:00
memprintf(err, "'%s' : custom id %d already used at %s:%d ('server %s')",
args[*cur_arg], newsrv->puid, target->conf.file, target->conf.line,
target->id);
return ERR_ALERT | ERR_FATAL;
}
MINOR: server: new server flag: SRV_F_FORCED_ID This flag aims at reporting whether the server unique id (srv->puid) has been forced by the administrator in HAProxy's configuration. If not set, it means HAProxy has generated automatically the server's unique id.
2015-07-07 16:02:20 -04:00
newsrv->flags |= SRV_F_FORCED_ID;
MEDIUM: server: move parsing of keyword "id" to server.c This is the first keyword to be moved to server.c.
2012-10-10 11:51:05 -04:00
return 0;
}
MINOR: server: Make 'default-server' support 'namespace' keyword. Before this patch, 'namespace' setting was only supported by 'server' directive. This patch makes 'default-server' directive support this setting.
2017-03-16 12:17:36 -04:00
/* Parse the "namespace" server keyword */
static int srv_parse_namespace(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
CLEANUP: build: rename some build macros to use the USE_* ones We still have quite a number of build macros which are mapped 1:1 to a USE_something setting in the makefile but which have a different name. This patch cleans this up by renaming them to use the USE_something one, allowing to clean up the makefile and make it more obvious when reading the code what build option needs to be added. The following renames were done : ENABLE_POLL -> USE_POLL ENABLE_EPOLL -> USE_EPOLL ENABLE_KQUEUE -> USE_KQUEUE ENABLE_EVPORTS -> USE_EVPORTS TPROXY -> USE_TPROXY NETFILTER -> USE_NETFILTER NEED_CRYPT_H -> USE_CRYPT_H CONFIG_HAP_CRYPT -> USE_LIBCRYPT CONFIG_HAP_NS -> DUSE_NS CONFIG_HAP_LINUX_SPLICE -> USE_LINUX_SPLICE CONFIG_HAP_LINUX_TPROXY -> USE_LINUX_TPROXY CONFIG_HAP_LINUX_VSYSCALL -> USE_LINUX_VSYSCALL
2019-05-22 13:24:06 -04:00
#ifdef USE_NS
MINOR: server: Make 'default-server' support 'namespace' keyword. Before this patch, 'namespace' setting was only supported by 'server' directive. This patch makes 'default-server' directive support this setting.
2017-03-16 12:17:36 -04:00
char *arg;
arg = args[*cur_arg + 1];
if (!*arg) {
memprintf(err, "'%s' : expects <name> as argument", args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
}
CLEANUP: Compare the return value of `XXXcmp()` functions with zero According to coding-style.txt it is recommended to use: `strcmp(a, b) == 0` instead of `!strcmp(a, b)` So let's do this. The change was performed by running the following (very long) coccinelle patch on src/: @@ statement S; expression E; expression F; @@ if ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) ( S | { ... } ) @@ statement S; expression E; expression F; @@ if ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) ( S | { ... } ) @@ expression E; expression F; expression G; @@ ( G && ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( G || ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 && G ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 || G ) @@ expression E; expression F; expression G; @@ ( G && - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( G || - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 && G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 || G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 )
2021-01-02 16:31:53 -05:00
if (strcmp(arg, "*") == 0) {
MINOR: server: Make 'default-server' support 'namespace' keyword. Before this patch, 'namespace' setting was only supported by 'server' directive. This patch makes 'default-server' directive support this setting.
2017-03-16 12:17:36 -04:00
/* Use the namespace associated with the connection (if present). */
newsrv->flags |= SRV_F_USE_NS_FROM_PP;
MINOR: capabilities: add cap_sys_admin support If 'namespace' keyword is used in the backend server settings or/and in the bind string, it means that haproxy process will call setns() to change its default namespace to the configured one and then, it will create a socket in this new namespace. setns() syscall requires CAP_SYS_ADMIN capability in the process Effective set (see man 2 setns). Otherwise, the process must be run as root. To avoid to run haproxy as root, let's add cap_sys_admin capability in the same way as we already added the support for some other network capabilities. As CAP_SYS_ADMIN belongs to CAP_SYS_* capabilities type, let's add a separate flag LSTCHK_SYSADM for it. This flag is set, if the 'namespace' keyword was found during configuration parsing. The flag may be unset only in prepare_caps_for_setuid() or in prepare_caps_from_permitted_set(), which inspect process EUID/RUID and Effective and Permitted capabilities sets. If system doesn't support Linux capabilities or 'cap_sys_admin' was not set in 'setcap', but 'namespace' keyword is presented in the configuration, we keep the previous strict behaviour. Process, that has changed uid to the non-priviledged user, will terminate with alert. This alert invites the user to recheck its configuration. In the case, when haproxy will start and run under a non-root user and 'cap_sys_admin' is not set, but 'namespace' keyword is presented, this patch does not change previous behaviour as well. We'll still let the user to try its configuration, but we inform via warning, that unexpected things, like socket creation errors, may occur.
2024-04-26 15:47:54 -04:00
global.last_checks |= LSTCHK_SYSADM;
MINOR: server: Make 'default-server' support 'namespace' keyword. Before this patch, 'namespace' setting was only supported by 'server' directive. This patch makes 'default-server' directive support this setting.
2017-03-16 12:17:36 -04:00
return 0;
}
/*
* As this parser may be called several times for the same 'default-server'
* object, or for a new 'server' instance deriving from a 'default-server'
* one with SRV_F_USE_NS_FROM_PP flag enabled, let's reset it.
*/
newsrv->flags &= ~SRV_F_USE_NS_FROM_PP;
newsrv->netns = netns_store_lookup(arg, strlen(arg));
if (!newsrv->netns)
newsrv->netns = netns_store_insert(arg);
if (!newsrv->netns) {
memprintf(err, "Cannot open namespace '%s'", arg);
return ERR_ALERT | ERR_FATAL;
}
MINOR: capabilities: add cap_sys_admin support If 'namespace' keyword is used in the backend server settings or/and in the bind string, it means that haproxy process will call setns() to change its default namespace to the configured one and then, it will create a socket in this new namespace. setns() syscall requires CAP_SYS_ADMIN capability in the process Effective set (see man 2 setns). Otherwise, the process must be run as root. To avoid to run haproxy as root, let's add cap_sys_admin capability in the same way as we already added the support for some other network capabilities. As CAP_SYS_ADMIN belongs to CAP_SYS_* capabilities type, let's add a separate flag LSTCHK_SYSADM for it. This flag is set, if the 'namespace' keyword was found during configuration parsing. The flag may be unset only in prepare_caps_for_setuid() or in prepare_caps_from_permitted_set(), which inspect process EUID/RUID and Effective and Permitted capabilities sets. If system doesn't support Linux capabilities or 'cap_sys_admin' was not set in 'setcap', but 'namespace' keyword is presented in the configuration, we keep the previous strict behaviour. Process, that has changed uid to the non-priviledged user, will terminate with alert. This alert invites the user to recheck its configuration. In the case, when haproxy will start and run under a non-root user and 'cap_sys_admin' is not set, but 'namespace' keyword is presented, this patch does not change previous behaviour as well. We'll still let the user to try its configuration, but we inform via warning, that unexpected things, like socket creation errors, may occur.
2024-04-26 15:47:54 -04:00
global.last_checks |= LSTCHK_SYSADM;
MINOR: server: Make 'default-server' support 'namespace' keyword. Before this patch, 'namespace' setting was only supported by 'server' directive. This patch makes 'default-server' directive support this setting.
2017-03-16 12:17:36 -04:00
return 0;
#else
memprintf(err, "'%s': '%s' option not implemented", args[0], args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
#endif
}
MINOR: server: Make 'default-server' support 'backup' keyword. At this time, only 'server' supported 'backup' keyword. This patch makes also 'default-server' directive support this keyword. A new keyword 'no-backup' has been added so that to disable 'backup' setting both in 'server' and 'default-server' directives. For instance, provided the following sequence of directives: default-server backup server srv1 server srv2 no-backup default-server no-backup server srv3 server srv4 backup srv1 and srv4 are declared as backup servers, srv2 and srv3 are declared as non-backup servers.
2017-03-10 05:51:05 -05:00
/* Parse the "no-backup" server keyword */
static int srv_parse_no_backup(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
newsrv->flags &= ~SRV_F_BACKUP;
return 0;
}
MINOR: server: Make 'default-server' support 'check-send-proxy' keyword. This patch makes 'default-server' directive support 'check-send-proxy' setting. A new keyword 'no-check-send-proxy' has been added so that to disable 'check-send-proxy' setting both in 'server' and 'default-server' directives.
2017-03-10 08:04:31 -05:00
MINOR: server: Make 'default-server' support 'send-proxy' and 'send-proxy-v2 keywords. This patch makes 'default-server' directive support 'send-proxy' (resp. 'send-proxy-v2') setting. A new keyword 'no-send-proxy' (resp. 'no-send-proxy-v2') has been added to disable 'send-proxy' (resp. 'send-proxy-v2') setting both in 'server' and 'default-server' directives.
2017-03-10 10:40:00 -05:00
/* Disable server PROXY protocol flags. */
BUILD: address a few cases of "static <type> inline foo()" Older compilers don't like to see "inline" placed after the type in a function declaration, it must be "static inline <type>" only. This patch touches various areas. The warnings were seen with gcc-3.4.
2019-04-15 15:25:03 -04:00
static inline int srv_disable_pp_flags(struct server *srv, unsigned int flags)
MINOR: server: Make 'default-server' support 'send-proxy' and 'send-proxy-v2 keywords. This patch makes 'default-server' directive support 'send-proxy' (resp. 'send-proxy-v2') setting. A new keyword 'no-send-proxy' (resp. 'no-send-proxy-v2') has been added to disable 'send-proxy' (resp. 'send-proxy-v2') setting both in 'server' and 'default-server' directives.
2017-03-10 10:40:00 -05:00
{
srv->pp_opts &= ~flags;
return 0;
}
/* Parse the "no-send-proxy" server keyword */
static int srv_parse_no_send_proxy(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
return srv_disable_pp_flags(newsrv, SRV_PP_V1);
}
/* Parse the "no-send-proxy-v2" server keyword */
static int srv_parse_no_send_proxy_v2(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
return srv_disable_pp_flags(newsrv, SRV_PP_V2);
}
MINOR: peers: Support for peer shards Add "shards" new keyword for "peers" section to configure the number of peer shards attached to such secions. This impact all the stick-tables attached to the section. Add "shard" new "server" parameter to configure the peers which participate to all the stick-tables contents distribution. Each peer receive the stick-tables updates only for keys with this shard value as distribution hash. The "shard" value is stored in ->shard new server struct member. cfg_parse_peers() which is the function which is called to parse all the lines of a "peers" section is modified to parse the "shards" parameter stored in ->nb_shards new peers struct member. Add srv_parse_shard() new callback into server.c to pare the "shard" parameter. Implement stksess_getkey_hash() to compute the distribution hash for a stick-table key as the 64-bits xxhash of the key concatenated to the stick-table name. This function is called by stksess_setkey_shard(), itself called by the already implemented function which create a new stick-table key (stksess_new()). Add ->idlen new stktable struct member to store the stick-table name length to not have to compute it each time a stick-table key hash is computed.
2022-10-17 08:58:19 -04:00
/* Parse the "shard" server keyword */
static int srv_parse_shard(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
newsrv->shard = atol(args[*cur_arg + 1]);
return 0;
}
MINOR: server: Add "no-tfo" option. Simple patch to add "no-tfo" option to "default-server" and "server" lines to disable any usage of TCP fast open. Must be backported to 2.0.
2019-07-04 08:19:06 -04:00
/* Parse the "no-tfo" server keyword */
static int srv_parse_no_tfo(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
newsrv->flags &= ~SRV_F_FASTOPEN;
return 0;
}
MINOR: server: Make 'default-server' support 'non-stick' keyword. This patch makes 'default-server' directive support 'non-stick' setting. A new keyword 'stick' has been added so that to disable 'non-stick' setting both in 'server' and 'default-server' directives.
2017-03-10 09:50:49 -05:00
/* Parse the "non-stick" server keyword */
static int srv_parse_non_stick(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
newsrv->flags |= SRV_F_NON_STICK;
return 0;
}
MINOR: server: Make 'default-server' support 'send-proxy' and 'send-proxy-v2 keywords. This patch makes 'default-server' directive support 'send-proxy' (resp. 'send-proxy-v2') setting. A new keyword 'no-send-proxy' (resp. 'no-send-proxy-v2') has been added to disable 'send-proxy' (resp. 'send-proxy-v2') setting both in 'server' and 'default-server' directives.
2017-03-10 10:40:00 -05:00
/* Enable server PROXY protocol flags. */
BUILD: address a few cases of "static <type> inline foo()" Older compilers don't like to see "inline" placed after the type in a function declaration, it must be "static inline <type>" only. This patch touches various areas. The warnings were seen with gcc-3.4.
2019-04-15 15:25:03 -04:00
static inline int srv_enable_pp_flags(struct server *srv, unsigned int flags)
MINOR: server: Make 'default-server' support 'send-proxy' and 'send-proxy-v2 keywords. This patch makes 'default-server' directive support 'send-proxy' (resp. 'send-proxy-v2') setting. A new keyword 'no-send-proxy' (resp. 'no-send-proxy-v2') has been added to disable 'send-proxy' (resp. 'send-proxy-v2') setting both in 'server' and 'default-server' directives.
2017-03-10 10:40:00 -05:00
{
srv->pp_opts |= flags;
return 0;
}
MINOR: mux/server: Add 'proto' keyword to force the multiplexer's protocol For now, it is parsed but not used. Tests are done on it to check if the side and the mode are compatible with the server's definition.
2018-04-10 08:45:45 -04:00
/* parse the "proto" server keyword */
static int srv_parse_proto(char **args, int *cur_arg,
struct proxy *px, struct server *newsrv, char **err)
{
struct ist proto;
if (!*args[*cur_arg + 1]) {
memprintf(err, "'%s' : missing value", args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
}
CLEANUP: Use the ist() macro whenever possible Refactoring performed with the following Coccinelle patch: @@ char *s; @@ ( - ist2(s, strlen(s)) + ist(s) | - ist2(strdup(s), strlen(s)) + ist(strdup(s)) ) Note that this replacement is safe even in the strdup() case, because `ist()` will not call `strlen()` on a `NULL` pointer. Instead is inserts a length of `0`, effectively resulting in `IST_NULL`.
2021-03-04 11:31:47 -05:00
proto = ist(args[*cur_arg + 1]);
MINOR: mux/server: Add 'proto' keyword to force the multiplexer's protocol For now, it is parsed but not used. Tests are done on it to check if the side and the mode are compatible with the server's definition.
2018-04-10 08:45:45 -04:00
newsrv->mux_proto = get_mux_proto(proto);
if (!newsrv->mux_proto) {
memprintf(err, "'%s' : unknown MUX protocol '%s'", args[*cur_arg], args[*cur_arg+1]);
return ERR_ALERT | ERR_FATAL;
}
return 0;
}
MINOR: server: Make 'default-server' support 'send-proxy' and 'send-proxy-v2 keywords. This patch makes 'default-server' directive support 'send-proxy' (resp. 'send-proxy-v2') setting. A new keyword 'no-send-proxy' (resp. 'no-send-proxy-v2') has been added to disable 'send-proxy' (resp. 'send-proxy-v2') setting both in 'server' and 'default-server' directives.
2017-03-10 10:40:00 -05:00
MINOR: introduce proxy-v2-options for send-proxy-v2 Proxy protocol v2 can transport many optional informations. To avoid send-proxy-v2-* explosion, this patch introduce proxy-v2-options parameter and will allow to write: "send-proxy-v2 proxy-v2-options ssl,cert-cn".
2018-02-01 09:20:32 -05:00
/* parse the "proxy-v2-options" */
static int srv_parse_proxy_v2_options(char **args, int *cur_arg,
struct proxy *px, struct server *newsrv, char **err)
{
char *p, *n;
for (p = args[*cur_arg+1]; p; p = n) {
n = strchr(p, ',');
if (n)
*n++ = '\0';
CLEANUP: Compare the return value of `XXXcmp()` functions with zero According to coding-style.txt it is recommended to use: `strcmp(a, b) == 0` instead of `!strcmp(a, b)` So let's do this. The change was performed by running the following (very long) coccinelle patch on src/: @@ statement S; expression E; expression F; @@ if ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) ( S | { ... } ) @@ statement S; expression E; expression F; @@ if ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) ( S | { ... } ) @@ expression E; expression F; expression G; @@ ( G && ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( G || ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 && G ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 || G ) @@ expression E; expression F; expression G; @@ ( G && - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( G || - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 && G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 || G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 )
2021-01-02 16:31:53 -05:00
if (strcmp(p, "ssl") == 0) {
MINOR: introduce proxy-v2-options for send-proxy-v2 Proxy protocol v2 can transport many optional informations. To avoid send-proxy-v2-* explosion, this patch introduce proxy-v2-options parameter and will allow to write: "send-proxy-v2 proxy-v2-options ssl,cert-cn".
2018-02-01 09:20:32 -05:00
newsrv->pp_opts |= SRV_PP_V2_SSL;
CLEANUP: Compare the return value of `XXXcmp()` functions with zero According to coding-style.txt it is recommended to use: `strcmp(a, b) == 0` instead of `!strcmp(a, b)` So let's do this. The change was performed by running the following (very long) coccinelle patch on src/: @@ statement S; expression E; expression F; @@ if ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) ( S | { ... } ) @@ statement S; expression E; expression F; @@ if ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) ( S | { ... } ) @@ expression E; expression F; expression G; @@ ( G && ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( G || ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 && G ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 || G ) @@ expression E; expression F; expression G; @@ ( G && - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( G || - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 && G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 || G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 )
2021-01-02 16:31:53 -05:00
} else if (strcmp(p, "cert-cn") == 0) {
MINOR: introduce proxy-v2-options for send-proxy-v2 Proxy protocol v2 can transport many optional informations. To avoid send-proxy-v2-* explosion, this patch introduce proxy-v2-options parameter and will allow to write: "send-proxy-v2 proxy-v2-options ssl,cert-cn".
2018-02-01 09:20:32 -05:00
newsrv->pp_opts |= SRV_PP_V2_SSL;
newsrv->pp_opts |= SRV_PP_V2_SSL_CN;
CLEANUP: Compare the return value of `XXXcmp()` functions with zero According to coding-style.txt it is recommended to use: `strcmp(a, b) == 0` instead of `!strcmp(a, b)` So let's do this. The change was performed by running the following (very long) coccinelle patch on src/: @@ statement S; expression E; expression F; @@ if ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) ( S | { ... } ) @@ statement S; expression E; expression F; @@ if ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) ( S | { ... } ) @@ expression E; expression F; expression G; @@ ( G && ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( G || ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 && G ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 || G ) @@ expression E; expression F; expression G; @@ ( G && - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( G || - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 && G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 || G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 )
2021-01-02 16:31:53 -05:00
} else if (strcmp(p, "cert-key") == 0) {
MINOR: connection: add proxy-v2-options ssl-cipher,cert-sig,cert-key This patch implement proxy protocol v2 options related to crypto information: ssl-cipher (PP2_SUBTYPE_SSL_CIPHER), cert-sig (PP2_SUBTYPE_SSL_SIG_ALG) and cert-key (PP2_SUBTYPE_SSL_KEY_ALG).
2018-02-01 09:53:52 -05:00
newsrv->pp_opts |= SRV_PP_V2_SSL;
newsrv->pp_opts |= SRV_PP_V2_SSL_KEY_ALG;
CLEANUP: Compare the return value of `XXXcmp()` functions with zero According to coding-style.txt it is recommended to use: `strcmp(a, b) == 0` instead of `!strcmp(a, b)` So let's do this. The change was performed by running the following (very long) coccinelle patch on src/: @@ statement S; expression E; expression F; @@ if ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) ( S | { ... } ) @@ statement S; expression E; expression F; @@ if ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) ( S | { ... } ) @@ expression E; expression F; expression G; @@ ( G && ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( G || ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 && G ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 || G ) @@ expression E; expression F; expression G; @@ ( G && - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( G || - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 && G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 || G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 )
2021-01-02 16:31:53 -05:00
} else if (strcmp(p, "cert-sig") == 0) {
MINOR: connection: add proxy-v2-options ssl-cipher,cert-sig,cert-key This patch implement proxy protocol v2 options related to crypto information: ssl-cipher (PP2_SUBTYPE_SSL_CIPHER), cert-sig (PP2_SUBTYPE_SSL_SIG_ALG) and cert-key (PP2_SUBTYPE_SSL_KEY_ALG).
2018-02-01 09:53:52 -05:00
newsrv->pp_opts |= SRV_PP_V2_SSL;
newsrv->pp_opts |= SRV_PP_V2_SSL_SIG_ALG;
CLEANUP: Compare the return value of `XXXcmp()` functions with zero According to coding-style.txt it is recommended to use: `strcmp(a, b) == 0` instead of `!strcmp(a, b)` So let's do this. The change was performed by running the following (very long) coccinelle patch on src/: @@ statement S; expression E; expression F; @@ if ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) ( S | { ... } ) @@ statement S; expression E; expression F; @@ if ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) ( S | { ... } ) @@ expression E; expression F; expression G; @@ ( G && ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( G || ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 && G ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 || G ) @@ expression E; expression F; expression G; @@ ( G && - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( G || - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 && G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 || G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 )
2021-01-02 16:31:53 -05:00
} else if (strcmp(p, "ssl-cipher") == 0) {
MINOR: connection: add proxy-v2-options ssl-cipher,cert-sig,cert-key This patch implement proxy protocol v2 options related to crypto information: ssl-cipher (PP2_SUBTYPE_SSL_CIPHER), cert-sig (PP2_SUBTYPE_SSL_SIG_ALG) and cert-key (PP2_SUBTYPE_SSL_KEY_ALG).
2018-02-01 09:53:52 -05:00
newsrv->pp_opts |= SRV_PP_V2_SSL;
newsrv->pp_opts |= SRV_PP_V2_SSL_CIPHER;
CLEANUP: Compare the return value of `XXXcmp()` functions with zero According to coding-style.txt it is recommended to use: `strcmp(a, b) == 0` instead of `!strcmp(a, b)` So let's do this. The change was performed by running the following (very long) coccinelle patch on src/: @@ statement S; expression E; expression F; @@ if ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) ( S | { ... } ) @@ statement S; expression E; expression F; @@ if ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) ( S | { ... } ) @@ expression E; expression F; expression G; @@ ( G && ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( G || ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 && G ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 || G ) @@ expression E; expression F; expression G; @@ ( G && - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( G || - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 && G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 || G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 )
2021-01-02 16:31:53 -05:00
} else if (strcmp(p, "authority") == 0) {
MINOR: connection: add proxy-v2-options authority This patch add option PP2_TYPE_AUTHORITY to proxy protocol v2 when a TLS connection was negotiated. In this case, authority corresponds to the sni.
2018-02-01 12:29:59 -05:00
newsrv->pp_opts |= SRV_PP_V2_AUTHORITY;
CLEANUP: Compare the return value of `XXXcmp()` functions with zero According to coding-style.txt it is recommended to use: `strcmp(a, b) == 0` instead of `!strcmp(a, b)` So let's do this. The change was performed by running the following (very long) coccinelle patch on src/: @@ statement S; expression E; expression F; @@ if ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) ( S | { ... } ) @@ statement S; expression E; expression F; @@ if ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) ( S | { ... } ) @@ expression E; expression F; expression G; @@ ( G && ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( G || ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 && G ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 || G ) @@ expression E; expression F; expression G; @@ ( G && - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( G || - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 && G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 || G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 )
2021-01-02 16:31:53 -05:00
} else if (strcmp(p, "crc32c") == 0) {
MINOR: proxy-v2-options: add crc32c This patch add option crc32c (PP2_TYPE_CRC32C) to proxy protocol v2. It compute the checksum of proxy protocol v2 header as describe in "doc/proxy-protocol.txt".
2018-02-05 09:26:43 -05:00
newsrv->pp_opts |= SRV_PP_V2_CRC32C;
CLEANUP: Compare the return value of `XXXcmp()` functions with zero According to coding-style.txt it is recommended to use: `strcmp(a, b) == 0` instead of `!strcmp(a, b)` So let's do this. The change was performed by running the following (very long) coccinelle patch on src/: @@ statement S; expression E; expression F; @@ if ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) ( S | { ... } ) @@ statement S; expression E; expression F; @@ if ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) ( S | { ... } ) @@ expression E; expression F; expression G; @@ ( G && ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( G || ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 && G ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 || G ) @@ expression E; expression F; expression G; @@ ( G && - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( G || - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 && G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 || G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 )
2021-01-02 16:31:53 -05:00
} else if (strcmp(p, "unique-id") == 0) {
MEDIUM: proxy_protocol: Support sending unique IDs using PPv2 This patch adds the `unique-id` option to `proxy-v2-options`. If this option is set a unique ID will be generated based on the `unique-id-format` while sending the proxy protocol v2 header and stored as the unique id for the first stream of the connection. This feature is meant to be used in `tcp` mode. It works on HTTP mode, but might result in inconsistent unique IDs for the first request on a keep-alive connection, because the unique ID for the first stream is generated earlier than the others. Now that we can send unique IDs in `tcp` mode the `%ID` log variable is made available in TCP mode.
2020-03-13 07:34:24 -04:00
newsrv->pp_opts |= SRV_PP_V2_UNIQUE_ID;
MINOR: introduce proxy-v2-options for send-proxy-v2 Proxy protocol v2 can transport many optional informations. To avoid send-proxy-v2-* explosion, this patch introduce proxy-v2-options parameter and will allow to write: "send-proxy-v2 proxy-v2-options ssl,cert-cn".
2018-02-01 09:20:32 -05:00
} else
goto fail;
}
return 0;
fail:
if (err)
memprintf(err, "'%s' : proxy v2 option not implemented", p);
return ERR_ALERT | ERR_FATAL;
}
MINOR: server: Make 'default-server' support 'observe' keyword. Before this path, 'observe' setting was only supported by 'server' directives. This patch makes 'default-server' directives also support 'observe' setting. Should not break anything.
2017-03-15 03:55:39 -04:00
/* Parse the "observe" server keyword */
static int srv_parse_observe(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
char *arg;
arg = args[*cur_arg + 1];
if (!*arg) {
memprintf(err, "'%s' expects <mode> as argument.\n", args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
}
CLEANUP: Compare the return value of `XXXcmp()` functions with zero According to coding-style.txt it is recommended to use: `strcmp(a, b) == 0` instead of `!strcmp(a, b)` So let's do this. The change was performed by running the following (very long) coccinelle patch on src/: @@ statement S; expression E; expression F; @@ if ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) ( S | { ... } ) @@ statement S; expression E; expression F; @@ if ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) ( S | { ... } ) @@ expression E; expression F; expression G; @@ ( G && ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( G || ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 && G ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 || G ) @@ expression E; expression F; expression G; @@ ( G && - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( G || - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 && G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 || G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 )
2021-01-02 16:31:53 -05:00
if (strcmp(arg, "none") == 0) {
MINOR: server: Make 'default-server' support 'observe' keyword. Before this path, 'observe' setting was only supported by 'server' directives. This patch makes 'default-server' directives also support 'observe' setting. Should not break anything.
2017-03-15 03:55:39 -04:00
newsrv->observe = HANA_OBS_NONE;
}
CLEANUP: Compare the return value of `XXXcmp()` functions with zero According to coding-style.txt it is recommended to use: `strcmp(a, b) == 0` instead of `!strcmp(a, b)` So let's do this. The change was performed by running the following (very long) coccinelle patch on src/: @@ statement S; expression E; expression F; @@ if ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) ( S | { ... } ) @@ statement S; expression E; expression F; @@ if ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) ( S | { ... } ) @@ expression E; expression F; expression G; @@ ( G && ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( G || ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 && G ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 || G ) @@ expression E; expression F; expression G; @@ ( G && - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( G || - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 && G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 || G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 )
2021-01-02 16:31:53 -05:00
else if (strcmp(arg, "layer4") == 0) {
MINOR: server: Make 'default-server' support 'observe' keyword. Before this path, 'observe' setting was only supported by 'server' directives. This patch makes 'default-server' directives also support 'observe' setting. Should not break anything.
2017-03-15 03:55:39 -04:00
newsrv->observe = HANA_OBS_LAYER4;
}
CLEANUP: Compare the return value of `XXXcmp()` functions with zero According to coding-style.txt it is recommended to use: `strcmp(a, b) == 0` instead of `!strcmp(a, b)` So let's do this. The change was performed by running the following (very long) coccinelle patch on src/: @@ statement S; expression E; expression F; @@ if ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) ( S | { ... } ) @@ statement S; expression E; expression F; @@ if ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) ( S | { ... } ) @@ expression E; expression F; expression G; @@ ( G && ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( G || ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 && G ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 || G ) @@ expression E; expression F; expression G; @@ ( G && - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( G || - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 && G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 || G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 )
2021-01-02 16:31:53 -05:00
else if (strcmp(arg, "layer7") == 0) {
MINOR: server: Make 'default-server' support 'observe' keyword. Before this path, 'observe' setting was only supported by 'server' directives. This patch makes 'default-server' directives also support 'observe' setting. Should not break anything.
2017-03-15 03:55:39 -04:00
if (curproxy->mode != PR_MODE_HTTP) {
memprintf(err, "'%s' can only be used in http proxies.\n", arg);
return ERR_ALERT;
}
newsrv->observe = HANA_OBS_LAYER7;
}
else {
memprintf(err, "'%s' expects one of 'none', 'layer4', 'layer7' "
"but got '%s'\n", args[*cur_arg], arg);
return ERR_ALERT | ERR_FATAL;
}
return 0;
}
REORG: server: move keywords in srv_kws Move server-keyword hardcoded in parse_server into the srv_kws list of server.c. Now every server keywords is checked through srv_find_kw. This has the effect to reduce the size of parse_server. As a side-effect, common kw list can be reduced. This change has been made to be able to quickly discard these keywords in case of a dynamic server.
2021-03-10 10:36:02 -05:00
/* Parse the "on-error" server keyword */
static int srv_parse_on_error(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
if (strcmp(args[*cur_arg + 1], "fastinter") == 0)
newsrv->onerror = HANA_ONERR_FASTINTER;
else if (strcmp(args[*cur_arg + 1], "fail-check") == 0)
newsrv->onerror = HANA_ONERR_FAILCHK;
else if (strcmp(args[*cur_arg + 1], "sudden-death") == 0)
newsrv->onerror = HANA_ONERR_SUDDTH;
else if (strcmp(args[*cur_arg + 1], "mark-down") == 0)
newsrv->onerror = HANA_ONERR_MARKDWN;
else {
memprintf(err, "'%s' expects one of 'fastinter', "
"'fail-check', 'sudden-death' or 'mark-down' but got '%s'",
args[*cur_arg], args[*cur_arg + 1]);
return ERR_ALERT | ERR_FATAL;
}
return 0;
}
/* Parse the "on-marked-down" server keyword */
static int srv_parse_on_marked_down(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
if (strcmp(args[*cur_arg + 1], "shutdown-sessions") == 0)
newsrv->onmarkeddown = HANA_ONMARKEDDOWN_SHUTDOWNSESSIONS;
else {
memprintf(err, "'%s' expects 'shutdown-sessions' but got '%s'",
args[*cur_arg], args[*cur_arg + 1]);
return ERR_ALERT | ERR_FATAL;
}
return 0;
}
/* Parse the "on-marked-up" server keyword */
static int srv_parse_on_marked_up(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
if (strcmp(args[*cur_arg + 1], "shutdown-backup-sessions") == 0)
newsrv->onmarkedup = HANA_ONMARKEDUP_SHUTDOWNBACKUPSESSIONS;
else {
memprintf(err, "'%s' expects 'shutdown-backup-sessions' but got '%s'",
args[*cur_arg], args[*cur_arg + 1]);
return ERR_ALERT | ERR_FATAL;
}
return 0;
}
MINOR: server: Make 'default-server' support 'redir' keyword. Before this patch only 'server' directives could support 'redir' setting. This patch makes also 'default-server' directives support 'redir' setting. Should not break anything.
2017-03-14 11:42:49 -04:00
/* Parse the "redir" server keyword */
static int srv_parse_redir(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
char *arg;
arg = args[*cur_arg + 1];
if (!*arg) {
memprintf(err, "'%s' expects <prefix> as argument.\n", args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
}
free(newsrv->rdr_pfx);
newsrv->rdr_pfx = strdup(arg);
newsrv->rdr_len = strlen(arg);
return 0;
}
REORG: server: move keywords in srv_kws Move server-keyword hardcoded in parse_server into the srv_kws list of server.c. Now every server keywords is checked through srv_find_kw. This has the effect to reduce the size of parse_server. As a side-effect, common kw list can be reduced. This change has been made to be able to quickly discard these keywords in case of a dynamic server.
2021-03-10 10:36:02 -05:00
/* Parse the "resolvers" server keyword */
static int srv_parse_resolvers(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
free(newsrv->resolvers_id);
newsrv->resolvers_id = strdup(args[*cur_arg + 1]);
return 0;
}
/* Parse the "resolve-net" server keyword */
static int srv_parse_resolve_net(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
char *p, *e;
unsigned char mask;
struct resolv_options *opt;
if (!args[*cur_arg + 1] || args[*cur_arg + 1][0] == '\0') {
memprintf(err, "'%s' expects a list of networks.",
args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
}
opt = &newsrv->resolv_opts;
/* Split arguments by comma, and convert it from ipv4 or ipv6
* string network in in_addr or in6_addr.
*/
p = args[*cur_arg + 1];
e = p;
while (*p != '\0') {
/* If no room available, return error. */
if (opt->pref_net_nb >= SRV_MAX_PREF_NET) {
memprintf(err, "'%s' exceed %d networks.",
args[*cur_arg], SRV_MAX_PREF_NET);
return ERR_ALERT | ERR_FATAL;
}
/* look for end or comma. */
while (*e != ',' && *e != '\0')
e++;
if (*e == ',') {
*e = '\0';
e++;
}
if (str2net(p, 0, &opt->pref_net[opt->pref_net_nb].addr.in4,
&opt->pref_net[opt->pref_net_nb].mask.in4)) {
/* Try to convert input string from ipv4 or ipv6 network. */
opt->pref_net[opt->pref_net_nb].family = AF_INET;
} else if (str62net(p, &opt->pref_net[opt->pref_net_nb].addr.in6,
&mask)) {
/* Try to convert input string from ipv6 network. */
len2mask6(mask, &opt->pref_net[opt->pref_net_nb].mask.in6);
opt->pref_net[opt->pref_net_nb].family = AF_INET6;
} else {
/* All network conversions fail, return error. */
memprintf(err, "'%s' invalid network '%s'.",
args[*cur_arg], p);
return ERR_ALERT | ERR_FATAL;
}
opt->pref_net_nb++;
p = e;
}
return 0;
}
/* Parse the "resolve-opts" server keyword */
static int srv_parse_resolve_opts(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
char *p, *end;
for (p = args[*cur_arg + 1]; *p; p = end) {
/* cut on next comma */
for (end = p; *end && *end != ','; end++);
if (*end)
*(end++) = 0;
if (strcmp(p, "allow-dup-ip") == 0) {
newsrv->resolv_opts.accept_duplicate_ip = 1;
}
else if (strcmp(p, "ignore-weight") == 0) {
newsrv->resolv_opts.ignore_weight = 1;
}
else if (strcmp(p, "prevent-dup-ip") == 0) {
newsrv->resolv_opts.accept_duplicate_ip = 0;
}
else {
memprintf(err, "'%s' : unknown resolve-opts option '%s', supported methods are 'allow-dup-ip', 'ignore-weight', and 'prevent-dup-ip'.",
args[*cur_arg], p);
return ERR_ALERT | ERR_FATAL;
}
}
return 0;
}
/* Parse the "resolve-prefer" server keyword */
static int srv_parse_resolve_prefer(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
if (strcmp(args[*cur_arg + 1], "ipv4") == 0)
newsrv->resolv_opts.family_prio = AF_INET;
else if (strcmp(args[*cur_arg + 1], "ipv6") == 0)
newsrv->resolv_opts.family_prio = AF_INET6;
else {
memprintf(err, "'%s' expects either ipv4 or ipv6 as argument.",
args[*cur_arg]);
return ERR_ALERT | ERR_FATAL;
}
return 0;
}
MINOR: server: Make 'default-server' support 'send-proxy' and 'send-proxy-v2 keywords. This patch makes 'default-server' directive support 'send-proxy' (resp. 'send-proxy-v2') setting. A new keyword 'no-send-proxy' (resp. 'no-send-proxy-v2') has been added to disable 'send-proxy' (resp. 'send-proxy-v2') setting both in 'server' and 'default-server' directives.
2017-03-10 10:40:00 -05:00
/* Parse the "send-proxy" server keyword */
static int srv_parse_send_proxy(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
return srv_enable_pp_flags(newsrv, SRV_PP_V1);
}
/* Parse the "send-proxy-v2" server keyword */
static int srv_parse_send_proxy_v2(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
return srv_enable_pp_flags(newsrv, SRV_PP_V2);
}
MINOR: server: Add parser support for set-proxy-v2-tlv-fmt This commit introduces a generic server-side parsing of type-value pair arguments and allocation of a TLV list via a new keyword called set-proxy-v2-tlv-fmt. This allows to 1) forward any TLV type with the help of fc_pp_tlv, 2) generally, send out any TLV type and value via a log format expression. To have this fully working the connection will need to be updated in a follow-up commit to actually respect the new server TLV list. default-server support has also been implemented.
2023-10-28 14:51:26 -04:00
/* Parse the "set-proxy-v2-tlv-fmt" server keyword */
static int srv_parse_set_proxy_v2_tlv_fmt(char **args, int *cur_arg,
struct proxy *px, struct server *newsrv, char **err)
{
char *error = NULL, *cmd = NULL;
unsigned int tlv_type = 0;
struct srv_pp_tlv_list *srv_tlv = NULL;
cmd = args[*cur_arg];
if (!*cmd) {
memprintf(err, "'%s' : could not read set-proxy-v2-tlv-fmt command", args[*cur_arg]);
goto fail;
}
cmd += strlen("set-proxy-v2-tlv-fmt");
if (*cmd == '(') {
cmd++; /* skip the '(' */
errno = 0;
tlv_type = strtoul(cmd, &error, 0); /* convert TLV ID */
if (unlikely((cmd == error) || (errno != 0))) {
memprintf(err, "'%s' : could not convert TLV ID", args[*cur_arg]);
goto fail;
}
if (errno == EINVAL) {
memprintf(err, "'%s' : could not find a valid number for the TLV ID", args[*cur_arg]);
goto fail;
}
if (*error != ')') {
memprintf(err, "'%s' : expects set-proxy-v2-tlv(<TLV ID>)", args[*cur_arg]);
goto fail;
}
if (tlv_type > 0xFF) {
memprintf(err, "'%s' : the maximum allowed TLV ID is %d", args[*cur_arg], 0xFF);
goto fail;
}
}
CLEANUP: Re-apply xalloc_size.cocci (3) This reapplies the xalloc_size.cocci patch across the whole `src/` tree. see 16cc16dd8235e7eb6c38b7abd210bd1e1d96b1d9 see 63ee0e4c01b94aee5fc6c6dd98cfc4480ae5ea46 see 9fb57e8c175a0b852b06a0780f48eb8eaf321a47
2023-11-05 14:02:37 -05:00
srv_tlv = malloc(sizeof(*srv_tlv));
MINOR: server: Add parser support for set-proxy-v2-tlv-fmt This commit introduces a generic server-side parsing of type-value pair arguments and allocation of a TLV list via a new keyword called set-proxy-v2-tlv-fmt. This allows to 1) forward any TLV type with the help of fc_pp_tlv, 2) generally, send out any TLV type and value via a log format expression. To have this fully working the connection will need to be updated in a follow-up commit to actually respect the new server TLV list. default-server support has also been implemented.
2023-10-28 14:51:26 -04:00
if (unlikely(!srv_tlv)) {
memprintf(err, "'%s' : failed to parse allocate TLV entry", args[*cur_arg]);
goto fail;
}
srv_tlv->type = tlv_type;
BUG/MEDIUM: server: properly initialize PROXY v2 TLVs The PROXY v2 TLVs were not properly initialized when defined with "set-proxy-v2-tlv-fmt" keyword, which could have caused a crash when validating the configuration or malfunction (e.g. when used in combination with "server-template" and/or "default-server"). The issue was introduced with commit 6f4bfed3a ("MINOR: server: Add parser support for set-proxy-v2-tlv-fmt"). This should be backported up to 2.9.
2025-02-26 13:13:31 -05:00
lf_expr_init(&srv_tlv->fmt);
MINOR: server: Add parser support for set-proxy-v2-tlv-fmt This commit introduces a generic server-side parsing of type-value pair arguments and allocation of a TLV list via a new keyword called set-proxy-v2-tlv-fmt. This allows to 1) forward any TLV type with the help of fc_pp_tlv, 2) generally, send out any TLV type and value via a log format expression. To have this fully working the connection will need to be updated in a follow-up commit to actually respect the new server TLV list. default-server support has also been implemented.
2023-10-28 14:51:26 -04:00
srv_tlv->fmt_string = strdup(args[*cur_arg + 1]);
if (unlikely(!srv_tlv->fmt_string)) {
memprintf(err, "'%s' : failed to save format string for parsing", args[*cur_arg]);
goto fail;
}
LIST_APPEND(&newsrv->pp_tlvs, &srv_tlv->list);
(*cur_arg)++;
return 0;
fail:
free(srv_tlv);
errno = 0;
return ERR_ALERT | ERR_FATAL;
}
REORG: server: move keywords in srv_kws Move server-keyword hardcoded in parse_server into the srv_kws list of server.c. Now every server keywords is checked through srv_find_kw. This has the effect to reduce the size of parse_server. As a side-effect, common kw list can be reduced. This change has been made to be able to quickly discard these keywords in case of a dynamic server.
2021-03-10 10:36:02 -05:00
/* Parse the "slowstart" server keyword */
static int srv_parse_slowstart(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
/* slowstart is stored in seconds */
unsigned int val;
const char *time_err = parse_time_err(args[*cur_arg + 1], &val, TIME_UNIT_MS);
if (time_err == PARSE_TIME_OVER) {
memprintf(err, "overflow in argument <%s> to <%s> of server %s, maximum value is 2147483647 ms (~24.8 days).",
args[*cur_arg+1], args[*cur_arg], newsrv->id);
return ERR_ALERT | ERR_FATAL;
}
else if (time_err == PARSE_TIME_UNDER) {
memprintf(err, "underflow in argument <%s> to <%s> of server %s, minimum non-null value is 1 ms.",
args[*cur_arg+1], args[*cur_arg], newsrv->id);
return ERR_ALERT | ERR_FATAL;
}
else if (time_err) {
memprintf(err, "unexpected character '%c' in 'slowstart' argument of server %s.",
*time_err, newsrv->id);
return ERR_ALERT | ERR_FATAL;
}
newsrv->slowstart = (val + 999) / 1000;
return 0;
}
MINOR: server: Make 'default-server' support 'source' keyword. Before this patch, only 'server' directives could support 'source' setting. This patch makes also 'default-server' directives support this setting. To do so, we had to extract the code responsible of parsing 'source' setting arguments from parse_server() function and make it callable both as 'default-server' and 'server' 'source' setting parser. So, the code is mostly the same as before except that before allocating anything for 'struct conn_src' members, we must free the memory previously allocated. Should not break anything.
2017-03-17 10:33:50 -04:00
/* Parse the "source" server keyword */
static int srv_parse_source(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
char *errmsg;
int port_low, port_high;
struct sockaddr_storage *sk;
errmsg = NULL;
if (!*args[*cur_arg + 1]) {
memprintf(err, "'%s' expects <addr>[:<port>[-<port>]], and optionally '%s' <addr>, "
"and '%s' <name> as argument.\n", args[*cur_arg], "usesrc", "interface");
goto err;
}
/* 'sk' is statically allocated (no need to be freed). */
MINOR: tools: make str2sa_range() directly return type hints str2sa_range() already allows the caller to provide <proto> in order to get a pointer on the protocol matching with the string input thanks to 5fc9328a ("MINOR: tools: make str2sa_range() directly return the protocol") However, as stated into the commit message, there is a trick: "we can fail to return a protocol in case the caller accepts an fqdn for use later. This is what servers do and in this case it is valid to return no protocol" In this case, we're unable to return protocol because the protocol lookup depends on both the [proto type + xprt type] and the [family type] to be known. While family type might not be directly resolved when fqdn is involved (because family type might be discovered using DNS queries), proto type and xprt type are already known. As such, the caller might be interested in knowing those address related hints even if the address family type is not yet resolved and thus the matching protocol cannot be looked up. Thus in this patch we add the optional net_addr_type (custom type) argument to str2sa_range to enable the caller to check the protocol type and transport type when the function succeeds.
2023-11-09 05:19:24 -05:00
sk = str2sa_range(args[*cur_arg + 1], NULL, &port_low, &port_high, NULL, NULL, NULL,
MINOR: tools: extend str2sa_range to add an alt parameter Add a new parameter "alt" that will store wether this configuration use an alternate protocol. This alt pointer will contain a value that can be transparently passed to protocol_lookup to obtain an appropriate protocol structure. This change is needed to allow for example the servers to know if it need to use an alternate protocol or not.
2024-08-26 05:50:24 -04:00
&errmsg, NULL, NULL, NULL,
MEDIUM: tools: make str2sa_range() check that the protocol has ->connect() Most callers of str2sa_range() need the protocol only to check that it provides a ->connect() method. It used to be used to verify that it's a stream protocol, but it might be a bit early to get rid of it. Let's keep the test for now but move it to str2sa_range() when the new flag PA_O_CONNECT is present. This way almost all call places could be cleaned from this. There's a strange test in the server address parsing code that rechecks the family from the socket which seems to be a duplicate of the previously removed tests. It will have to be rechecked.
2020-09-16 13:17:08 -04:00
PA_O_RESOLVE | PA_O_PORT_OK | PA_O_PORT_RANGE | PA_O_STREAM | PA_O_CONNECT);
MINOR: server: Make 'default-server' support 'source' keyword. Before this patch, only 'server' directives could support 'source' setting. This patch makes also 'default-server' directives support this setting. To do so, we had to extract the code responsible of parsing 'source' setting arguments from parse_server() function and make it callable both as 'default-server' and 'server' 'source' setting parser. So, the code is mostly the same as before except that before allocating anything for 'struct conn_src' members, we must free the memory previously allocated. Should not break anything.
2017-03-17 10:33:50 -04:00
if (!sk) {
memprintf(err, "'%s %s' : %s\n", args[*cur_arg], args[*cur_arg + 1], errmsg);
goto err;
}
newsrv->conn_src.opts |= CO_SRC_BIND;
newsrv->conn_src.source_addr = *sk;
if (port_low != port_high) {
int i;
newsrv->conn_src.sport_range = port_range_alloc_range(port_high - port_low + 1);
BUG/MINOR: server: Missing calloc return value check in srv_parse_source Two calloc calls were not checked in the srv_parse_source function. Considering that this function could be called at runtime through a dynamic server creation via the CLI, this could lead to an unfortunate crash. It was raised in GitHub issue #1233. It could be backported to all stable branches even though the runtime crash could only happen on branches where dynamic server creation is possible.
2021-05-12 03:44:06 -04:00
if (!newsrv->conn_src.sport_range) {
ha_alert("Server '%s': Out of memory (sport_range)\n", args[0]);
goto err;
}
MINOR: server: Make 'default-server' support 'source' keyword. Before this patch, only 'server' directives could support 'source' setting. This patch makes also 'default-server' directives support this setting. To do so, we had to extract the code responsible of parsing 'source' setting arguments from parse_server() function and make it callable both as 'default-server' and 'server' 'source' setting parser. So, the code is mostly the same as before except that before allocating anything for 'struct conn_src' members, we must free the memory previously allocated. Should not break anything.
2017-03-17 10:33:50 -04:00
for (i = 0; i < newsrv->conn_src.sport_range->size; i++)
newsrv->conn_src.sport_range->ports[i] = port_low + i;
}
*cur_arg += 2;
while (*(args[*cur_arg])) {
CLEANUP: Compare the return value of `XXXcmp()` functions with zero According to coding-style.txt it is recommended to use: `strcmp(a, b) == 0` instead of `!strcmp(a, b)` So let's do this. The change was performed by running the following (very long) coccinelle patch on src/: @@ statement S; expression E; expression F; @@ if ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) ( S | { ... } ) @@ statement S; expression E; expression F; @@ if ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) ( S | { ... } ) @@ expression E; expression F; expression G; @@ ( G && ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( G || ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 && G ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 || G ) @@ expression E; expression F; expression G; @@ ( G && - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( G || - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 && G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 || G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 )
2021-01-02 16:31:53 -05:00
if (strcmp(args[*cur_arg], "usesrc") == 0) { /* address to use outside */
MINOR: server: Make 'default-server' support 'source' keyword. Before this patch, only 'server' directives could support 'source' setting. This patch makes also 'default-server' directives support this setting. To do so, we had to extract the code responsible of parsing 'source' setting arguments from parse_server() function and make it callable both as 'default-server' and 'server' 'source' setting parser. So, the code is mostly the same as before except that before allocating anything for 'struct conn_src' members, we must free the memory previously allocated. Should not break anything.
2017-03-17 10:33:50 -04:00
#if defined(CONFIG_HAP_TRANSPARENT)
if (!*args[*cur_arg + 1]) {
CLEANUP: log: Rename Alert/Warning in ha_alert/ha_warning
2017-11-24 10:50:31 -05:00
ha_alert("'usesrc' expects <addr>[:<port>], 'client', 'clientip', "
"or 'hdr_ip(name,#)' as argument.\n");
MINOR: server: Make 'default-server' support 'source' keyword. Before this patch, only 'server' directives could support 'source' setting. This patch makes also 'default-server' directives support this setting. To do so, we had to extract the code responsible of parsing 'source' setting arguments from parse_server() function and make it callable both as 'default-server' and 'server' 'source' setting parser. So, the code is mostly the same as before except that before allocating anything for 'struct conn_src' members, we must free the memory previously allocated. Should not break anything.
2017-03-17 10:33:50 -04:00
goto err;
}
CLEANUP: Compare the return value of `XXXcmp()` functions with zero According to coding-style.txt it is recommended to use: `strcmp(a, b) == 0` instead of `!strcmp(a, b)` So let's do this. The change was performed by running the following (very long) coccinelle patch on src/: @@ statement S; expression E; expression F; @@ if ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) ( S | { ... } ) @@ statement S; expression E; expression F; @@ if ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) ( S | { ... } ) @@ expression E; expression F; expression G; @@ ( G && ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( G || ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 && G ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 || G ) @@ expression E; expression F; expression G; @@ ( G && - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( G || - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 && G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 || G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 )
2021-01-02 16:31:53 -05:00
if (strcmp(args[*cur_arg + 1], "client") == 0) {
MINOR: server: Make 'default-server' support 'source' keyword. Before this patch, only 'server' directives could support 'source' setting. This patch makes also 'default-server' directives support this setting. To do so, we had to extract the code responsible of parsing 'source' setting arguments from parse_server() function and make it callable both as 'default-server' and 'server' 'source' setting parser. So, the code is mostly the same as before except that before allocating anything for 'struct conn_src' members, we must free the memory previously allocated. Should not break anything.
2017-03-17 10:33:50 -04:00
newsrv->conn_src.opts &= ~CO_SRC_TPROXY_MASK;
newsrv->conn_src.opts |= CO_SRC_TPROXY_CLI;
}
CLEANUP: Compare the return value of `XXXcmp()` functions with zero According to coding-style.txt it is recommended to use: `strcmp(a, b) == 0` instead of `!strcmp(a, b)` So let's do this. The change was performed by running the following (very long) coccinelle patch on src/: @@ statement S; expression E; expression F; @@ if ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) ( S | { ... } ) @@ statement S; expression E; expression F; @@ if ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) ( S | { ... } ) @@ expression E; expression F; expression G; @@ ( G && ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( G || ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 && G ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 || G ) @@ expression E; expression F; expression G; @@ ( G && - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( G || - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 && G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 || G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 )
2021-01-02 16:31:53 -05:00
else if (strcmp(args[*cur_arg + 1], "clientip") == 0) {
MINOR: server: Make 'default-server' support 'source' keyword. Before this patch, only 'server' directives could support 'source' setting. This patch makes also 'default-server' directives support this setting. To do so, we had to extract the code responsible of parsing 'source' setting arguments from parse_server() function and make it callable both as 'default-server' and 'server' 'source' setting parser. So, the code is mostly the same as before except that before allocating anything for 'struct conn_src' members, we must free the memory previously allocated. Should not break anything.
2017-03-17 10:33:50 -04:00
newsrv->conn_src.opts &= ~CO_SRC_TPROXY_MASK;
newsrv->conn_src.opts |= CO_SRC_TPROXY_CIP;
}
else if (!strncmp(args[*cur_arg + 1], "hdr_ip(", 7)) {
char *name, *end;
name = args[*cur_arg + 1] + 7;
BUILD: general: always pass unsigned chars to is* functions The isalnum(), isalpha(), isdigit() etc functions from ctype.h are supposed to take an int in argument which must either reflect an unsigned char or EOF. In practice on some platforms they're implemented as macros referencing an array, and when passed a char, they either cause a warning "array subscript has type 'char'" when lucky, or cause random segfaults when unlucky. It's quite unconvenient by the way since none of them may return true for negative values. The recent introduction of cygwin to the list of regularly tested build platforms revealed a lot of breakage there due to the same issues again. So this patch addresses the problem all over the code at once. It adds unsigned char casts to every valid use case, and also drops the unneeded double cast to int that was sometimes added on top of it. It may be backported by dropping irrelevant changes if that helps better support uncommon platforms. It's unlikely to fix bugs on platforms which would already not emit any warning though.
2020-02-25 02:16:33 -05:00
while (isspace((unsigned char)*name))
MINOR: server: Make 'default-server' support 'source' keyword. Before this patch, only 'server' directives could support 'source' setting. This patch makes also 'default-server' directives support this setting. To do so, we had to extract the code responsible of parsing 'source' setting arguments from parse_server() function and make it callable both as 'default-server' and 'server' 'source' setting parser. So, the code is mostly the same as before except that before allocating anything for 'struct conn_src' members, we must free the memory previously allocated. Should not break anything.
2017-03-17 10:33:50 -04:00
name++;
end = name;
BUILD: general: always pass unsigned chars to is* functions The isalnum(), isalpha(), isdigit() etc functions from ctype.h are supposed to take an int in argument which must either reflect an unsigned char or EOF. In practice on some platforms they're implemented as macros referencing an array, and when passed a char, they either cause a warning "array subscript has type 'char'" when lucky, or cause random segfaults when unlucky. It's quite unconvenient by the way since none of them may return true for negative values. The recent introduction of cygwin to the list of regularly tested build platforms revealed a lot of breakage there due to the same issues again. So this patch addresses the problem all over the code at once. It adds unsigned char casts to every valid use case, and also drops the unneeded double cast to int that was sometimes added on top of it. It may be backported by dropping irrelevant changes if that helps better support uncommon platforms. It's unlikely to fix bugs on platforms which would already not emit any warning though.
2020-02-25 02:16:33 -05:00
while (*end && !isspace((unsigned char)*end) && *end != ',' && *end != ')')
MINOR: server: Make 'default-server' support 'source' keyword. Before this patch, only 'server' directives could support 'source' setting. This patch makes also 'default-server' directives support this setting. To do so, we had to extract the code responsible of parsing 'source' setting arguments from parse_server() function and make it callable both as 'default-server' and 'server' 'source' setting parser. So, the code is mostly the same as before except that before allocating anything for 'struct conn_src' members, we must free the memory previously allocated. Should not break anything.
2017-03-17 10:33:50 -04:00
end++;
newsrv->conn_src.opts &= ~CO_SRC_TPROXY_MASK;
newsrv->conn_src.opts |= CO_SRC_TPROXY_DYN;
free(newsrv->conn_src.bind_hdr_name);
newsrv->conn_src.bind_hdr_name = calloc(1, end - name + 1);
BUG/MINOR: server: Missing calloc return value check in srv_parse_source Two calloc calls were not checked in the srv_parse_source function. Considering that this function could be called at runtime through a dynamic server creation via the CLI, this could lead to an unfortunate crash. It was raised in GitHub issue #1233. It could be backported to all stable branches even though the runtime crash could only happen on branches where dynamic server creation is possible.
2021-05-12 03:44:06 -04:00
if (!newsrv->conn_src.bind_hdr_name) {
ha_alert("Server '%s': Out of memory (bind_hdr_name)\n", args[0]);
goto err;
}
MINOR: server: Make 'default-server' support 'source' keyword. Before this patch, only 'server' directives could support 'source' setting. This patch makes also 'default-server' directives support this setting. To do so, we had to extract the code responsible of parsing 'source' setting arguments from parse_server() function and make it callable both as 'default-server' and 'server' 'source' setting parser. So, the code is mostly the same as before except that before allocating anything for 'struct conn_src' members, we must free the memory previously allocated. Should not break anything.
2017-03-17 10:33:50 -04:00
newsrv->conn_src.bind_hdr_len = end - name;
memcpy(newsrv->conn_src.bind_hdr_name, name, end - name);
newsrv->conn_src.bind_hdr_name[end - name] = '\0';
newsrv->conn_src.bind_hdr_occ = -1;
/* now look for an occurrence number */
BUILD: general: always pass unsigned chars to is* functions The isalnum(), isalpha(), isdigit() etc functions from ctype.h are supposed to take an int in argument which must either reflect an unsigned char or EOF. In practice on some platforms they're implemented as macros referencing an array, and when passed a char, they either cause a warning "array subscript has type 'char'" when lucky, or cause random segfaults when unlucky. It's quite unconvenient by the way since none of them may return true for negative values. The recent introduction of cygwin to the list of regularly tested build platforms revealed a lot of breakage there due to the same issues again. So this patch addresses the problem all over the code at once. It adds unsigned char casts to every valid use case, and also drops the unneeded double cast to int that was sometimes added on top of it. It may be backported by dropping irrelevant changes if that helps better support uncommon platforms. It's unlikely to fix bugs on platforms which would already not emit any warning though.
2020-02-25 02:16:33 -05:00
while (isspace((unsigned char)*end))
MINOR: server: Make 'default-server' support 'source' keyword. Before this patch, only 'server' directives could support 'source' setting. This patch makes also 'default-server' directives support this setting. To do so, we had to extract the code responsible of parsing 'source' setting arguments from parse_server() function and make it callable both as 'default-server' and 'server' 'source' setting parser. So, the code is mostly the same as before except that before allocating anything for 'struct conn_src' members, we must free the memory previously allocated. Should not break anything.
2017-03-17 10:33:50 -04:00
end++;
if (*end == ',') {
end++;
name = end;
if (*end == '-')
end++;
BUILD: general: always pass unsigned chars to is* functions The isalnum(), isalpha(), isdigit() etc functions from ctype.h are supposed to take an int in argument which must either reflect an unsigned char or EOF. In practice on some platforms they're implemented as macros referencing an array, and when passed a char, they either cause a warning "array subscript has type 'char'" when lucky, or cause random segfaults when unlucky. It's quite unconvenient by the way since none of them may return true for negative values. The recent introduction of cygwin to the list of regularly tested build platforms revealed a lot of breakage there due to the same issues again. So this patch addresses the problem all over the code at once. It adds unsigned char casts to every valid use case, and also drops the unneeded double cast to int that was sometimes added on top of it. It may be backported by dropping irrelevant changes if that helps better support uncommon platforms. It's unlikely to fix bugs on platforms which would already not emit any warning though.
2020-02-25 02:16:33 -05:00
while (isdigit((unsigned char)*end))
MINOR: server: Make 'default-server' support 'source' keyword. Before this patch, only 'server' directives could support 'source' setting. This patch makes also 'default-server' directives support this setting. To do so, we had to extract the code responsible of parsing 'source' setting arguments from parse_server() function and make it callable both as 'default-server' and 'server' 'source' setting parser. So, the code is mostly the same as before except that before allocating anything for 'struct conn_src' members, we must free the memory previously allocated. Should not break anything.
2017-03-17 10:33:50 -04:00
end++;
newsrv->conn_src.bind_hdr_occ = strl2ic(name, end - name);
}
if (newsrv->conn_src.bind_hdr_occ < -MAX_HDR_HISTORY) {
CLEANUP: log: Rename Alert/Warning in ha_alert/ha_warning
2017-11-24 10:50:31 -05:00
ha_alert("usesrc hdr_ip(name,num) does not support negative"
" occurrences values smaller than %d.\n", MAX_HDR_HISTORY);
MINOR: server: Make 'default-server' support 'source' keyword. Before this patch, only 'server' directives could support 'source' setting. This patch makes also 'default-server' directives support this setting. To do so, we had to extract the code responsible of parsing 'source' setting arguments from parse_server() function and make it callable both as 'default-server' and 'server' 'source' setting parser. So, the code is mostly the same as before except that before allocating anything for 'struct conn_src' members, we must free the memory previously allocated. Should not break anything.
2017-03-17 10:33:50 -04:00
goto err;
}
}
else {
struct sockaddr_storage *sk;
int port1, port2;
/* 'sk' is statically allocated (no need to be freed). */
MINOR: tools: make str2sa_range() directly return type hints str2sa_range() already allows the caller to provide <proto> in order to get a pointer on the protocol matching with the string input thanks to 5fc9328a ("MINOR: tools: make str2sa_range() directly return the protocol") However, as stated into the commit message, there is a trick: "we can fail to return a protocol in case the caller accepts an fqdn for use later. This is what servers do and in this case it is valid to return no protocol" In this case, we're unable to return protocol because the protocol lookup depends on both the [proto type + xprt type] and the [family type] to be known. While family type might not be directly resolved when fqdn is involved (because family type might be discovered using DNS queries), proto type and xprt type are already known. As such, the caller might be interested in knowing those address related hints even if the address family type is not yet resolved and thus the matching protocol cannot be looked up. Thus in this patch we add the optional net_addr_type (custom type) argument to str2sa_range to enable the caller to check the protocol type and transport type when the function succeeds.
2023-11-09 05:19:24 -05:00
sk = str2sa_range(args[*cur_arg + 1], NULL, &port1, &port2, NULL, NULL, NULL,
MINOR: tools: extend str2sa_range to add an alt parameter Add a new parameter "alt" that will store wether this configuration use an alternate protocol. This alt pointer will contain a value that can be transparently passed to protocol_lookup to obtain an appropriate protocol structure. This change is needed to allow for example the servers to know if it need to use an alternate protocol or not.
2024-08-26 05:50:24 -04:00
&errmsg, NULL, NULL, NULL,
MEDIUM: tools: make str2sa_range() check that the protocol has ->connect() Most callers of str2sa_range() need the protocol only to check that it provides a ->connect() method. It used to be used to verify that it's a stream protocol, but it might be a bit early to get rid of it. Let's keep the test for now but move it to str2sa_range() when the new flag PA_O_CONNECT is present. This way almost all call places could be cleaned from this. There's a strange test in the server address parsing code that rechecks the family from the socket which seems to be a duplicate of the previously removed tests. It will have to be rechecked.
2020-09-16 13:17:08 -04:00
PA_O_RESOLVE | PA_O_PORT_OK | PA_O_STREAM | PA_O_CONNECT);
MINOR: server: Make 'default-server' support 'source' keyword. Before this patch, only 'server' directives could support 'source' setting. This patch makes also 'default-server' directives support this setting. To do so, we had to extract the code responsible of parsing 'source' setting arguments from parse_server() function and make it callable both as 'default-server' and 'server' 'source' setting parser. So, the code is mostly the same as before except that before allocating anything for 'struct conn_src' members, we must free the memory previously allocated. Should not break anything.
2017-03-17 10:33:50 -04:00
if (!sk) {
CLEANUP: log: Rename Alert/Warning in ha_alert/ha_warning
2017-11-24 10:50:31 -05:00
ha_alert("'%s %s' : %s\n", args[*cur_arg], args[*cur_arg + 1], errmsg);
MINOR: server: Make 'default-server' support 'source' keyword. Before this patch, only 'server' directives could support 'source' setting. This patch makes also 'default-server' directives support this setting. To do so, we had to extract the code responsible of parsing 'source' setting arguments from parse_server() function and make it callable both as 'default-server' and 'server' 'source' setting parser. So, the code is mostly the same as before except that before allocating anything for 'struct conn_src' members, we must free the memory previously allocated. Should not break anything.
2017-03-17 10:33:50 -04:00
goto err;
}
newsrv->conn_src.tproxy_addr = *sk;
newsrv->conn_src.opts |= CO_SRC_TPROXY_ADDR;
}
global.last_checks |= LSTCHK_NETADM;
*cur_arg += 2;
continue;
#else /* no TPROXY support */
CLEANUP: log: Rename Alert/Warning in ha_alert/ha_warning
2017-11-24 10:50:31 -05:00
ha_alert("'usesrc' not allowed here because support for TPROXY was not compiled in.\n");
MINOR: server: Make 'default-server' support 'source' keyword. Before this patch, only 'server' directives could support 'source' setting. This patch makes also 'default-server' directives support this setting. To do so, we had to extract the code responsible of parsing 'source' setting arguments from parse_server() function and make it callable both as 'default-server' and 'server' 'source' setting parser. So, the code is mostly the same as before except that before allocating anything for 'struct conn_src' members, we must free the memory previously allocated. Should not break anything.
2017-03-17 10:33:50 -04:00
goto err;
#endif /* defined(CONFIG_HAP_TRANSPARENT) */
} /* "usesrc" */
CLEANUP: Compare the return value of `XXXcmp()` functions with zero According to coding-style.txt it is recommended to use: `strcmp(a, b) == 0` instead of `!strcmp(a, b)` So let's do this. The change was performed by running the following (very long) coccinelle patch on src/: @@ statement S; expression E; expression F; @@ if ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) ( S | { ... } ) @@ statement S; expression E; expression F; @@ if ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) ( S | { ... } ) @@ expression E; expression F; expression G; @@ ( G && ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( G || ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 && G ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 || G ) @@ expression E; expression F; expression G; @@ ( G && - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( G || - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 && G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 || G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 )
2021-01-02 16:31:53 -05:00
if (strcmp(args[*cur_arg], "interface") == 0) { /* specifically bind to this interface */
MINOR: server: Make 'default-server' support 'source' keyword. Before this patch, only 'server' directives could support 'source' setting. This patch makes also 'default-server' directives support this setting. To do so, we had to extract the code responsible of parsing 'source' setting arguments from parse_server() function and make it callable both as 'default-server' and 'server' 'source' setting parser. So, the code is mostly the same as before except that before allocating anything for 'struct conn_src' members, we must free the memory previously allocated. Should not break anything.
2017-03-17 10:33:50 -04:00
#ifdef SO_BINDTODEVICE
if (!*args[*cur_arg + 1]) {
CLEANUP: log: Rename Alert/Warning in ha_alert/ha_warning
2017-11-24 10:50:31 -05:00
ha_alert("'%s' : missing interface name.\n", args[0]);
MINOR: server: Make 'default-server' support 'source' keyword. Before this patch, only 'server' directives could support 'source' setting. This patch makes also 'default-server' directives support this setting. To do so, we had to extract the code responsible of parsing 'source' setting arguments from parse_server() function and make it callable both as 'default-server' and 'server' 'source' setting parser. So, the code is mostly the same as before except that before allocating anything for 'struct conn_src' members, we must free the memory previously allocated. Should not break anything.
2017-03-17 10:33:50 -04:00
goto err;
}
free(newsrv->conn_src.iface_name);
newsrv->conn_src.iface_name = strdup(args[*cur_arg + 1]);
newsrv->conn_src.iface_len = strlen(newsrv->conn_src.iface_name);
global.last_checks |= LSTCHK_NETADM;
#else
CLEANUP: log: Rename Alert/Warning in ha_alert/ha_warning
2017-11-24 10:50:31 -05:00
ha_alert("'%s' : '%s' option not implemented.\n", args[0], args[*cur_arg]);
MINOR: server: Make 'default-server' support 'source' keyword. Before this patch, only 'server' directives could support 'source' setting. This patch makes also 'default-server' directives support this setting. To do so, we had to extract the code responsible of parsing 'source' setting arguments from parse_server() function and make it callable both as 'default-server' and 'server' 'source' setting parser. So, the code is mostly the same as before except that before allocating anything for 'struct conn_src' members, we must free the memory previously allocated. Should not break anything.
2017-03-17 10:33:50 -04:00
goto err;
#endif
*cur_arg += 2;
continue;
}
/* this keyword in not an option of "source" */
break;
} /* while */
return 0;
err:
free(errmsg);
return ERR_ALERT | ERR_FATAL;
}
MINOR: server: Make 'default-server' support 'non-stick' keyword. This patch makes 'default-server' directive support 'non-stick' setting. A new keyword 'stick' has been added so that to disable 'non-stick' setting both in 'server' and 'default-server' directives.
2017-03-10 09:50:49 -05:00
/* Parse the "stick" server keyword */
static int srv_parse_stick(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
newsrv->flags &= ~SRV_F_NON_STICK;
return 0;
}
MINOR: server: Make 'default-server' support 'track' setting. Before this patch only 'server' directives could support 'track' setting. This patch makes 'default-server' directives also support this setting. Should not break anything.
2017-03-14 10:21:31 -04:00
/* Parse the "track" server keyword */
static int srv_parse_track(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
char *arg;
arg = args[*cur_arg + 1];
if (!*arg) {
memprintf(err, "'track' expects [<proxy>/]<server> as argument.\n");
return ERR_ALERT | ERR_FATAL;
}
free(newsrv->trackit);
newsrv->trackit = strdup(arg);
return 0;
}
MEDIUM: connection: Upstream SOCKS4 proxy support Have "socks4" and "check-via-socks4" server keyword added. Implement handshake with SOCKS4 proxy server for tcp stream connection. See issue #82. I have the "SOCKS: A protocol for TCP proxy across firewalls" doc found at "https://www.openssh.com/txt/socks4.protocol". Please reference to it. [wt: for now connecting to the SOCKS4 proxy over unix sockets is not supported, and mixing IPv4/IPv6 is discouraged; indeed, the control layer is unique for a connection and will be used both for connecting and for target address manipulation. As such it may for example report incorrect destination addresses in logs if the proxy is reached over IPv6]
2019-05-22 07:44:48 -04:00
/* Parse the "socks4" server keyword */
static int srv_parse_socks4(char **args, int *cur_arg,
struct proxy *curproxy, struct server *newsrv, char **err)
{
char *errmsg;
int port_low, port_high;
struct sockaddr_storage *sk;
errmsg = NULL;
if (!*args[*cur_arg + 1]) {
memprintf(err, "'%s' expects <addr>:<port> as argument.\n", args[*cur_arg]);
goto err;
}
/* 'sk' is statically allocated (no need to be freed). */
MINOR: tools: make str2sa_range() directly return type hints str2sa_range() already allows the caller to provide <proto> in order to get a pointer on the protocol matching with the string input thanks to 5fc9328a ("MINOR: tools: make str2sa_range() directly return the protocol") However, as stated into the commit message, there is a trick: "we can fail to return a protocol in case the caller accepts an fqdn for use later. This is what servers do and in this case it is valid to return no protocol" In this case, we're unable to return protocol because the protocol lookup depends on both the [proto type + xprt type] and the [family type] to be known. While family type might not be directly resolved when fqdn is involved (because family type might be discovered using DNS queries), proto type and xprt type are already known. As such, the caller might be interested in knowing those address related hints even if the address family type is not yet resolved and thus the matching protocol cannot be looked up. Thus in this patch we add the optional net_addr_type (custom type) argument to str2sa_range to enable the caller to check the protocol type and transport type when the function succeeds.
2023-11-09 05:19:24 -05:00
sk = str2sa_range(args[*cur_arg + 1], NULL, &port_low, &port_high, NULL, NULL, NULL,
MINOR: tools: extend str2sa_range to add an alt parameter Add a new parameter "alt" that will store wether this configuration use an alternate protocol. This alt pointer will contain a value that can be transparently passed to protocol_lookup to obtain an appropriate protocol structure. This change is needed to allow for example the servers to know if it need to use an alternate protocol or not.
2024-08-26 05:50:24 -04:00
&errmsg, NULL, NULL, NULL,
MEDIUM: tools: make str2sa_range() check that the protocol has ->connect() Most callers of str2sa_range() need the protocol only to check that it provides a ->connect() method. It used to be used to verify that it's a stream protocol, but it might be a bit early to get rid of it. Let's keep the test for now but move it to str2sa_range() when the new flag PA_O_CONNECT is present. This way almost all call places could be cleaned from this. There's a strange test in the server address parsing code that rechecks the family from the socket which seems to be a duplicate of the previously removed tests. It will have to be rechecked.
2020-09-16 13:17:08 -04:00
PA_O_RESOLVE | PA_O_PORT_OK | PA_O_PORT_MAND | PA_O_STREAM | PA_O_CONNECT);
MEDIUM: connection: Upstream SOCKS4 proxy support Have "socks4" and "check-via-socks4" server keyword added. Implement handshake with SOCKS4 proxy server for tcp stream connection. See issue #82. I have the "SOCKS: A protocol for TCP proxy across firewalls" doc found at "https://www.openssh.com/txt/socks4.protocol". Please reference to it. [wt: for now connecting to the SOCKS4 proxy over unix sockets is not supported, and mixing IPv4/IPv6 is discouraged; indeed, the control layer is unique for a connection and will be used both for connecting and for target address manipulation. As such it may for example report incorrect destination addresses in logs if the proxy is reached over IPv6]
2019-05-22 07:44:48 -04:00
if (!sk) {
memprintf(err, "'%s %s' : %s\n", args[*cur_arg], args[*cur_arg + 1], errmsg);
goto err;
}
newsrv->flags |= SRV_F_SOCKS4_PROXY;
newsrv->socks4_addr = *sk;
return 0;
err:
free(errmsg);
return ERR_ALERT | ERR_FATAL;
}
MINOR: server: Make 'default-server' support 'source' keyword. Before this patch, only 'server' directives could support 'source' setting. This patch makes also 'default-server' directives support this setting. To do so, we had to extract the code responsible of parsing 'source' setting arguments from parse_server() function and make it callable both as 'default-server' and 'server' 'source' setting parser. So, the code is mostly the same as before except that before allocating anything for 'struct conn_src' members, we must free the memory previously allocated. Should not break anything.
2017-03-17 10:33:50 -04:00
MEDIUM: tcp: add the "tfo" option to support TCP fastopen on the server This implements support for the new API which relies on a call to setsockopt(). On systems that support it (currently, only Linux >= 4.11), this enables using TCP fast open when connecting to server. Please note that you should use the retry-on "conn-failure", "empty-response" and "response-timeout" keywords, or the request won't be able to be retried on failure. Co-authored-by: Olivier Houchard <ohouchard@haproxy.com>
2017-01-23 17:36:45 -05:00
/* parse the "tfo" server keyword */
static int srv_parse_tfo(char **args, int *cur_arg, struct proxy *px, struct server *newsrv, char **err)
{
newsrv->flags |= SRV_F_FASTOPEN;
return 0;
}
REORG: server: move keywords in srv_kws Move server-keyword hardcoded in parse_server into the srv_kws list of server.c. Now every server keywords is checked through srv_find_kw. This has the effect to reduce the size of parse_server. As a side-effect, common kw list can be reduced. This change has been made to be able to quickly discard these keywords in case of a dynamic server.
2021-03-10 10:36:02 -05:00
/* parse the "usesrc" server keyword */
static int srv_parse_usesrc(char **args, int *cur_arg, struct proxy *px, struct server *newsrv, char **err)
{
memprintf(err, "'%s' only allowed after a '%s' statement.",
"usesrc", "source");
return ERR_ALERT | ERR_FATAL;
}
/* parse the "weight" server keyword */
static int srv_parse_weight(char **args, int *cur_arg, struct proxy *px, struct server *newsrv, char **err)
{
int w;
w = atol(args[*cur_arg + 1]);
if (w < 0 || w > SRV_UWGHT_MAX) {
memprintf(err, "weight of server %s is not within 0 and %d (%d).",
newsrv->id, SRV_UWGHT_MAX, w);
return ERR_ALERT | ERR_FATAL;
}
newsrv->uweight = newsrv->iweight = w;
return 0;
}
MEDIUM: servers: Add strict-maxconn. Maxconn is a bit of a misnomer when it comes to servers, as it doesn't control the maximum number of connections we establish to a server, but the maximum number of simultaneous requests. So add "strict-maxconn", that will make it so we will never establish more connections than maxconn. It extends the meaning of the "restricted" setting of tune.takeover-other-tg-connections, as it will also attempt to get idle connections from other thread groups if strict-maxconn is set.
2025-02-06 11:07:48 -05:00
static int srv_parse_strict_maxconn(char **args, int *cur_arg, struct proxy *px, struct server *newsrv, char **err)
{
newsrv->flags |= SRV_F_STRICT_MAXCONN;
return 0;
}
MINOR: server: simplify srv_has_streams() Now that thanks to commit c880c32b16 ("MINOR: stream: decrement srv->served after detaching from the list") we can trust srv->served, let's use it and no longer loop on threads when checking if a server still has streams attached to it. This will be much cheaper and will result in keeping isolation for a shorter time in the "wait" command.
2025-03-18 06:30:37 -04:00
/* Returns 1 if the server has streams pointing to it, and 0 otherwise. */
BUG/MEDIUM: server/cli: don't delete a dynamic server that has streams In cli_parse_delete_server(), we take care of checking that the server is in MAINT and that the cur_sess counter is set to 0, in the hope that no connection/stream ressources continue to point to the server, else we refuse to delete it. As shown in GH #2298, this is not sufficient. Indeed, when the server option "on-marked-down shutdown-sessions" is not used, server streams are not purged when srv enters maintenance mode. As such, there could be remaining streams that point to the server. To detect this, a secondary check on srv->cur_sess counter was performed in cli_parse_delete_server(). Unfortunately, there are some code paths that could lead to cur_sess being decremented, and not resulting in a stream being actually shutdown. As such, if the delete_server cli is handled right after cur_sess has been decremented with streams still pointing to the server, we could face some nasty bugs where stream->srv_conn could point to garbage memory area, as described in the original github report. To make the check more reliable prior to deleting the server, we don't rely exclusively on cur_sess and directly check that the server is not used in any stream through the srv_has_stream() helper function. Thanks to @capflam which found out the root cause for the bug and greatly helped to provide the fix. This should be backported up to 2.6.
2023-09-21 08:18:50 -04:00
static int srv_has_streams(struct server *srv)
{
MINOR: server: simplify srv_has_streams() Now that thanks to commit c880c32b16 ("MINOR: stream: decrement srv->served after detaching from the list") we can trust srv->served, let's use it and no longer loop on threads when checking if a server still has streams attached to it. This will be much cheaper and will result in keeping isolation for a shorter time in the "wait" command.
2025-03-18 06:30:37 -04:00
return !!_HA_ATOMIC_LOAD(&srv->served);
BUG/MEDIUM: server/cli: don't delete a dynamic server that has streams In cli_parse_delete_server(), we take care of checking that the server is in MAINT and that the cur_sess counter is set to 0, in the hope that no connection/stream ressources continue to point to the server, else we refuse to delete it. As shown in GH #2298, this is not sufficient. Indeed, when the server option "on-marked-down shutdown-sessions" is not used, server streams are not purged when srv enters maintenance mode. As such, there could be remaining streams that point to the server. To detect this, a secondary check on srv->cur_sess counter was performed in cli_parse_delete_server(). Unfortunately, there are some code paths that could lead to cur_sess being decremented, and not resulting in a stream being actually shutdown. As such, if the delete_server cli is handled right after cur_sess has been decremented with streams still pointing to the server, we could face some nasty bugs where stream->srv_conn could point to garbage memory area, as described in the original github report. To make the check more reliable prior to deleting the server, we don't rely exclusively on cur_sess and directly check that the server is not used in any stream through the srv_has_stream() helper function. Thanks to @capflam which found out the root cause for the bug and greatly helped to provide the fix. This should be backported up to 2.6.
2023-09-21 08:18:50 -04:00
}
REORG: checks: put the functions in the appropriate files ! Checks.c has become a total mess. A number of proxy or server maintenance and queue management functions were put there probably because they were used there, but that makes the code untouchable. And that's without saying that their names does not always relate to what they really do! So let's do a first pass by moving these ones : - set_backend_down() => backend.c - redistribute_pending() => queue.c:pendconn_redistribute() - check_for_pending() => queue.c:pendconn_grab_from_px() - shutdown_sessions => server.c:srv_shutdown_sessions() - shutdown_backup_sessions => server.c:srv_shutdown_backup_sessions() All of them were moved at once.
2014-05-16 05:48:10 -04:00
/* Shutdown all connections of a server. The caller must pass a termination
REORG/MEDIUM: stream: rename stream flags from SN_* to SF_* This is in order to keep things consistent.
2015-04-02 19:14:29 -04:00
* code in <why>, which must be one of SF_ERR_* indicating the reason for the
REORG: checks: put the functions in the appropriate files ! Checks.c has become a total mess. A number of proxy or server maintenance and queue management functions were put there probably because they were used there, but that makes the code untouchable. And that's without saying that their names does not always relate to what they really do! So let's do a first pass by moving these ones : - set_backend_down() => backend.c - redistribute_pending() => queue.c:pendconn_redistribute() - check_for_pending() => queue.c:pendconn_grab_from_px() - shutdown_sessions => server.c:srv_shutdown_sessions() - shutdown_backup_sessions => server.c:srv_shutdown_backup_sessions() All of them were moved at once.
2014-05-16 05:48:10 -04:00
* shutdown.
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
*
Revert "BUG/MINOR: server: shut down streams under thread isolation" This reverts commit b500e84e24fd19ccbcdf4fae5165aeb07e46bd67. Thread isolation does not work well for this, there exists code paths which already hold the server's lock and result in a deadlock. Let's revert that and address it better without isolation.
2024-09-26 12:36:17 -04:00
* Must be called with the server lock held.
REORG: checks: put the functions in the appropriate files ! Checks.c has become a total mess. A number of proxy or server maintenance and queue management functions were put there probably because they were used there, but that makes the code untouchable. And that's without saying that their names does not always relate to what they really do! So let's do a first pass by moving these ones : - set_backend_down() => backend.c - redistribute_pending() => queue.c:pendconn_redistribute() - check_for_pending() => queue.c:pendconn_grab_from_px() - shutdown_sessions => server.c:srv_shutdown_sessions() - shutdown_backup_sessions => server.c:srv_shutdown_backup_sessions() All of them were moved at once.
2014-05-16 05:48:10 -04:00
*/
REORG/MAJOR: session: rename the "session" entity to "stream" With HTTP/2, we'll have to support multiplexed streams. A stream is in fact the largest part of what we currently call a session, it has buffers, logs, etc. In order to catch any error, this commit removes any reference to the struct session and tries to rename most "session" occurrences in function names to "stream" and "sess" to "strm" when that's related to a session. The files stream.{c,h} were added and session.{c,h} removed. The session will be reintroduced later and a few parts of the stream will progressively be moved overthere. It will more or less contain only what we need in an embryonic session. Sample fetch functions and converters will have to change a bit so that they'll use an L5 (session) instead of what's currently called "L4" which is in fact L6 for now. Once all changes are completed, we should see approximately this : L7 - http_txn L6 - stream L5 - session L4 - connection | applet There will be at most one http_txn per stream, and a same session will possibly be referenced by multiple streams. A connection will point to a session and to a stream. The session will hold all the information we need to keep even when we don't yet have a stream. Some more cleanup is needed because some code was already far from being clean. The server queue management still refers to sessions at many places while comments talk about connections. This will have to be cleaned up once we have a server-side connection pool manager. Stream flags "SN_*" still need to be renamed, it doesn't seem like any of them will need to move to the session.
2015-04-02 18:22:06 -04:00
void srv_shutdown_streams(struct server *srv, int why)
REORG: checks: put the functions in the appropriate files ! Checks.c has become a total mess. A number of proxy or server maintenance and queue management functions were put there probably because they were used there, but that makes the code untouchable. And that's without saying that their names does not always relate to what they really do! So let's do a first pass by moving these ones : - set_backend_down() => backend.c - redistribute_pending() => queue.c:pendconn_redistribute() - check_for_pending() => queue.c:pendconn_grab_from_px() - shutdown_sessions => server.c:srv_shutdown_sessions() - shutdown_backup_sessions => server.c:srv_shutdown_backup_sessions() All of them were moved at once.
2014-05-16 05:48:10 -04:00
{
OPTIM: server: switch the actconn list to an mt-list The remaining contention on the server lock solely comes from sess_change_server() which takes the lock to add and remove a stream from the server's actconn list. This is both expensive and pointless since we have mt-lists, and this list is only used by the CLI's "shutdown server sessions" command! Let's migrate to an mt-list and remove the need for this costly lock. By doing so, the request rate increased by ~1.8%.
2021-02-17 07:33:24 -05:00
struct stream *stream;
MAJOR: import: update mt_list to support exponential back-off (try #2) This is the second attempt at importing the updated mt_list code (commit 59459ea3). The previous one was attempted with commit c618ed5ff4 ("MAJOR: import: update mt_list to support exponential back-off") but revealed problems with QUIC connections and was reverted. The problem that was faced was that elements deleted inside an iterator were no longer reset, and that if they were to be recycled in this form, they could appear as busy to the next user. This was trivially reproduced with this: $ cat quic-repro.cfg global stats socket /tmp/sock1 level admin stats timeout 1h limited-quic frontend stats mode http bind quic4@:8443 ssl crt rsa+dh2048.pem alpn h3 timeout client 5s stats uri / $ ./haproxy -db -f quic-repro.cfg & $ h2load -c 10 -n 100000 --npn h3 https://127.0.0.1:8443/ => hang This was purely an API issue caused by the simplified usage of the macros for the iterator. The original version had two backups (one full element and one pointer) that the user had to take care of, while the new one only uses one that is transparent for the user. But during removal, the element still has to be unlocked if it's going to be reused. All of this sparked discussions with Fred and Aurlien regarding the still unclear state of locking. It was found that the lock API does too much at once and is lacking granularity. The new version offers a much more fine- grained control allowing to selectively lock/unlock an element, a link, the rest of the list etc. It was also found that plenty of places just want to free the current element, or delete it to do anything with it, hence don't need to reset its pointers (e.g. event_hdl). Finally it appeared obvious that the root cause of the problem was the unclear usage of the list iterators themselves because one does not necessarily expect the element to be presented locked when not needed, which makes the unlock easy to overlook during reviews. The updated version of the list presents explicit lock status in the macro name (_LOCKED or _UNLOCKED suffixes). When using the _LOCKED suffix, the caller is expected to unlock the element if it intends to reuse it. At least the status is advertised. The _UNLOCKED variant, instead, always unlocks it before starting the loop block. This means it's not necessary to think about unlocking it, though it's obviously not usable with everything. A few _UNLOCKED were used at obvious places (i.e. where the element is deleted and freed without any prior check). Interestingly, the tests performed last year on QUIC forwarding, that resulted in limited traffic for the original version and higher bit rate for the new one couldn't be reproduced because since then the QUIC stack has gaind in efficiency, and the 100 Gbps barrier is now reached with or without the mt_list update. However the unit tests definitely show a huge difference, particularly on EPYC platforms where the EBO provides tremendous CPU savings. Overall, the following changes are visible from the application code: - mt_list_for_each_entry_safe() + 1 back elem + 1 back ptr => MT_LIST_FOR_EACH_ENTRY_LOCKED() or MT_LIST_FOR_EACH_ENTRY_UNLOCKED() + 1 back elem - MT_LIST_DELETE_SAFE() no longer needed in MT_LIST_FOR_EACH_ENTRY_UNLOCKED() => just manually set iterator to NULL however. For MT_LIST_FOR_EACH_ENTRY_LOCKED() => mt_list_unlock_self() (if element going to be reused) + NULL - MT_LIST_LOCK_ELT => mt_list_lock_full() - MT_LIST_UNLOCK_ELT => mt_list_unlock_full() - l = MT_LIST_APPEND_LOCKED(h, e); MT_LIST_UNLOCK_ELT(); => l=mt_list_lock_prev(h); mt_list_lock_elem(e); mt_list_unlock_full(e, l)
2024-05-30 05:27:32 -04:00
struct mt_list back;
MINOR: server: move actconns to the per-thread structure The actconns list creates massive contention on low server counts because it's in fact a list of streams using a server, all threads compete on the list's head and it's still possible to see some watchdog panics on 48 threads under extreme contention with 47 threads trying to add and one thread trying to delete. Moving this list per thread is trivial because it's only used by srv_shutdown_streams(), which simply required to iterate over the list. The field was renamed to "streams" as it's really a list of streams rather than a list of connections.
2021-03-04 04:47:54 -05:00
int thr;
REORG: checks: put the functions in the appropriate files ! Checks.c has become a total mess. A number of proxy or server maintenance and queue management functions were put there probably because they were used there, but that makes the code untouchable. And that's without saying that their names does not always relate to what they really do! So let's do a first pass by moving these ones : - set_backend_down() => backend.c - redistribute_pending() => queue.c:pendconn_redistribute() - check_for_pending() => queue.c:pendconn_grab_from_px() - shutdown_sessions => server.c:srv_shutdown_sessions() - shutdown_backup_sessions => server.c:srv_shutdown_backup_sessions() All of them were moved at once.
2014-05-16 05:48:10 -04:00
MINOR: server: move actconns to the per-thread structure The actconns list creates massive contention on low server counts because it's in fact a list of streams using a server, all threads compete on the list's head and it's still possible to see some watchdog panics on 48 threads under extreme contention with 47 threads trying to add and one thread trying to delete. Moving this list per thread is trivial because it's only used by srv_shutdown_streams(), which simply required to iterate over the list. The field was renamed to "streams" as it's really a list of streams rather than a list of connections.
2021-03-04 04:47:54 -05:00
for (thr = 0; thr < global.nbthread; thr++)
MAJOR: import: update mt_list to support exponential back-off (try #2) This is the second attempt at importing the updated mt_list code (commit 59459ea3). The previous one was attempted with commit c618ed5ff4 ("MAJOR: import: update mt_list to support exponential back-off") but revealed problems with QUIC connections and was reverted. The problem that was faced was that elements deleted inside an iterator were no longer reset, and that if they were to be recycled in this form, they could appear as busy to the next user. This was trivially reproduced with this: $ cat quic-repro.cfg global stats socket /tmp/sock1 level admin stats timeout 1h limited-quic frontend stats mode http bind quic4@:8443 ssl crt rsa+dh2048.pem alpn h3 timeout client 5s stats uri / $ ./haproxy -db -f quic-repro.cfg & $ h2load -c 10 -n 100000 --npn h3 https://127.0.0.1:8443/ => hang This was purely an API issue caused by the simplified usage of the macros for the iterator. The original version had two backups (one full element and one pointer) that the user had to take care of, while the new one only uses one that is transparent for the user. But during removal, the element still has to be unlocked if it's going to be reused. All of this sparked discussions with Fred and Aurlien regarding the still unclear state of locking. It was found that the lock API does too much at once and is lacking granularity. The new version offers a much more fine- grained control allowing to selectively lock/unlock an element, a link, the rest of the list etc. It was also found that plenty of places just want to free the current element, or delete it to do anything with it, hence don't need to reset its pointers (e.g. event_hdl). Finally it appeared obvious that the root cause of the problem was the unclear usage of the list iterators themselves because one does not necessarily expect the element to be presented locked when not needed, which makes the unlock easy to overlook during reviews. The updated version of the list presents explicit lock status in the macro name (_LOCKED or _UNLOCKED suffixes). When using the _LOCKED suffix, the caller is expected to unlock the element if it intends to reuse it. At least the status is advertised. The _UNLOCKED variant, instead, always unlocks it before starting the loop block. This means it's not necessary to think about unlocking it, though it's obviously not usable with everything. A few _UNLOCKED were used at obvious places (i.e. where the element is deleted and freed without any prior check). Interestingly, the tests performed last year on QUIC forwarding, that resulted in limited traffic for the original version and higher bit rate for the new one couldn't be reproduced because since then the QUIC stack has gaind in efficiency, and the 100 Gbps barrier is now reached with or without the mt_list update. However the unit tests definitely show a huge difference, particularly on EPYC platforms where the EBO provides tremendous CPU savings. Overall, the following changes are visible from the application code: - mt_list_for_each_entry_safe() + 1 back elem + 1 back ptr => MT_LIST_FOR_EACH_ENTRY_LOCKED() or MT_LIST_FOR_EACH_ENTRY_UNLOCKED() + 1 back elem - MT_LIST_DELETE_SAFE() no longer needed in MT_LIST_FOR_EACH_ENTRY_UNLOCKED() => just manually set iterator to NULL however. For MT_LIST_FOR_EACH_ENTRY_LOCKED() => mt_list_unlock_self() (if element going to be reused) + NULL - MT_LIST_LOCK_ELT => mt_list_lock_full() - MT_LIST_UNLOCK_ELT => mt_list_unlock_full() - l = MT_LIST_APPEND_LOCKED(h, e); MT_LIST_UNLOCK_ELT(); => l=mt_list_lock_prev(h); mt_list_lock_elem(e); mt_list_unlock_full(e, l)
2024-05-30 05:27:32 -04:00
MT_LIST_FOR_EACH_ENTRY_LOCKED(stream, &srv->per_thr[thr].streams, by_srv, back)
MINOR: server: move actconns to the per-thread structure The actconns list creates massive contention on low server counts because it's in fact a list of streams using a server, all threads compete on the list's head and it's still possible to see some watchdog panics on 48 threads under extreme contention with 47 threads trying to add and one thread trying to delete. Moving this list per thread is trivial because it's only used by srv_shutdown_streams(), which simply required to iterate over the list. The field was renamed to "streams" as it's really a list of streams rather than a list of connections.
2021-03-04 04:47:54 -05:00
if (stream->srv_conn == srv)
stream_shutdown(stream, why);
MINOR: server: make srv_shutdown_sessions() call pendconn_redistribute() When shutting down server sessions, the queue was not considered, which is a problem if some element reached the queue at the moment the server was going down, because there will be no more requests to kick them out of it. Let's always make sure we scan the queue to kick these streams out of it and that they can possibly find a more suitable server. This may make a difference in the time it takes to shut down a server on the CLI when lots of servers are in the queue. It might be interesting to backport this to 3.0 but probably not much further.
2024-09-27 13:01:38 -04:00
/* also kill the possibly pending streams in the queue */
pendconn_redistribute(srv);
REORG: checks: put the functions in the appropriate files ! Checks.c has become a total mess. A number of proxy or server maintenance and queue management functions were put there probably because they were used there, but that makes the code untouchable. And that's without saying that their names does not always relate to what they really do! So let's do a first pass by moving these ones : - set_backend_down() => backend.c - redistribute_pending() => queue.c:pendconn_redistribute() - check_for_pending() => queue.c:pendconn_grab_from_px() - shutdown_sessions => server.c:srv_shutdown_sessions() - shutdown_backup_sessions => server.c:srv_shutdown_backup_sessions() All of them were moved at once.
2014-05-16 05:48:10 -04:00
}
/* Shutdown all connections of all backup servers of a proxy. The caller must
REORG/MEDIUM: stream: rename stream flags from SN_* to SF_* This is in order to keep things consistent.
2015-04-02 19:14:29 -04:00
* pass a termination code in <why>, which must be one of SF_ERR_* indicating
REORG: checks: put the functions in the appropriate files ! Checks.c has become a total mess. A number of proxy or server maintenance and queue management functions were put there probably because they were used there, but that makes the code untouchable. And that's without saying that their names does not always relate to what they really do! So let's do a first pass by moving these ones : - set_backend_down() => backend.c - redistribute_pending() => queue.c:pendconn_redistribute() - check_for_pending() => queue.c:pendconn_grab_from_px() - shutdown_sessions => server.c:srv_shutdown_sessions() - shutdown_backup_sessions => server.c:srv_shutdown_backup_sessions() All of them were moved at once.
2014-05-16 05:48:10 -04:00
* the reason for the shutdown.
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
*
* Must be called with the server lock held.
REORG: checks: put the functions in the appropriate files ! Checks.c has become a total mess. A number of proxy or server maintenance and queue management functions were put there probably because they were used there, but that makes the code untouchable. And that's without saying that their names does not always relate to what they really do! So let's do a first pass by moving these ones : - set_backend_down() => backend.c - redistribute_pending() => queue.c:pendconn_redistribute() - check_for_pending() => queue.c:pendconn_grab_from_px() - shutdown_sessions => server.c:srv_shutdown_sessions() - shutdown_backup_sessions => server.c:srv_shutdown_backup_sessions() All of them were moved at once.
2014-05-16 05:48:10 -04:00
*/
REORG/MAJOR: session: rename the "session" entity to "stream" With HTTP/2, we'll have to support multiplexed streams. A stream is in fact the largest part of what we currently call a session, it has buffers, logs, etc. In order to catch any error, this commit removes any reference to the struct session and tries to rename most "session" occurrences in function names to "stream" and "sess" to "strm" when that's related to a session. The files stream.{c,h} were added and session.{c,h} removed. The session will be reintroduced later and a few parts of the stream will progressively be moved overthere. It will more or less contain only what we need in an embryonic session. Sample fetch functions and converters will have to change a bit so that they'll use an L5 (session) instead of what's currently called "L4" which is in fact L6 for now. Once all changes are completed, we should see approximately this : L7 - http_txn L6 - stream L5 - session L4 - connection | applet There will be at most one http_txn per stream, and a same session will possibly be referenced by multiple streams. A connection will point to a session and to a stream. The session will hold all the information we need to keep even when we don't yet have a stream. Some more cleanup is needed because some code was already far from being clean. The server queue management still refers to sessions at many places while comments talk about connections. This will have to be cleaned up once we have a server-side connection pool manager. Stream flags "SN_*" still need to be renamed, it doesn't seem like any of them will need to move to the session.
2015-04-02 18:22:06 -04:00
void srv_shutdown_backup_streams(struct proxy *px, int why)
REORG: checks: put the functions in the appropriate files ! Checks.c has become a total mess. A number of proxy or server maintenance and queue management functions were put there probably because they were used there, but that makes the code untouchable. And that's without saying that their names does not always relate to what they really do! So let's do a first pass by moving these ones : - set_backend_down() => backend.c - redistribute_pending() => queue.c:pendconn_redistribute() - check_for_pending() => queue.c:pendconn_grab_from_px() - shutdown_sessions => server.c:srv_shutdown_sessions() - shutdown_backup_sessions => server.c:srv_shutdown_backup_sessions() All of them were moved at once.
2014-05-16 05:48:10 -04:00
{
struct server *srv;
for (srv = px->srv; srv != NULL; srv = srv->next)
if (srv->flags & SRV_F_BACKUP)
REORG/MAJOR: session: rename the "session" entity to "stream" With HTTP/2, we'll have to support multiplexed streams. A stream is in fact the largest part of what we currently call a session, it has buffers, logs, etc. In order to catch any error, this commit removes any reference to the struct session and tries to rename most "session" occurrences in function names to "stream" and "sess" to "strm" when that's related to a session. The files stream.{c,h} were added and session.{c,h} removed. The session will be reintroduced later and a few parts of the stream will progressively be moved overthere. It will more or less contain only what we need in an embryonic session. Sample fetch functions and converters will have to change a bit so that they'll use an L5 (session) instead of what's currently called "L4" which is in fact L6 for now. Once all changes are completed, we should see approximately this : L7 - http_txn L6 - stream L5 - session L4 - connection | applet There will be at most one http_txn per stream, and a same session will possibly be referenced by multiple streams. A connection will point to a session and to a stream. The session will hold all the information we need to keep even when we don't yet have a stream. Some more cleanup is needed because some code was already far from being clean. The server queue management still refers to sessions at many places while comments talk about connections. This will have to be cleaned up once we have a server-side connection pool manager. Stream flags "SN_*" still need to be renamed, it doesn't seem like any of them will need to move to the session.
2015-04-02 18:22:06 -04:00
srv_shutdown_streams(srv, why);
REORG: checks: put the functions in the appropriate files ! Checks.c has become a total mess. A number of proxy or server maintenance and queue management functions were put there probably because they were used there, but that makes the code untouchable. And that's without saying that their names does not always relate to what they really do! So let's do a first pass by moving these ones : - set_backend_down() => backend.c - redistribute_pending() => queue.c:pendconn_redistribute() - check_for_pending() => queue.c:pendconn_grab_from_px() - shutdown_sessions => server.c:srv_shutdown_sessions() - shutdown_backup_sessions => server.c:srv_shutdown_backup_sessions() All of them were moved at once.
2014-05-16 05:48:10 -04:00
}
MINOR: server: pass adm and op cause to srv_update_status() Operational and administrative state change causes are not propagated through srv_update_status(), instead they are directly consumed within the function to provide additional info during the call when required. Thus, there is no valid reason for keeping adm and op causes within server struct. We are wasting space and keeping uneeded complexity. We now exlicitly pass change type (operational or administrative) and associated cause to srv_update_status() so that no extra storage is needed since those values are only relevant from srv_update_status().
2023-04-18 05:00:17 -04:00
static void srv_append_op_chg_cause(struct buffer *msg, struct server *s, enum srv_op_st_chg_cause cause)
MINOR: server: srv_append_status refacto srv_append_status() has become a swiss-knife function over time. It is used from server code and also from checks code, with various inputs and distincts code paths, making it very hard to guess the actual behavior of the function (resulting string output). To simplify the logic behind it, we're dividing it in multiple contextual functions that take simple inputs and do explicit things, making them more predictable and easier to maintain.
2023-04-14 12:07:09 -04:00
{
MINOR: server: pass adm and op cause to srv_update_status() Operational and administrative state change causes are not propagated through srv_update_status(), instead they are directly consumed within the function to provide additional info during the call when required. Thus, there is no valid reason for keeping adm and op causes within server struct. We are wasting space and keeping uneeded complexity. We now exlicitly pass change type (operational or administrative) and associated cause to srv_update_status() so that no extra storage is needed since those values are only relevant from srv_update_status().
2023-04-18 05:00:17 -04:00
switch (cause) {
MINOR: server: change srv_op_st_chg_cause storage type This one is greatly inspired by "MINOR: server: change adm_st_chg_cause storage type". While looking at current srv_op_st_chg_cause usage, it was clear that the struct needed some cleanup since some leftovers from asynchronous server state change updates were left behind and resulted in some useless code duplication, and making the whole thing harder to maintain. Two observations were made: - by tracking down srv_set_{running, stopped, stopping} usage, we can see that the <reason> argument is always a fixed statically allocated string. - check-related state change context (duration, status, code...) is not used anymore since srv_append_status() directly extracts the values from the server->check. This is pure legacy from when the state changes were applied asynchronously. To prevent code duplication, useless string copies and make the reason/cause more exportable, we store it as an enum now, and we provide srv_op_st_chg_cause() function to fetch the related description string. HEALTH and AGENT causes (check related) are now explicitly identified to make consumers like srv_append_op_chg_cause() able to fetch checks info from the server itself if they need to.
2023-04-04 04:17:40 -04:00
case SRV_OP_STCHGC_NONE:
break; /* do nothing */
case SRV_OP_STCHGC_HEALTH:
check_append_info(msg, &s->check);
break;
case SRV_OP_STCHGC_AGENT:
check_append_info(msg, &s->agent);
break;
default:
MINOR: server: pass adm and op cause to srv_update_status() Operational and administrative state change causes are not propagated through srv_update_status(), instead they are directly consumed within the function to provide additional info during the call when required. Thus, there is no valid reason for keeping adm and op causes within server struct. We are wasting space and keeping uneeded complexity. We now exlicitly pass change type (operational or administrative) and associated cause to srv_update_status() so that no extra storage is needed since those values are only relevant from srv_update_status().
2023-04-18 05:00:17 -04:00
chunk_appendf(msg, ", %s", srv_op_st_chg_cause(cause));
MINOR: server: change srv_op_st_chg_cause storage type This one is greatly inspired by "MINOR: server: change adm_st_chg_cause storage type". While looking at current srv_op_st_chg_cause usage, it was clear that the struct needed some cleanup since some leftovers from asynchronous server state change updates were left behind and resulted in some useless code duplication, and making the whole thing harder to maintain. Two observations were made: - by tracking down srv_set_{running, stopped, stopping} usage, we can see that the <reason> argument is always a fixed statically allocated string. - check-related state change context (duration, status, code...) is not used anymore since srv_append_status() directly extracts the values from the server->check. This is pure legacy from when the state changes were applied asynchronously. To prevent code duplication, useless string copies and make the reason/cause more exportable, we store it as an enum now, and we provide srv_op_st_chg_cause() function to fetch the related description string. HEALTH and AGENT causes (check related) are now explicitly identified to make consumers like srv_append_op_chg_cause() able to fetch checks info from the server itself if they need to.
2023-04-04 04:17:40 -04:00
break;
}
MINOR: server: srv_append_status refacto srv_append_status() has become a swiss-knife function over time. It is used from server code and also from checks code, with various inputs and distincts code paths, making it very hard to guess the actual behavior of the function (resulting string output). To simplify the logic behind it, we're dividing it in multiple contextual functions that take simple inputs and do explicit things, making them more predictable and easier to maintain.
2023-04-14 12:07:09 -04:00
}
MINOR: server: pass adm and op cause to srv_update_status() Operational and administrative state change causes are not propagated through srv_update_status(), instead they are directly consumed within the function to provide additional info during the call when required. Thus, there is no valid reason for keeping adm and op causes within server struct. We are wasting space and keeping uneeded complexity. We now exlicitly pass change type (operational or administrative) and associated cause to srv_update_status() so that no extra storage is needed since those values are only relevant from srv_update_status().
2023-04-18 05:00:17 -04:00
static void srv_append_adm_chg_cause(struct buffer *msg, struct server *s, enum srv_adm_st_chg_cause cause)
MINOR: server: srv_append_status refacto srv_append_status() has become a swiss-knife function over time. It is used from server code and also from checks code, with various inputs and distincts code paths, making it very hard to guess the actual behavior of the function (resulting string output). To simplify the logic behind it, we're dividing it in multiple contextual functions that take simple inputs and do explicit things, making them more predictable and easier to maintain.
2023-04-14 12:07:09 -04:00
{
MINOR: server: pass adm and op cause to srv_update_status() Operational and administrative state change causes are not propagated through srv_update_status(), instead they are directly consumed within the function to provide additional info during the call when required. Thus, there is no valid reason for keeping adm and op causes within server struct. We are wasting space and keeping uneeded complexity. We now exlicitly pass change type (operational or administrative) and associated cause to srv_update_status() so that no extra storage is needed since those values are only relevant from srv_update_status().
2023-04-18 05:00:17 -04:00
if (cause)
chunk_appendf(msg, " (%s)", srv_adm_st_chg_cause(cause));
MINOR: server: srv_append_status refacto srv_append_status() has become a swiss-knife function over time. It is used from server code and also from checks code, with various inputs and distincts code paths, making it very hard to guess the actual behavior of the function (resulting string output). To simplify the logic behind it, we're dividing it in multiple contextual functions that take simple inputs and do explicit things, making them more predictable and easier to maintain.
2023-04-14 12:07:09 -04:00
}
/* Appends some information to a message string related to a server tracking
* or requeued connections info.
*
* If <forced> is null and the server tracks another one, a "via"
BUG/MEDIUM: log: check result details truncated. Fix regression introduced by commit: 'MAJOR: servers: propagate server status changes asynchronously.' The building of the log line was re-worked to be done at the postponed point without lack of data. [wt: this only affects 1.8-dev, no backport needed]
2017-10-19 08:42:30 -04:00
* If <xferred> is non-negative, some information about requeued sessions are
MINOR: server: make the status reporting function support a reason srv_adm_append_status() was renamed srv_append_status() since it's no more dedicated to maintenance mode. It now supports a reason which if not null is appended to the output string.
2014-05-20 15:55:30 -04:00
* provided.
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
*
* Must be called with the server lock held.
MEDIUM: server: properly support and propagate the maintenance status This change now involves a new flag SRV_ADMF_IMAINT to note that the maintenance status of a server is inherited from another server. Thus, we know at each server level in the chain if it's running, in forced maintenance or in a maintenance status because it tracks another server, or even in both states. Disabling a server propagates this flag down to other servers. Enabling a server flushes the flag down. A server becomes up again once both of its flags are cleared. Two new functions "srv_adm_set_maint()" and "srv_adm_set_ready()" are used to manipulate this maintenance status. They're used by the CLI and the stats page. Now the stats page always says "MAINT" instead of "MAINT(via)" and it's only the chk/down field which reports "via x/y" when the status is inherited from another server, but it doesn't say it when a server was forced into maintenance. The CSV output indicates "MAINT (via x/y)" instead of only "MAINT(via)". This is the most accurate representation. One important thing is that now entering/leaving maintenance for a tracking server correctly follows the state of the tracked server.
2014-05-16 05:25:16 -04:00
*/
MINOR: server: srv_append_status refacto srv_append_status() has become a swiss-knife function over time. It is used from server code and also from checks code, with various inputs and distincts code paths, making it very hard to guess the actual behavior of the function (resulting string output). To simplify the logic behind it, we're dividing it in multiple contextual functions that take simple inputs and do explicit things, making them more predictable and easier to maintain.
2023-04-14 12:07:09 -04:00
static void srv_append_more(struct buffer *msg, struct server *s,
int xferred, int forced)
MEDIUM: server: properly support and propagate the maintenance status This change now involves a new flag SRV_ADMF_IMAINT to note that the maintenance status of a server is inherited from another server. Thus, we know at each server level in the chain if it's running, in forced maintenance or in a maintenance status because it tracks another server, or even in both states. Disabling a server propagates this flag down to other servers. Enabling a server flushes the flag down. A server becomes up again once both of its flags are cleared. Two new functions "srv_adm_set_maint()" and "srv_adm_set_ready()" are used to manipulate this maintenance status. They're used by the CLI and the stats page. Now the stats page always says "MAINT" instead of "MAINT(via)" and it's only the chk/down field which reports "via x/y" when the status is inherited from another server, but it doesn't say it when a server was forced into maintenance. The CSV output indicates "MAINT (via x/y)" instead of only "MAINT(via)". This is the most accurate representation. One important thing is that now entering/leaving maintenance for a tracking server correctly follows the state of the tracked server.
2014-05-16 05:25:16 -04:00
{
MINOR: server: srv_append_status refacto srv_append_status() has become a swiss-knife function over time. It is used from server code and also from checks code, with various inputs and distincts code paths, making it very hard to guess the actual behavior of the function (resulting string output). To simplify the logic behind it, we're dividing it in multiple contextual functions that take simple inputs and do explicit things, making them more predictable and easier to maintain.
2023-04-14 12:07:09 -04:00
if (!forced && s->track) {
MINOR: server: make the status reporting function support a reason srv_adm_append_status() was renamed srv_append_status() since it's no more dedicated to maintenance mode. It now supports a reason which if not null is appended to the output string.
2014-05-20 15:55:30 -04:00
chunk_appendf(msg, " via %s/%s", s->track->proxy->id, s->track->id);
BUG/MEDIUM: log: check result details truncated. Fix regression introduced by commit: 'MAJOR: servers: propagate server status changes asynchronously.' The building of the log line was re-worked to be done at the postponed point without lack of data. [wt: this only affects 1.8-dev, no backport needed]
2017-10-19 08:42:30 -04:00
}
MEDIUM: server: properly support and propagate the maintenance status This change now involves a new flag SRV_ADMF_IMAINT to note that the maintenance status of a server is inherited from another server. Thus, we know at each server level in the chain if it's running, in forced maintenance or in a maintenance status because it tracks another server, or even in both states. Disabling a server propagates this flag down to other servers. Enabling a server flushes the flag down. A server becomes up again once both of its flags are cleared. Two new functions "srv_adm_set_maint()" and "srv_adm_set_ready()" are used to manipulate this maintenance status. They're used by the CLI and the stats page. Now the stats page always says "MAINT" instead of "MAINT(via)" and it's only the chk/down field which reports "via x/y" when the status is inherited from another server, but it doesn't say it when a server was forced into maintenance. The CSV output indicates "MAINT (via x/y)" instead of only "MAINT(via)". This is the most accurate representation. One important thing is that now entering/leaving maintenance for a tracking server correctly follows the state of the tracked server.
2014-05-16 05:25:16 -04:00
if (xferred >= 0) {
MEDIUM: check: server states and weight propagation re-work The server state and weight was reworked to handle "pending" values updated by checks/CLI/LUA/agent. These values are commited to be propagated to the LB stack. In further dev related to multi-thread, the commit will be handled into a sync point. Pending values are named using the prefix 'next_' Current values used by the LB stack are named 'cur_'
2017-08-31 08:41:55 -04:00
if (s->next_state == SRV_ST_STOPPED)
MEDIUM: server: properly support and propagate the maintenance status This change now involves a new flag SRV_ADMF_IMAINT to note that the maintenance status of a server is inherited from another server. Thus, we know at each server level in the chain if it's running, in forced maintenance or in a maintenance status because it tracks another server, or even in both states. Disabling a server propagates this flag down to other servers. Enabling a server flushes the flag down. A server becomes up again once both of its flags are cleared. Two new functions "srv_adm_set_maint()" and "srv_adm_set_ready()" are used to manipulate this maintenance status. They're used by the CLI and the stats page. Now the stats page always says "MAINT" instead of "MAINT(via)" and it's only the chk/down field which reports "via x/y" when the status is inherited from another server, but it doesn't say it when a server was forced into maintenance. The CSV output indicates "MAINT (via x/y)" instead of only "MAINT(via)". This is the most accurate representation. One important thing is that now entering/leaving maintenance for a tracking server correctly follows the state of the tracked server.
2014-05-16 05:25:16 -04:00
chunk_appendf(msg, ". %d active and %d backup servers left.%s"
" %d sessions active, %d requeued, %d remaining in queue",
s->proxy->srv_act, s->proxy->srv_bck,
(s->proxy->srv_bck && !s->proxy->srv_act) ? " Running on backup." : "",
MINOR: proxies/servers: Calculate queueslength and use it. For both proxies and servers, properly calculates queueslength, which is the total number of element in each queues (as they currently are only using one queue, it is equivalent to the number of element of that queue), and use it instead of the queue's length.
2025-01-15 10:37:35 -05:00
s->cur_sess, xferred, s->queueslength);
MEDIUM: server: properly support and propagate the maintenance status This change now involves a new flag SRV_ADMF_IMAINT to note that the maintenance status of a server is inherited from another server. Thus, we know at each server level in the chain if it's running, in forced maintenance or in a maintenance status because it tracks another server, or even in both states. Disabling a server propagates this flag down to other servers. Enabling a server flushes the flag down. A server becomes up again once both of its flags are cleared. Two new functions "srv_adm_set_maint()" and "srv_adm_set_ready()" are used to manipulate this maintenance status. They're used by the CLI and the stats page. Now the stats page always says "MAINT" instead of "MAINT(via)" and it's only the chk/down field which reports "via x/y" when the status is inherited from another server, but it doesn't say it when a server was forced into maintenance. The CSV output indicates "MAINT (via x/y)" instead of only "MAINT(via)". This is the most accurate representation. One important thing is that now entering/leaving maintenance for a tracking server correctly follows the state of the tracked server.
2014-05-16 05:25:16 -04:00
else
chunk_appendf(msg, ". %d active and %d backup servers online.%s"
" %d sessions requeued, %d total in queue",
s->proxy->srv_act, s->proxy->srv_bck,
(s->proxy->srv_bck && !s->proxy->srv_act) ? " Running on backup." : "",
MINOR: proxies/servers: Calculate queueslength and use it. For both proxies and servers, properly calculates queueslength, which is the total number of element in each queues (as they currently are only using one queue, it is equivalent to the number of element of that queue), and use it instead of the queue's length.
2025-01-15 10:37:35 -05:00
xferred, s->queueslength);
MEDIUM: server: properly support and propagate the maintenance status This change now involves a new flag SRV_ADMF_IMAINT to note that the maintenance status of a server is inherited from another server. Thus, we know at each server level in the chain if it's running, in forced maintenance or in a maintenance status because it tracks another server, or even in both states. Disabling a server propagates this flag down to other servers. Enabling a server flushes the flag down. A server becomes up again once both of its flags are cleared. Two new functions "srv_adm_set_maint()" and "srv_adm_set_ready()" are used to manipulate this maintenance status. They're used by the CLI and the stats page. Now the stats page always says "MAINT" instead of "MAINT(via)" and it's only the chk/down field which reports "via x/y" when the status is inherited from another server, but it doesn't say it when a server was forced into maintenance. The CSV output indicates "MAINT (via x/y)" instead of only "MAINT(via)". This is the most accurate representation. One important thing is that now entering/leaving maintenance for a tracking server correctly follows the state of the tracked server.
2014-05-16 05:25:16 -04:00
}
}
CLEANUP: server: fix srv_set_{running, stopping, stopped} function comment Fixing function comments for the server state changing function since they still refer to asynchonous propagation of server state which is no longer in play. Moreover, there were some mixups between running/stopping.
2023-04-19 04:33:02 -04:00
/* Marks server <s> down, regardless of its checks' statuses. The server
* transfers queued streams whenever possible to other servers at a sync
* point. Maintenance servers are ignored.
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
*
* Must be called with the server lock held.
MINOR: server: implement srv_set_stopped() This function was extracted from check_set_server_down(). In only manipulates the server state and does not consider the health checks at all, nor does it modify their status. It takes a reason message to report in logs, however it passes NULL when recursing through the trackers chain. For now the function is not used, but the goal is to split health checks status from server status and to be able to change a server's state regardless of health checks statuses.
2014-05-20 16:25:12 -04:00
*/
MINOR: server: change srv_op_st_chg_cause storage type This one is greatly inspired by "MINOR: server: change adm_st_chg_cause storage type". While looking at current srv_op_st_chg_cause usage, it was clear that the struct needed some cleanup since some leftovers from asynchronous server state change updates were left behind and resulted in some useless code duplication, and making the whole thing harder to maintain. Two observations were made: - by tracking down srv_set_{running, stopped, stopping} usage, we can see that the <reason> argument is always a fixed statically allocated string. - check-related state change context (duration, status, code...) is not used anymore since srv_append_status() directly extracts the values from the server->check. This is pure legacy from when the state changes were applied asynchronously. To prevent code duplication, useless string copies and make the reason/cause more exportable, we store it as an enum now, and we provide srv_op_st_chg_cause() function to fetch the related description string. HEALTH and AGENT causes (check related) are now explicitly identified to make consumers like srv_append_op_chg_cause() able to fetch checks info from the server itself if they need to.
2023-04-04 04:17:40 -04:00
void srv_set_stopped(struct server *s, enum srv_op_st_chg_cause cause)
MINOR: server: implement srv_set_stopped() This function was extracted from check_set_server_down(). In only manipulates the server state and does not consider the health checks at all, nor does it modify their status. It takes a reason message to report in logs, however it passes NULL when recursing through the trackers chain. For now the function is not used, but the goal is to split health checks status from server status and to be able to change a server's state regardless of health checks statuses.
2014-05-20 16:25:12 -04:00
{
struct server *srv;
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
if ((s->cur_admin & SRV_ADMF_MAINT) || s->next_state == SRV_ST_STOPPED)
MINOR: server: implement srv_set_stopped() This function was extracted from check_set_server_down(). In only manipulates the server state and does not consider the health checks at all, nor does it modify their status. It takes a reason message to report in logs, however it passes NULL when recursing through the trackers chain. For now the function is not used, but the goal is to split health checks status from server status and to be able to change a server's state regardless of health checks statuses.
2014-05-20 16:25:12 -04:00
return;
MEDIUM: check: server states and weight propagation re-work The server state and weight was reworked to handle "pending" values updated by checks/CLI/LUA/agent. These values are commited to be propagated to the LB stack. In further dev related to multi-thread, the commit will be handled into a sync point. Pending values are named using the prefix 'next_' Current values used by the LB stack are named 'cur_'
2017-08-31 08:41:55 -04:00
s->next_state = SRV_ST_STOPPED;
MINOR: server: implement srv_set_stopped() This function was extracted from check_set_server_down(). In only manipulates the server state and does not consider the health checks at all, nor does it modify their status. It takes a reason message to report in logs, however it passes NULL when recursing through the trackers chain. For now the function is not used, but the goal is to split health checks status from server status and to be able to change a server's state regardless of health checks statuses.
2014-05-20 16:25:12 -04:00
BUG/MEDIUM: server: update our local state before propagating changes Commit 3ff577e ("MAJOR: server: make server state changes synchronous again") reintroduced synchronous server state changes. However, during the previous change from synchronous to asynchronous, the server state propagation was placed at the end of the function to ease the code changes, and the commit above didn't put it back at its place. This has resulted in propagated states to be incomplete. For example, making a server leave maintenance would make it up but would leave its tracking servers down because they see their tracked server is still down. Let's just move the status update right to its place. It also adds the benefit of reporting state changes in the order they appear and not in reverse. No backport is needed.
2018-08-21 02:22:26 -04:00
/* propagate changes */
MINOR: server: pass adm and op cause to srv_update_status() Operational and administrative state change causes are not propagated through srv_update_status(), instead they are directly consumed within the function to provide additional info during the call when required. Thus, there is no valid reason for keeping adm and op causes within server struct. We are wasting space and keeping uneeded complexity. We now exlicitly pass change type (operational or administrative) and associated cause to srv_update_status() so that no extra storage is needed since those values are only relevant from srv_update_status().
2023-04-18 05:00:17 -04:00
srv_update_status(s, 0, cause);
BUG/MEDIUM: server: update our local state before propagating changes Commit 3ff577e ("MAJOR: server: make server state changes synchronous again") reintroduced synchronous server state changes. However, during the previous change from synchronous to asynchronous, the server state propagation was placed at the end of the function to ease the code changes, and the commit above didn't put it back at its place. This has resulted in propagated states to be incomplete. For example, making a server leave maintenance would make it up but would leave its tracking servers down because they see their tracked server is still down. Let's just move the status update right to its place. It also adds the benefit of reporting state changes in the order they appear and not in reverse. No backport is needed.
2018-08-21 02:22:26 -04:00
MEDIUM: threads/server: Use the server lock to protect health check and cli concurrency
2017-10-23 08:39:51 -04:00
for (srv = s->trackers; srv; srv = srv->tracknext) {
BUILD: threads: Rename SPIN/RWLOCK macros using HA_ prefix This remove any name conflicts, especially on Solaris.
2017-11-07 04:42:54 -05:00
HA_SPIN_LOCK(SERVER_LOCK, &srv->lock);
MINOR: server: change srv_op_st_chg_cause storage type This one is greatly inspired by "MINOR: server: change adm_st_chg_cause storage type". While looking at current srv_op_st_chg_cause usage, it was clear that the struct needed some cleanup since some leftovers from asynchronous server state change updates were left behind and resulted in some useless code duplication, and making the whole thing harder to maintain. Two observations were made: - by tracking down srv_set_{running, stopped, stopping} usage, we can see that the <reason> argument is always a fixed statically allocated string. - check-related state change context (duration, status, code...) is not used anymore since srv_append_status() directly extracts the values from the server->check. This is pure legacy from when the state changes were applied asynchronously. To prevent code duplication, useless string copies and make the reason/cause more exportable, we store it as an enum now, and we provide srv_op_st_chg_cause() function to fetch the related description string. HEALTH and AGENT causes (check related) are now explicitly identified to make consumers like srv_append_op_chg_cause() able to fetch checks info from the server itself if they need to.
2023-04-04 04:17:40 -04:00
srv_set_stopped(srv, SRV_OP_STCHGC_NONE);
BUILD: threads: Rename SPIN/RWLOCK macros using HA_ prefix This remove any name conflicts, especially on Solaris.
2017-11-07 04:42:54 -05:00
HA_SPIN_UNLOCK(SERVER_LOCK, &srv->lock);
MEDIUM: threads/server: Use the server lock to protect health check and cli concurrency
2017-10-23 08:39:51 -04:00
}
MINOR: server: implement srv_set_stopped() This function was extracted from check_set_server_down(). In only manipulates the server state and does not consider the health checks at all, nor does it modify their status. It takes a reason message to report in logs, however it passes NULL when recursing through the trackers chain. For now the function is not used, but the goal is to split health checks status from server status and to be able to change a server's state regardless of health checks statuses.
2014-05-20 16:25:12 -04:00
}
MINOR: server: implement srv_set_running() This function was taken from check_set_server_up(). It does not consider health checks at all and only sets a server up provided it's not in maintenance. The resulting state may be either RUNNING or STARTING depending on the presence of a slowstart or not. The state change is propagated to tracked servers. For now the function is not used, but the goal is to split health checks status from server status and to be able to change a server's state regardless of health checks statuses.
2014-05-20 16:46:35 -04:00
/* Marks server <s> up regardless of its checks' statuses and provided it isn't
CLEANUP: server: fix srv_set_{running, stopping, stopped} function comment Fixing function comments for the server state changing function since they still refer to asynchonous propagation of server state which is no longer in play. Moreover, there were some mixups between running/stopping.
2023-04-19 04:33:02 -04:00
* in maintenance. The server tries to grab requests from the proxy at a sync
* point. Maintenance servers are ignored.
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
*
* Must be called with the server lock held.
MINOR: server: implement srv_set_running() This function was taken from check_set_server_up(). It does not consider health checks at all and only sets a server up provided it's not in maintenance. The resulting state may be either RUNNING or STARTING depending on the presence of a slowstart or not. The state change is propagated to tracked servers. For now the function is not used, but the goal is to split health checks status from server status and to be able to change a server's state regardless of health checks statuses.
2014-05-20 16:46:35 -04:00
*/
MINOR: server: change srv_op_st_chg_cause storage type This one is greatly inspired by "MINOR: server: change adm_st_chg_cause storage type". While looking at current srv_op_st_chg_cause usage, it was clear that the struct needed some cleanup since some leftovers from asynchronous server state change updates were left behind and resulted in some useless code duplication, and making the whole thing harder to maintain. Two observations were made: - by tracking down srv_set_{running, stopped, stopping} usage, we can see that the <reason> argument is always a fixed statically allocated string. - check-related state change context (duration, status, code...) is not used anymore since srv_append_status() directly extracts the values from the server->check. This is pure legacy from when the state changes were applied asynchronously. To prevent code duplication, useless string copies and make the reason/cause more exportable, we store it as an enum now, and we provide srv_op_st_chg_cause() function to fetch the related description string. HEALTH and AGENT causes (check related) are now explicitly identified to make consumers like srv_append_op_chg_cause() able to fetch checks info from the server itself if they need to.
2023-04-04 04:17:40 -04:00
void srv_set_running(struct server *s, enum srv_op_st_chg_cause cause)
MINOR: server: implement srv_set_running() This function was taken from check_set_server_up(). It does not consider health checks at all and only sets a server up provided it's not in maintenance. The resulting state may be either RUNNING or STARTING depending on the presence of a slowstart or not. The state change is propagated to tracked servers. For now the function is not used, but the goal is to split health checks status from server status and to be able to change a server's state regardless of health checks statuses.
2014-05-20 16:46:35 -04:00
{
struct server *srv;
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
if (s->cur_admin & SRV_ADMF_MAINT)
MINOR: server: implement srv_set_running() This function was taken from check_set_server_up(). It does not consider health checks at all and only sets a server up provided it's not in maintenance. The resulting state may be either RUNNING or STARTING depending on the presence of a slowstart or not. The state change is propagated to tracked servers. For now the function is not used, but the goal is to split health checks status from server status and to be able to change a server's state regardless of health checks statuses.
2014-05-20 16:46:35 -04:00
return;
MEDIUM: check: server states and weight propagation re-work The server state and weight was reworked to handle "pending" values updated by checks/CLI/LUA/agent. These values are commited to be propagated to the LB stack. In further dev related to multi-thread, the commit will be handled into a sync point. Pending values are named using the prefix 'next_' Current values used by the LB stack are named 'cur_'
2017-08-31 08:41:55 -04:00
if (s->next_state == SRV_ST_STARTING || s->next_state == SRV_ST_RUNNING)
MINOR: server: implement srv_set_running() This function was taken from check_set_server_up(). It does not consider health checks at all and only sets a server up provided it's not in maintenance. The resulting state may be either RUNNING or STARTING depending on the presence of a slowstart or not. The state change is propagated to tracked servers. For now the function is not used, but the goal is to split health checks status from server status and to be able to change a server's state regardless of health checks statuses.
2014-05-20 16:46:35 -04:00
return;
MEDIUM: check: server states and weight propagation re-work The server state and weight was reworked to handle "pending" values updated by checks/CLI/LUA/agent. These values are commited to be propagated to the LB stack. In further dev related to multi-thread, the commit will be handled into a sync point. Pending values are named using the prefix 'next_' Current values used by the LB stack are named 'cur_'
2017-08-31 08:41:55 -04:00
s->next_state = SRV_ST_STARTING;
MINOR: server: implement srv_set_running() This function was taken from check_set_server_up(). It does not consider health checks at all and only sets a server up provided it's not in maintenance. The resulting state may be either RUNNING or STARTING depending on the presence of a slowstart or not. The state change is propagated to tracked servers. For now the function is not used, but the goal is to split health checks status from server status and to be able to change a server's state regardless of health checks statuses.
2014-05-20 16:46:35 -04:00
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
if (s->slowstart <= 0)
s->next_state = SRV_ST_RUNNING;
MINOR: server: implement srv_set_running() This function was taken from check_set_server_up(). It does not consider health checks at all and only sets a server up provided it's not in maintenance. The resulting state may be either RUNNING or STARTING depending on the presence of a slowstart or not. The state change is propagated to tracked servers. For now the function is not used, but the goal is to split health checks status from server status and to be able to change a server's state regardless of health checks statuses.
2014-05-20 16:46:35 -04:00
BUG/MEDIUM: server: update our local state before propagating changes Commit 3ff577e ("MAJOR: server: make server state changes synchronous again") reintroduced synchronous server state changes. However, during the previous change from synchronous to asynchronous, the server state propagation was placed at the end of the function to ease the code changes, and the commit above didn't put it back at its place. This has resulted in propagated states to be incomplete. For example, making a server leave maintenance would make it up but would leave its tracking servers down because they see their tracked server is still down. Let's just move the status update right to its place. It also adds the benefit of reporting state changes in the order they appear and not in reverse. No backport is needed.
2018-08-21 02:22:26 -04:00
/* propagate changes */
MINOR: server: pass adm and op cause to srv_update_status() Operational and administrative state change causes are not propagated through srv_update_status(), instead they are directly consumed within the function to provide additional info during the call when required. Thus, there is no valid reason for keeping adm and op causes within server struct. We are wasting space and keeping uneeded complexity. We now exlicitly pass change type (operational or administrative) and associated cause to srv_update_status() so that no extra storage is needed since those values are only relevant from srv_update_status().
2023-04-18 05:00:17 -04:00
srv_update_status(s, 0, cause);
BUG/MEDIUM: server: update our local state before propagating changes Commit 3ff577e ("MAJOR: server: make server state changes synchronous again") reintroduced synchronous server state changes. However, during the previous change from synchronous to asynchronous, the server state propagation was placed at the end of the function to ease the code changes, and the commit above didn't put it back at its place. This has resulted in propagated states to be incomplete. For example, making a server leave maintenance would make it up but would leave its tracking servers down because they see their tracked server is still down. Let's just move the status update right to its place. It also adds the benefit of reporting state changes in the order they appear and not in reverse. No backport is needed.
2018-08-21 02:22:26 -04:00
MEDIUM: threads/server: Use the server lock to protect health check and cli concurrency
2017-10-23 08:39:51 -04:00
for (srv = s->trackers; srv; srv = srv->tracknext) {
BUILD: threads: Rename SPIN/RWLOCK macros using HA_ prefix This remove any name conflicts, especially on Solaris.
2017-11-07 04:42:54 -05:00
HA_SPIN_LOCK(SERVER_LOCK, &srv->lock);
MINOR: server: change srv_op_st_chg_cause storage type This one is greatly inspired by "MINOR: server: change adm_st_chg_cause storage type". While looking at current srv_op_st_chg_cause usage, it was clear that the struct needed some cleanup since some leftovers from asynchronous server state change updates were left behind and resulted in some useless code duplication, and making the whole thing harder to maintain. Two observations were made: - by tracking down srv_set_{running, stopped, stopping} usage, we can see that the <reason> argument is always a fixed statically allocated string. - check-related state change context (duration, status, code...) is not used anymore since srv_append_status() directly extracts the values from the server->check. This is pure legacy from when the state changes were applied asynchronously. To prevent code duplication, useless string copies and make the reason/cause more exportable, we store it as an enum now, and we provide srv_op_st_chg_cause() function to fetch the related description string. HEALTH and AGENT causes (check related) are now explicitly identified to make consumers like srv_append_op_chg_cause() able to fetch checks info from the server itself if they need to.
2023-04-04 04:17:40 -04:00
srv_set_running(srv, SRV_OP_STCHGC_NONE);
BUILD: threads: Rename SPIN/RWLOCK macros using HA_ prefix This remove any name conflicts, especially on Solaris.
2017-11-07 04:42:54 -05:00
HA_SPIN_UNLOCK(SERVER_LOCK, &srv->lock);
MEDIUM: threads/server: Use the server lock to protect health check and cli concurrency
2017-10-23 08:39:51 -04:00
}
MINOR: server: implement srv_set_running() This function was taken from check_set_server_up(). It does not consider health checks at all and only sets a server up provided it's not in maintenance. The resulting state may be either RUNNING or STARTING depending on the presence of a slowstart or not. The state change is propagated to tracked servers. For now the function is not used, but the goal is to split health checks status from server status and to be able to change a server's state regardless of health checks statuses.
2014-05-20 16:46:35 -04:00
}
MINOR: server: implement srv_set_stopping() This function was taken from check_set_server_drain(). It does not consider health checks at all and only sets a server to stopping provided it's not in maintenance and is not currently stopped. The resulting state will be STOPPING. The state change is propagated to tracked servers. For now the function is not used, but the goal is to split health checks status from server status and to be able to change a server's state regardless of health checks statuses.
2014-05-21 07:54:57 -04:00
/* Marks server <s> stopping regardless of its checks' statuses and provided it
CLEANUP: server: fix srv_set_{running, stopping, stopped} function comment Fixing function comments for the server state changing function since they still refer to asynchonous propagation of server state which is no longer in play. Moreover, there were some mixups between running/stopping.
2023-04-19 04:33:02 -04:00
* isn't in maintenance. The server tries to redispatch pending requests
* to the proxy. Maintenance servers are ignored.
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
*
* Must be called with the server lock held.
MINOR: server: implement srv_set_stopping() This function was taken from check_set_server_drain(). It does not consider health checks at all and only sets a server to stopping provided it's not in maintenance and is not currently stopped. The resulting state will be STOPPING. The state change is propagated to tracked servers. For now the function is not used, but the goal is to split health checks status from server status and to be able to change a server's state regardless of health checks statuses.
2014-05-21 07:54:57 -04:00
*/
MINOR: server: change srv_op_st_chg_cause storage type This one is greatly inspired by "MINOR: server: change adm_st_chg_cause storage type". While looking at current srv_op_st_chg_cause usage, it was clear that the struct needed some cleanup since some leftovers from asynchronous server state change updates were left behind and resulted in some useless code duplication, and making the whole thing harder to maintain. Two observations were made: - by tracking down srv_set_{running, stopped, stopping} usage, we can see that the <reason> argument is always a fixed statically allocated string. - check-related state change context (duration, status, code...) is not used anymore since srv_append_status() directly extracts the values from the server->check. This is pure legacy from when the state changes were applied asynchronously. To prevent code duplication, useless string copies and make the reason/cause more exportable, we store it as an enum now, and we provide srv_op_st_chg_cause() function to fetch the related description string. HEALTH and AGENT causes (check related) are now explicitly identified to make consumers like srv_append_op_chg_cause() able to fetch checks info from the server itself if they need to.
2023-04-04 04:17:40 -04:00
void srv_set_stopping(struct server *s, enum srv_op_st_chg_cause cause)
MINOR: server: implement srv_set_stopping() This function was taken from check_set_server_drain(). It does not consider health checks at all and only sets a server to stopping provided it's not in maintenance and is not currently stopped. The resulting state will be STOPPING. The state change is propagated to tracked servers. For now the function is not used, but the goal is to split health checks status from server status and to be able to change a server's state regardless of health checks statuses.
2014-05-21 07:54:57 -04:00
{
struct server *srv;
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
if (s->cur_admin & SRV_ADMF_MAINT)
MINOR: server: implement srv_set_stopping() This function was taken from check_set_server_drain(). It does not consider health checks at all and only sets a server to stopping provided it's not in maintenance and is not currently stopped. The resulting state will be STOPPING. The state change is propagated to tracked servers. For now the function is not used, but the goal is to split health checks status from server status and to be able to change a server's state regardless of health checks statuses.
2014-05-21 07:54:57 -04:00
return;
MEDIUM: check: server states and weight propagation re-work The server state and weight was reworked to handle "pending" values updated by checks/CLI/LUA/agent. These values are commited to be propagated to the LB stack. In further dev related to multi-thread, the commit will be handled into a sync point. Pending values are named using the prefix 'next_' Current values used by the LB stack are named 'cur_'
2017-08-31 08:41:55 -04:00
if (s->next_state == SRV_ST_STOPPING)
MINOR: server: implement srv_set_stopping() This function was taken from check_set_server_drain(). It does not consider health checks at all and only sets a server to stopping provided it's not in maintenance and is not currently stopped. The resulting state will be STOPPING. The state change is propagated to tracked servers. For now the function is not used, but the goal is to split health checks status from server status and to be able to change a server's state regardless of health checks statuses.
2014-05-21 07:54:57 -04:00
return;
MEDIUM: check: server states and weight propagation re-work The server state and weight was reworked to handle "pending" values updated by checks/CLI/LUA/agent. These values are commited to be propagated to the LB stack. In further dev related to multi-thread, the commit will be handled into a sync point. Pending values are named using the prefix 'next_' Current values used by the LB stack are named 'cur_'
2017-08-31 08:41:55 -04:00
s->next_state = SRV_ST_STOPPING;
MINOR: server: implement srv_set_stopping() This function was taken from check_set_server_drain(). It does not consider health checks at all and only sets a server to stopping provided it's not in maintenance and is not currently stopped. The resulting state will be STOPPING. The state change is propagated to tracked servers. For now the function is not used, but the goal is to split health checks status from server status and to be able to change a server's state regardless of health checks statuses.
2014-05-21 07:54:57 -04:00
BUG/MEDIUM: server: update our local state before propagating changes Commit 3ff577e ("MAJOR: server: make server state changes synchronous again") reintroduced synchronous server state changes. However, during the previous change from synchronous to asynchronous, the server state propagation was placed at the end of the function to ease the code changes, and the commit above didn't put it back at its place. This has resulted in propagated states to be incomplete. For example, making a server leave maintenance would make it up but would leave its tracking servers down because they see their tracked server is still down. Let's just move the status update right to its place. It also adds the benefit of reporting state changes in the order they appear and not in reverse. No backport is needed.
2018-08-21 02:22:26 -04:00
/* propagate changes */
MINOR: server: pass adm and op cause to srv_update_status() Operational and administrative state change causes are not propagated through srv_update_status(), instead they are directly consumed within the function to provide additional info during the call when required. Thus, there is no valid reason for keeping adm and op causes within server struct. We are wasting space and keeping uneeded complexity. We now exlicitly pass change type (operational or administrative) and associated cause to srv_update_status() so that no extra storage is needed since those values are only relevant from srv_update_status().
2023-04-18 05:00:17 -04:00
srv_update_status(s, 0, cause);
BUG/MEDIUM: server: update our local state before propagating changes Commit 3ff577e ("MAJOR: server: make server state changes synchronous again") reintroduced synchronous server state changes. However, during the previous change from synchronous to asynchronous, the server state propagation was placed at the end of the function to ease the code changes, and the commit above didn't put it back at its place. This has resulted in propagated states to be incomplete. For example, making a server leave maintenance would make it up but would leave its tracking servers down because they see their tracked server is still down. Let's just move the status update right to its place. It also adds the benefit of reporting state changes in the order they appear and not in reverse. No backport is needed.
2018-08-21 02:22:26 -04:00
MEDIUM: threads/server: Use the server lock to protect health check and cli concurrency
2017-10-23 08:39:51 -04:00
for (srv = s->trackers; srv; srv = srv->tracknext) {
BUILD: threads: Rename SPIN/RWLOCK macros using HA_ prefix This remove any name conflicts, especially on Solaris.
2017-11-07 04:42:54 -05:00
HA_SPIN_LOCK(SERVER_LOCK, &srv->lock);
MINOR: server: change srv_op_st_chg_cause storage type This one is greatly inspired by "MINOR: server: change adm_st_chg_cause storage type". While looking at current srv_op_st_chg_cause usage, it was clear that the struct needed some cleanup since some leftovers from asynchronous server state change updates were left behind and resulted in some useless code duplication, and making the whole thing harder to maintain. Two observations were made: - by tracking down srv_set_{running, stopped, stopping} usage, we can see that the <reason> argument is always a fixed statically allocated string. - check-related state change context (duration, status, code...) is not used anymore since srv_append_status() directly extracts the values from the server->check. This is pure legacy from when the state changes were applied asynchronously. To prevent code duplication, useless string copies and make the reason/cause more exportable, we store it as an enum now, and we provide srv_op_st_chg_cause() function to fetch the related description string. HEALTH and AGENT causes (check related) are now explicitly identified to make consumers like srv_append_op_chg_cause() able to fetch checks info from the server itself if they need to.
2023-04-04 04:17:40 -04:00
srv_set_stopping(srv, SRV_OP_STCHGC_NONE);
BUG/MEDIUM: threads/server: Fix deadlock in srv_set_stopping/srv_set_admin_flag Because of a typo (HA_SPIN_LOCK instead of HA_SPIN_UNLOCK), there is a deadlock in srv_set_stopping and srv_set_admin_flag when there is at least one trackers. This patch must be backported in 1.8.
2018-01-24 15:49:41 -05:00
HA_SPIN_UNLOCK(SERVER_LOCK, &srv->lock);
MEDIUM: threads/server: Use the server lock to protect health check and cli concurrency
2017-10-23 08:39:51 -04:00
}
MINOR: server: implement srv_set_stopping() This function was taken from check_set_server_drain(). It does not consider health checks at all and only sets a server to stopping provided it's not in maintenance and is not currently stopped. The resulting state will be STOPPING. The state change is propagated to tracked servers. For now the function is not used, but the goal is to split health checks status from server status and to be able to change a server's state regardless of health checks statuses.
2014-05-21 07:54:57 -04:00
}
MINOR: server: implement srv_set_running() This function was taken from check_set_server_up(). It does not consider health checks at all and only sets a server up provided it's not in maintenance. The resulting state may be either RUNNING or STARTING depending on the presence of a slowstart or not. The state change is propagated to tracked servers. For now the function is not used, but the goal is to split health checks status from server status and to be able to change a server's state regardless of health checks statuses.
2014-05-20 16:46:35 -04:00
MAJOR: checks: add support for a new "drain" administrative mode This patch adds support for a new "drain" mode. So now we have 3 admin modes for a server : - READY - DRAIN - MAINT The drain mode disables load balancing but leaves the server up. It can coexist with maint, except that maint has precedence. It is also inherited from tracked servers, so just like maint, it's represented with 2 bits. New functions were designed to set/clear each flag and to propagate the changes to tracking servers when relevant, and to log the changes. Existing functions srv_set_adm_maint() and srv_set_adm_ready() were replaced to make use of the new functions. Currently the drain mode is not yet used, however the whole logic was tested with all combinations of set/clear of both flags in various orders to catch all corner cases.
2014-05-22 10:14:34 -04:00
/* Enables admin flag <mode> (among SRV_ADMF_*) on server <s>. This is used to
* enforce either maint mode or drain mode. It is not allowed to set more than
* one flag at once. The equivalent "inherited" flag is propagated to all
* tracking servers. Maintenance mode disables health checks (but not agent
* checks). When either the flag is already set or no flag is passed, nothing
MINOR: server: make srv_set_admin_state() capable of telling why this happens It will be important to help debugging some DNS resolution issues to know why a server was marked down, so let's make the function support a 3rd argument with an indication of the reason. Passing NULL will keep the message as-is.
2016-11-07 09:53:43 -05:00
* is done. If <cause> is non-null, it will be displayed at the end of the log
* lines to justify the state change.
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
*
* Must be called with the server lock held.
MEDIUM: server: properly support and propagate the maintenance status This change now involves a new flag SRV_ADMF_IMAINT to note that the maintenance status of a server is inherited from another server. Thus, we know at each server level in the chain if it's running, in forced maintenance or in a maintenance status because it tracks another server, or even in both states. Disabling a server propagates this flag down to other servers. Enabling a server flushes the flag down. A server becomes up again once both of its flags are cleared. Two new functions "srv_adm_set_maint()" and "srv_adm_set_ready()" are used to manipulate this maintenance status. They're used by the CLI and the stats page. Now the stats page always says "MAINT" instead of "MAINT(via)" and it's only the chk/down field which reports "via x/y" when the status is inherited from another server, but it doesn't say it when a server was forced into maintenance. The CSV output indicates "MAINT (via x/y)" instead of only "MAINT(via)". This is the most accurate representation. One important thing is that now entering/leaving maintenance for a tracking server correctly follows the state of the tracked server.
2014-05-16 05:25:16 -04:00
*/
MINOR: server: change adm_st_chg_cause storage type Even though it doesn't look like it at first glance, this is more like a cleanup than an actual code improvement: Given that srv->adm_st_chg_cause has been used to exclusively store static strings ever since it was implemented, we make the choice to store it as an enum instead of a fixed-size string within server struct. This will allow to save some space in server struct, and will make it more easily exportable (ie: event handlers) because of the reduced memory footprint during handling and the ability to later get the corresponding human-readable message when it's explicitly needed.
2023-04-03 11:40:28 -04:00
void srv_set_admin_flag(struct server *s, enum srv_admin mode, enum srv_adm_st_chg_cause cause)
MEDIUM: server: properly support and propagate the maintenance status This change now involves a new flag SRV_ADMF_IMAINT to note that the maintenance status of a server is inherited from another server. Thus, we know at each server level in the chain if it's running, in forced maintenance or in a maintenance status because it tracks another server, or even in both states. Disabling a server propagates this flag down to other servers. Enabling a server flushes the flag down. A server becomes up again once both of its flags are cleared. Two new functions "srv_adm_set_maint()" and "srv_adm_set_ready()" are used to manipulate this maintenance status. They're used by the CLI and the stats page. Now the stats page always says "MAINT" instead of "MAINT(via)" and it's only the chk/down field which reports "via x/y" when the status is inherited from another server, but it doesn't say it when a server was forced into maintenance. The CSV output indicates "MAINT (via x/y)" instead of only "MAINT(via)". This is the most accurate representation. One important thing is that now entering/leaving maintenance for a tracking server correctly follows the state of the tracked server.
2014-05-16 05:25:16 -04:00
{
struct server *srv;
if (!mode)
return;
/* stop going down as soon as we meet a server already in the same state */
MEDIUM: check: server states and weight propagation re-work The server state and weight was reworked to handle "pending" values updated by checks/CLI/LUA/agent. These values are commited to be propagated to the LB stack. In further dev related to multi-thread, the commit will be handled into a sync point. Pending values are named using the prefix 'next_' Current values used by the LB stack are named 'cur_'
2017-08-31 08:41:55 -04:00
if (s->next_admin & mode)
MEDIUM: server: properly support and propagate the maintenance status This change now involves a new flag SRV_ADMF_IMAINT to note that the maintenance status of a server is inherited from another server. Thus, we know at each server level in the chain if it's running, in forced maintenance or in a maintenance status because it tracks another server, or even in both states. Disabling a server propagates this flag down to other servers. Enabling a server flushes the flag down. A server becomes up again once both of its flags are cleared. Two new functions "srv_adm_set_maint()" and "srv_adm_set_ready()" are used to manipulate this maintenance status. They're used by the CLI and the stats page. Now the stats page always says "MAINT" instead of "MAINT(via)" and it's only the chk/down field which reports "via x/y" when the status is inherited from another server, but it doesn't say it when a server was forced into maintenance. The CSV output indicates "MAINT (via x/y)" instead of only "MAINT(via)". This is the most accurate representation. One important thing is that now entering/leaving maintenance for a tracking server correctly follows the state of the tracked server.
2014-05-16 05:25:16 -04:00
return;
MEDIUM: check: server states and weight propagation re-work The server state and weight was reworked to handle "pending" values updated by checks/CLI/LUA/agent. These values are commited to be propagated to the LB stack. In further dev related to multi-thread, the commit will be handled into a sync point. Pending values are named using the prefix 'next_' Current values used by the LB stack are named 'cur_'
2017-08-31 08:41:55 -04:00
s->next_admin |= mode;
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
BUG/MEDIUM: server: update our local state before propagating changes Commit 3ff577e ("MAJOR: server: make server state changes synchronous again") reintroduced synchronous server state changes. However, during the previous change from synchronous to asynchronous, the server state propagation was placed at the end of the function to ease the code changes, and the commit above didn't put it back at its place. This has resulted in propagated states to be incomplete. For example, making a server leave maintenance would make it up but would leave its tracking servers down because they see their tracked server is still down. Let's just move the status update right to its place. It also adds the benefit of reporting state changes in the order they appear and not in reverse. No backport is needed.
2018-08-21 02:22:26 -04:00
/* propagate changes */
MINOR: server: pass adm and op cause to srv_update_status() Operational and administrative state change causes are not propagated through srv_update_status(), instead they are directly consumed within the function to provide additional info during the call when required. Thus, there is no valid reason for keeping adm and op causes within server struct. We are wasting space and keeping uneeded complexity. We now exlicitly pass change type (operational or administrative) and associated cause to srv_update_status() so that no extra storage is needed since those values are only relevant from srv_update_status().
2023-04-18 05:00:17 -04:00
srv_update_status(s, 1, cause);
BUG/MEDIUM: server: update our local state before propagating changes Commit 3ff577e ("MAJOR: server: make server state changes synchronous again") reintroduced synchronous server state changes. However, during the previous change from synchronous to asynchronous, the server state propagation was placed at the end of the function to ease the code changes, and the commit above didn't put it back at its place. This has resulted in propagated states to be incomplete. For example, making a server leave maintenance would make it up but would leave its tracking servers down because they see their tracked server is still down. Let's just move the status update right to its place. It also adds the benefit of reporting state changes in the order they appear and not in reverse. No backport is needed.
2018-08-21 02:22:26 -04:00
MAJOR: checks: add support for a new "drain" administrative mode This patch adds support for a new "drain" mode. So now we have 3 admin modes for a server : - READY - DRAIN - MAINT The drain mode disables load balancing but leaves the server up. It can coexist with maint, except that maint has precedence. It is also inherited from tracked servers, so just like maint, it's represented with 2 bits. New functions were designed to set/clear each flag and to propagate the changes to tracking servers when relevant, and to log the changes. Existing functions srv_set_adm_maint() and srv_set_adm_ready() were replaced to make use of the new functions. Currently the drain mode is not yet used, however the whole logic was tested with all combinations of set/clear of both flags in various orders to catch all corner cases.
2014-05-22 10:14:34 -04:00
/* stop going down if the equivalent flag was already present (forced or inherited) */
MEDIUM: check: server states and weight propagation re-work The server state and weight was reworked to handle "pending" values updated by checks/CLI/LUA/agent. These values are commited to be propagated to the LB stack. In further dev related to multi-thread, the commit will be handled into a sync point. Pending values are named using the prefix 'next_' Current values used by the LB stack are named 'cur_'
2017-08-31 08:41:55 -04:00
if (((mode & SRV_ADMF_MAINT) && (s->next_admin & ~mode & SRV_ADMF_MAINT)) ||
((mode & SRV_ADMF_DRAIN) && (s->next_admin & ~mode & SRV_ADMF_DRAIN)))
BUG/MEDIUM: server: update our local state before propagating changes Commit 3ff577e ("MAJOR: server: make server state changes synchronous again") reintroduced synchronous server state changes. However, during the previous change from synchronous to asynchronous, the server state propagation was placed at the end of the function to ease the code changes, and the commit above didn't put it back at its place. This has resulted in propagated states to be incomplete. For example, making a server leave maintenance would make it up but would leave its tracking servers down because they see their tracked server is still down. Let's just move the status update right to its place. It also adds the benefit of reporting state changes in the order they appear and not in reverse. No backport is needed.
2018-08-21 02:22:26 -04:00
return;
MAJOR: checks: add support for a new "drain" administrative mode This patch adds support for a new "drain" mode. So now we have 3 admin modes for a server : - READY - DRAIN - MAINT The drain mode disables load balancing but leaves the server up. It can coexist with maint, except that maint has precedence. It is also inherited from tracked servers, so just like maint, it's represented with 2 bits. New functions were designed to set/clear each flag and to propagate the changes to tracking servers when relevant, and to log the changes. Existing functions srv_set_adm_maint() and srv_set_adm_ready() were replaced to make use of the new functions. Currently the drain mode is not yet used, however the whole logic was tested with all combinations of set/clear of both flags in various orders to catch all corner cases.
2014-05-22 10:14:34 -04:00
/* compute the inherited flag to propagate */
if (mode & SRV_ADMF_MAINT)
mode = SRV_ADMF_IMAINT;
else if (mode & SRV_ADMF_DRAIN)
mode = SRV_ADMF_IDRAIN;
MEDIUM: threads/server: Use the server lock to protect health check and cli concurrency
2017-10-23 08:39:51 -04:00
for (srv = s->trackers; srv; srv = srv->tracknext) {
BUILD: threads: Rename SPIN/RWLOCK macros using HA_ prefix This remove any name conflicts, especially on Solaris.
2017-11-07 04:42:54 -05:00
HA_SPIN_LOCK(SERVER_LOCK, &srv->lock);
MINOR: server: make srv_set_admin_state() capable of telling why this happens It will be important to help debugging some DNS resolution issues to know why a server was marked down, so let's make the function support a 3rd argument with an indication of the reason. Passing NULL will keep the message as-is.
2016-11-07 09:53:43 -05:00
srv_set_admin_flag(srv, mode, cause);
BUG/MEDIUM: threads/server: Fix deadlock in srv_set_stopping/srv_set_admin_flag Because of a typo (HA_SPIN_LOCK instead of HA_SPIN_UNLOCK), there is a deadlock in srv_set_stopping and srv_set_admin_flag when there is at least one trackers. This patch must be backported in 1.8.
2018-01-24 15:49:41 -05:00
HA_SPIN_UNLOCK(SERVER_LOCK, &srv->lock);
MEDIUM: threads/server: Use the server lock to protect health check and cli concurrency
2017-10-23 08:39:51 -04:00
}
MEDIUM: server: properly support and propagate the maintenance status This change now involves a new flag SRV_ADMF_IMAINT to note that the maintenance status of a server is inherited from another server. Thus, we know at each server level in the chain if it's running, in forced maintenance or in a maintenance status because it tracks another server, or even in both states. Disabling a server propagates this flag down to other servers. Enabling a server flushes the flag down. A server becomes up again once both of its flags are cleared. Two new functions "srv_adm_set_maint()" and "srv_adm_set_ready()" are used to manipulate this maintenance status. They're used by the CLI and the stats page. Now the stats page always says "MAINT" instead of "MAINT(via)" and it's only the chk/down field which reports "via x/y" when the status is inherited from another server, but it doesn't say it when a server was forced into maintenance. The CSV output indicates "MAINT (via x/y)" instead of only "MAINT(via)". This is the most accurate representation. One important thing is that now entering/leaving maintenance for a tracking server correctly follows the state of the tracked server.
2014-05-16 05:25:16 -04:00
}
MAJOR: checks: add support for a new "drain" administrative mode This patch adds support for a new "drain" mode. So now we have 3 admin modes for a server : - READY - DRAIN - MAINT The drain mode disables load balancing but leaves the server up. It can coexist with maint, except that maint has precedence. It is also inherited from tracked servers, so just like maint, it's represented with 2 bits. New functions were designed to set/clear each flag and to propagate the changes to tracking servers when relevant, and to log the changes. Existing functions srv_set_adm_maint() and srv_set_adm_ready() were replaced to make use of the new functions. Currently the drain mode is not yet used, however the whole logic was tested with all combinations of set/clear of both flags in various orders to catch all corner cases.
2014-05-22 10:14:34 -04:00
/* Disables admin flag <mode> (among SRV_ADMF_*) on server <s>. This is used to
* stop enforcing either maint mode or drain mode. It is not allowed to set more
* than one flag at once. The equivalent "inherited" flag is propagated to all
* tracking servers. Leaving maintenance mode re-enables health checks. When
* either the flag is already cleared or no flag is passed, nothing is done.
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
*
* Must be called with the server lock held.
MEDIUM: server: properly support and propagate the maintenance status This change now involves a new flag SRV_ADMF_IMAINT to note that the maintenance status of a server is inherited from another server. Thus, we know at each server level in the chain if it's running, in forced maintenance or in a maintenance status because it tracks another server, or even in both states. Disabling a server propagates this flag down to other servers. Enabling a server flushes the flag down. A server becomes up again once both of its flags are cleared. Two new functions "srv_adm_set_maint()" and "srv_adm_set_ready()" are used to manipulate this maintenance status. They're used by the CLI and the stats page. Now the stats page always says "MAINT" instead of "MAINT(via)" and it's only the chk/down field which reports "via x/y" when the status is inherited from another server, but it doesn't say it when a server was forced into maintenance. The CSV output indicates "MAINT (via x/y)" instead of only "MAINT(via)". This is the most accurate representation. One important thing is that now entering/leaving maintenance for a tracking server correctly follows the state of the tracked server.
2014-05-16 05:25:16 -04:00
*/
MAJOR: checks: add support for a new "drain" administrative mode This patch adds support for a new "drain" mode. So now we have 3 admin modes for a server : - READY - DRAIN - MAINT The drain mode disables load balancing but leaves the server up. It can coexist with maint, except that maint has precedence. It is also inherited from tracked servers, so just like maint, it's represented with 2 bits. New functions were designed to set/clear each flag and to propagate the changes to tracking servers when relevant, and to log the changes. Existing functions srv_set_adm_maint() and srv_set_adm_ready() were replaced to make use of the new functions. Currently the drain mode is not yet used, however the whole logic was tested with all combinations of set/clear of both flags in various orders to catch all corner cases.
2014-05-22 10:14:34 -04:00
void srv_clr_admin_flag(struct server *s, enum srv_admin mode)
MEDIUM: server: properly support and propagate the maintenance status This change now involves a new flag SRV_ADMF_IMAINT to note that the maintenance status of a server is inherited from another server. Thus, we know at each server level in the chain if it's running, in forced maintenance or in a maintenance status because it tracks another server, or even in both states. Disabling a server propagates this flag down to other servers. Enabling a server flushes the flag down. A server becomes up again once both of its flags are cleared. Two new functions "srv_adm_set_maint()" and "srv_adm_set_ready()" are used to manipulate this maintenance status. They're used by the CLI and the stats page. Now the stats page always says "MAINT" instead of "MAINT(via)" and it's only the chk/down field which reports "via x/y" when the status is inherited from another server, but it doesn't say it when a server was forced into maintenance. The CSV output indicates "MAINT (via x/y)" instead of only "MAINT(via)". This is the most accurate representation. One important thing is that now entering/leaving maintenance for a tracking server correctly follows the state of the tracked server.
2014-05-16 05:25:16 -04:00
{
struct server *srv;
if (!mode)
return;
/* stop going down as soon as we see the flag is not there anymore */
MEDIUM: check: server states and weight propagation re-work The server state and weight was reworked to handle "pending" values updated by checks/CLI/LUA/agent. These values are commited to be propagated to the LB stack. In further dev related to multi-thread, the commit will be handled into a sync point. Pending values are named using the prefix 'next_' Current values used by the LB stack are named 'cur_'
2017-08-31 08:41:55 -04:00
if (!(s->next_admin & mode))
MEDIUM: server: properly support and propagate the maintenance status This change now involves a new flag SRV_ADMF_IMAINT to note that the maintenance status of a server is inherited from another server. Thus, we know at each server level in the chain if it's running, in forced maintenance or in a maintenance status because it tracks another server, or even in both states. Disabling a server propagates this flag down to other servers. Enabling a server flushes the flag down. A server becomes up again once both of its flags are cleared. Two new functions "srv_adm_set_maint()" and "srv_adm_set_ready()" are used to manipulate this maintenance status. They're used by the CLI and the stats page. Now the stats page always says "MAINT" instead of "MAINT(via)" and it's only the chk/down field which reports "via x/y" when the status is inherited from another server, but it doesn't say it when a server was forced into maintenance. The CSV output indicates "MAINT (via x/y)" instead of only "MAINT(via)". This is the most accurate representation. One important thing is that now entering/leaving maintenance for a tracking server correctly follows the state of the tracked server.
2014-05-16 05:25:16 -04:00
return;
MEDIUM: check: server states and weight propagation re-work The server state and weight was reworked to handle "pending" values updated by checks/CLI/LUA/agent. These values are commited to be propagated to the LB stack. In further dev related to multi-thread, the commit will be handled into a sync point. Pending values are named using the prefix 'next_' Current values used by the LB stack are named 'cur_'
2017-08-31 08:41:55 -04:00
s->next_admin &= ~mode;
MEDIUM: server: properly support and propagate the maintenance status This change now involves a new flag SRV_ADMF_IMAINT to note that the maintenance status of a server is inherited from another server. Thus, we know at each server level in the chain if it's running, in forced maintenance or in a maintenance status because it tracks another server, or even in both states. Disabling a server propagates this flag down to other servers. Enabling a server flushes the flag down. A server becomes up again once both of its flags are cleared. Two new functions "srv_adm_set_maint()" and "srv_adm_set_ready()" are used to manipulate this maintenance status. They're used by the CLI and the stats page. Now the stats page always says "MAINT" instead of "MAINT(via)" and it's only the chk/down field which reports "via x/y" when the status is inherited from another server, but it doesn't say it when a server was forced into maintenance. The CSV output indicates "MAINT (via x/y)" instead of only "MAINT(via)". This is the most accurate representation. One important thing is that now entering/leaving maintenance for a tracking server correctly follows the state of the tracked server.
2014-05-16 05:25:16 -04:00
BUG/MEDIUM: server: update our local state before propagating changes Commit 3ff577e ("MAJOR: server: make server state changes synchronous again") reintroduced synchronous server state changes. However, during the previous change from synchronous to asynchronous, the server state propagation was placed at the end of the function to ease the code changes, and the commit above didn't put it back at its place. This has resulted in propagated states to be incomplete. For example, making a server leave maintenance would make it up but would leave its tracking servers down because they see their tracked server is still down. Let's just move the status update right to its place. It also adds the benefit of reporting state changes in the order they appear and not in reverse. No backport is needed.
2018-08-21 02:22:26 -04:00
/* propagate changes */
MINOR: server: pass adm and op cause to srv_update_status() Operational and administrative state change causes are not propagated through srv_update_status(), instead they are directly consumed within the function to provide additional info during the call when required. Thus, there is no valid reason for keeping adm and op causes within server struct. We are wasting space and keeping uneeded complexity. We now exlicitly pass change type (operational or administrative) and associated cause to srv_update_status() so that no extra storage is needed since those values are only relevant from srv_update_status().
2023-04-18 05:00:17 -04:00
srv_update_status(s, 1, SRV_ADM_STCHGC_NONE);
BUG/MEDIUM: server: update our local state before propagating changes Commit 3ff577e ("MAJOR: server: make server state changes synchronous again") reintroduced synchronous server state changes. However, during the previous change from synchronous to asynchronous, the server state propagation was placed at the end of the function to ease the code changes, and the commit above didn't put it back at its place. This has resulted in propagated states to be incomplete. For example, making a server leave maintenance would make it up but would leave its tracking servers down because they see their tracked server is still down. Let's just move the status update right to its place. It also adds the benefit of reporting state changes in the order they appear and not in reverse. No backport is needed.
2018-08-21 02:22:26 -04:00
MAJOR: checks: add support for a new "drain" administrative mode This patch adds support for a new "drain" mode. So now we have 3 admin modes for a server : - READY - DRAIN - MAINT The drain mode disables load balancing but leaves the server up. It can coexist with maint, except that maint has precedence. It is also inherited from tracked servers, so just like maint, it's represented with 2 bits. New functions were designed to set/clear each flag and to propagate the changes to tracking servers when relevant, and to log the changes. Existing functions srv_set_adm_maint() and srv_set_adm_ready() were replaced to make use of the new functions. Currently the drain mode is not yet used, however the whole logic was tested with all combinations of set/clear of both flags in various orders to catch all corner cases.
2014-05-22 10:14:34 -04:00
/* stop going down if the equivalent flag is still present (forced or inherited) */
MEDIUM: check: server states and weight propagation re-work The server state and weight was reworked to handle "pending" values updated by checks/CLI/LUA/agent. These values are commited to be propagated to the LB stack. In further dev related to multi-thread, the commit will be handled into a sync point. Pending values are named using the prefix 'next_' Current values used by the LB stack are named 'cur_'
2017-08-31 08:41:55 -04:00
if (((mode & SRV_ADMF_MAINT) && (s->next_admin & SRV_ADMF_MAINT)) ||
((mode & SRV_ADMF_DRAIN) && (s->next_admin & SRV_ADMF_DRAIN)))
BUG/MEDIUM: server: update our local state before propagating changes Commit 3ff577e ("MAJOR: server: make server state changes synchronous again") reintroduced synchronous server state changes. However, during the previous change from synchronous to asynchronous, the server state propagation was placed at the end of the function to ease the code changes, and the commit above didn't put it back at its place. This has resulted in propagated states to be incomplete. For example, making a server leave maintenance would make it up but would leave its tracking servers down because they see their tracked server is still down. Let's just move the status update right to its place. It also adds the benefit of reporting state changes in the order they appear and not in reverse. No backport is needed.
2018-08-21 02:22:26 -04:00
return;
MEDIUM: server: properly support and propagate the maintenance status This change now involves a new flag SRV_ADMF_IMAINT to note that the maintenance status of a server is inherited from another server. Thus, we know at each server level in the chain if it's running, in forced maintenance or in a maintenance status because it tracks another server, or even in both states. Disabling a server propagates this flag down to other servers. Enabling a server flushes the flag down. A server becomes up again once both of its flags are cleared. Two new functions "srv_adm_set_maint()" and "srv_adm_set_ready()" are used to manipulate this maintenance status. They're used by the CLI and the stats page. Now the stats page always says "MAINT" instead of "MAINT(via)" and it's only the chk/down field which reports "via x/y" when the status is inherited from another server, but it doesn't say it when a server was forced into maintenance. The CSV output indicates "MAINT (via x/y)" instead of only "MAINT(via)". This is the most accurate representation. One important thing is that now entering/leaving maintenance for a tracking server correctly follows the state of the tracked server.
2014-05-16 05:25:16 -04:00
MAJOR: checks: add support for a new "drain" administrative mode This patch adds support for a new "drain" mode. So now we have 3 admin modes for a server : - READY - DRAIN - MAINT The drain mode disables load balancing but leaves the server up. It can coexist with maint, except that maint has precedence. It is also inherited from tracked servers, so just like maint, it's represented with 2 bits. New functions were designed to set/clear each flag and to propagate the changes to tracking servers when relevant, and to log the changes. Existing functions srv_set_adm_maint() and srv_set_adm_ready() were replaced to make use of the new functions. Currently the drain mode is not yet used, however the whole logic was tested with all combinations of set/clear of both flags in various orders to catch all corner cases.
2014-05-22 10:14:34 -04:00
if (mode & SRV_ADMF_MAINT)
mode = SRV_ADMF_IMAINT;
else if (mode & SRV_ADMF_DRAIN)
mode = SRV_ADMF_IDRAIN;
MEDIUM: server: properly support and propagate the maintenance status This change now involves a new flag SRV_ADMF_IMAINT to note that the maintenance status of a server is inherited from another server. Thus, we know at each server level in the chain if it's running, in forced maintenance or in a maintenance status because it tracks another server, or even in both states. Disabling a server propagates this flag down to other servers. Enabling a server flushes the flag down. A server becomes up again once both of its flags are cleared. Two new functions "srv_adm_set_maint()" and "srv_adm_set_ready()" are used to manipulate this maintenance status. They're used by the CLI and the stats page. Now the stats page always says "MAINT" instead of "MAINT(via)" and it's only the chk/down field which reports "via x/y" when the status is inherited from another server, but it doesn't say it when a server was forced into maintenance. The CSV output indicates "MAINT (via x/y)" instead of only "MAINT(via)". This is the most accurate representation. One important thing is that now entering/leaving maintenance for a tracking server correctly follows the state of the tracked server.
2014-05-16 05:25:16 -04:00
MEDIUM: threads/server: Use the server lock to protect health check and cli concurrency
2017-10-23 08:39:51 -04:00
for (srv = s->trackers; srv; srv = srv->tracknext) {
BUILD: threads: Rename SPIN/RWLOCK macros using HA_ prefix This remove any name conflicts, especially on Solaris.
2017-11-07 04:42:54 -05:00
HA_SPIN_LOCK(SERVER_LOCK, &srv->lock);
MAJOR: checks: add support for a new "drain" administrative mode This patch adds support for a new "drain" mode. So now we have 3 admin modes for a server : - READY - DRAIN - MAINT The drain mode disables load balancing but leaves the server up. It can coexist with maint, except that maint has precedence. It is also inherited from tracked servers, so just like maint, it's represented with 2 bits. New functions were designed to set/clear each flag and to propagate the changes to tracking servers when relevant, and to log the changes. Existing functions srv_set_adm_maint() and srv_set_adm_ready() were replaced to make use of the new functions. Currently the drain mode is not yet used, however the whole logic was tested with all combinations of set/clear of both flags in various orders to catch all corner cases.
2014-05-22 10:14:34 -04:00
srv_clr_admin_flag(srv, mode);
BUILD: threads: Rename SPIN/RWLOCK macros using HA_ prefix This remove any name conflicts, especially on Solaris.
2017-11-07 04:42:54 -05:00
HA_SPIN_UNLOCK(SERVER_LOCK, &srv->lock);
MEDIUM: threads/server: Use the server lock to protect health check and cli concurrency
2017-10-23 08:39:51 -04:00
}
MEDIUM: server: properly support and propagate the maintenance status This change now involves a new flag SRV_ADMF_IMAINT to note that the maintenance status of a server is inherited from another server. Thus, we know at each server level in the chain if it's running, in forced maintenance or in a maintenance status because it tracks another server, or even in both states. Disabling a server propagates this flag down to other servers. Enabling a server flushes the flag down. A server becomes up again once both of its flags are cleared. Two new functions "srv_adm_set_maint()" and "srv_adm_set_ready()" are used to manipulate this maintenance status. They're used by the CLI and the stats page. Now the stats page always says "MAINT" instead of "MAINT(via)" and it's only the chk/down field which reports "via x/y" when the status is inherited from another server, but it doesn't say it when a server was forced into maintenance. The CSV output indicates "MAINT (via x/y)" instead of only "MAINT(via)". This is the most accurate representation. One important thing is that now entering/leaving maintenance for a tracking server correctly follows the state of the tracked server.
2014-05-16 05:25:16 -04:00
}
BUG/MEDIUM: servers: properly propagate the maintenance states during startup Right now there is an issue with the way the maintenance flags are propagated upon startup. They are not propagate, just copied from the tracked server. This implies that depending on the server's order, some tracking servers may not be marked down. For example this configuration does not work as expected : server s1 1.1.1.1:8000 track s2 server s2 1.1.1.1:8000 track s3 server s3 1.1.1.1:8000 track s4 server s4 wtap:8000 check inter 1s disabled It results in s1/s2 being up, and s3/s4 being down, while all of them should be down. The only clean way to process this is to run through all "root" servers (those not tracking any other server), and to propagate their state down to all their trackers. This is the same algorithm used to propagate the state changes. It has to be done both to compute the IDRAIN flag and the IMAINT flag. However, doing so requires that tracking servers are not marked as inherited maintenance anymore while parsing the configuration (and given that it is wrong, better drop it). This fix also addresses another side effect of the bug above which is that the IDRAIN/IMAINT flags are stored in the state files, and if restored while the tracked server doesn't have the equivalent flag, the servers may end up in a situation where it's impossible to remove these flags. For example in the configuration above, after removing "disabled" on server s4, the other servers would have remained down, and not anymore with this fix. Similarly, the combination of IMAINT or IDRAIN with their respective forced modes was not accepted on reload, which is wrong as well. This bug has been present at least since 1.5, maybe even 1.4 (it came with tracking support). The fix needs to be backported there, though the srv-state parts are irrelevant. This commit relies on previous patch to silence warnings on startup.
2016-11-03 14:22:19 -04:00
/* principle: propagate maint and drain to tracking servers. This is useful
* upon startup so that inherited states are correct.
*/
static void srv_propagate_admin_state(struct server *srv)
{
struct server *srv2;
if (!srv->trackers)
return;
for (srv2 = srv->trackers; srv2; srv2 = srv2->tracknext) {
BUILD: threads: Rename SPIN/RWLOCK macros using HA_ prefix This remove any name conflicts, especially on Solaris.
2017-11-07 04:42:54 -05:00
HA_SPIN_LOCK(SERVER_LOCK, &srv2->lock);
MEDIUM: check: server states and weight propagation re-work The server state and weight was reworked to handle "pending" values updated by checks/CLI/LUA/agent. These values are commited to be propagated to the LB stack. In further dev related to multi-thread, the commit will be handled into a sync point. Pending values are named using the prefix 'next_' Current values used by the LB stack are named 'cur_'
2017-08-31 08:41:55 -04:00
if (srv->next_admin & (SRV_ADMF_MAINT | SRV_ADMF_CMAINT))
MINOR: server: change adm_st_chg_cause storage type Even though it doesn't look like it at first glance, this is more like a cleanup than an actual code improvement: Given that srv->adm_st_chg_cause has been used to exclusively store static strings ever since it was implemented, we make the choice to store it as an enum instead of a fixed-size string within server struct. This will allow to save some space in server struct, and will make it more easily exportable (ie: event handlers) because of the reduced memory footprint during handling and the ability to later get the corresponding human-readable message when it's explicitly needed.
2023-04-03 11:40:28 -04:00
srv_set_admin_flag(srv2, SRV_ADMF_IMAINT, SRV_ADM_STCHGC_NONE);
BUG/MEDIUM: servers: properly propagate the maintenance states during startup Right now there is an issue with the way the maintenance flags are propagated upon startup. They are not propagate, just copied from the tracked server. This implies that depending on the server's order, some tracking servers may not be marked down. For example this configuration does not work as expected : server s1 1.1.1.1:8000 track s2 server s2 1.1.1.1:8000 track s3 server s3 1.1.1.1:8000 track s4 server s4 wtap:8000 check inter 1s disabled It results in s1/s2 being up, and s3/s4 being down, while all of them should be down. The only clean way to process this is to run through all "root" servers (those not tracking any other server), and to propagate their state down to all their trackers. This is the same algorithm used to propagate the state changes. It has to be done both to compute the IDRAIN flag and the IMAINT flag. However, doing so requires that tracking servers are not marked as inherited maintenance anymore while parsing the configuration (and given that it is wrong, better drop it). This fix also addresses another side effect of the bug above which is that the IDRAIN/IMAINT flags are stored in the state files, and if restored while the tracked server doesn't have the equivalent flag, the servers may end up in a situation where it's impossible to remove these flags. For example in the configuration above, after removing "disabled" on server s4, the other servers would have remained down, and not anymore with this fix. Similarly, the combination of IMAINT or IDRAIN with their respective forced modes was not accepted on reload, which is wrong as well. This bug has been present at least since 1.5, maybe even 1.4 (it came with tracking support). The fix needs to be backported there, though the srv-state parts are irrelevant. This commit relies on previous patch to silence warnings on startup.
2016-11-03 14:22:19 -04:00
MEDIUM: check: server states and weight propagation re-work The server state and weight was reworked to handle "pending" values updated by checks/CLI/LUA/agent. These values are commited to be propagated to the LB stack. In further dev related to multi-thread, the commit will be handled into a sync point. Pending values are named using the prefix 'next_' Current values used by the LB stack are named 'cur_'
2017-08-31 08:41:55 -04:00
if (srv->next_admin & SRV_ADMF_DRAIN)
MINOR: server: change adm_st_chg_cause storage type Even though it doesn't look like it at first glance, this is more like a cleanup than an actual code improvement: Given that srv->adm_st_chg_cause has been used to exclusively store static strings ever since it was implemented, we make the choice to store it as an enum instead of a fixed-size string within server struct. This will allow to save some space in server struct, and will make it more easily exportable (ie: event handlers) because of the reduced memory footprint during handling and the ability to later get the corresponding human-readable message when it's explicitly needed.
2023-04-03 11:40:28 -04:00
srv_set_admin_flag(srv2, SRV_ADMF_IDRAIN, SRV_ADM_STCHGC_NONE);
BUILD: threads: Rename SPIN/RWLOCK macros using HA_ prefix This remove any name conflicts, especially on Solaris.
2017-11-07 04:42:54 -05:00
HA_SPIN_UNLOCK(SERVER_LOCK, &srv2->lock);
BUG/MEDIUM: servers: properly propagate the maintenance states during startup Right now there is an issue with the way the maintenance flags are propagated upon startup. They are not propagate, just copied from the tracked server. This implies that depending on the server's order, some tracking servers may not be marked down. For example this configuration does not work as expected : server s1 1.1.1.1:8000 track s2 server s2 1.1.1.1:8000 track s3 server s3 1.1.1.1:8000 track s4 server s4 wtap:8000 check inter 1s disabled It results in s1/s2 being up, and s3/s4 being down, while all of them should be down. The only clean way to process this is to run through all "root" servers (those not tracking any other server), and to propagate their state down to all their trackers. This is the same algorithm used to propagate the state changes. It has to be done both to compute the IDRAIN flag and the IMAINT flag. However, doing so requires that tracking servers are not marked as inherited maintenance anymore while parsing the configuration (and given that it is wrong, better drop it). This fix also addresses another side effect of the bug above which is that the IDRAIN/IMAINT flags are stored in the state files, and if restored while the tracked server doesn't have the equivalent flag, the servers may end up in a situation where it's impossible to remove these flags. For example in the configuration above, after removing "disabled" on server s4, the other servers would have remained down, and not anymore with this fix. Similarly, the combination of IMAINT or IDRAIN with their respective forced modes was not accepted on reload, which is wrong as well. This bug has been present at least since 1.5, maybe even 1.4 (it came with tracking support). The fix needs to be backported there, though the srv-state parts are irrelevant. This commit relies on previous patch to silence warnings on startup.
2016-11-03 14:22:19 -04:00
}
}
/* Compute and propagate the admin states for all servers in proxy <px>.
* Only servers *not* tracking another one are considered, because other
* ones will be handled when the server they track is visited.
*/
void srv_compute_all_admin_states(struct proxy *px)
{
struct server *srv;
for (srv = px->srv; srv; srv = srv->next) {
if (srv->track)
continue;
srv_propagate_admin_state(srv);
}
}
MEDIUM: server: move parsing of keyword "id" to server.c This is the first keyword to be moved to server.c.
2012-10-10 11:51:05 -04:00
/* Note: must not be declared <const> as its list will be overwritten.
DOC: server: document what to check for when adding new server keywords It's too easy to overlook the dynamic servers when adding new server keywords, and the fields on each keyword line are totally obscure. This commit adds a title to each column of the table and explains what is expected and what to check for when adding a keyword.
2024-09-10 12:50:12 -04:00
*
*** P L E A S E R E A D B E L O W B E F O R E T O U C H I N G !!! ***
*
* Some mistakes are commonly repeated when touching this table, so please
* read the following rules before changing / adding an entry, and better
* ask on the mailing list in case of doubt.
*
* - this list is alphabetically ordered, doing so helps all code contributors
* spot how to name a keyword, which helps users thanks to a form of naming
* consistency. Please insert new entries at the right position so as not
* to break alphabetical ordering. If in doubt, sorting the lines in your
* editor should not change anything (or should fix your addition).
*
* - the fields for each entry in the array are, from left to right:
* - the keyword itself (a string, all characters lower case, no special
* chars, no space/dot/underscore, use-dash-to-delimit-multiple-words)
* - the parsing function (edit or copy one close to your needs, parsers
* can easily support multiple keywords if adapted to check args[0]).
* - the number of arguments the keyword takes. Please do not add new
* keywords taking other than exactly 1 argument, they're hard to adapt
* to for external parsers. The special value -1 indicates a variable
* number, used by "source" only. Never do this.
* - whether or not the keyword is supported on default-server lines
* (0 = not supported, 1 = supported). Please do not add unsupported
* keywords without a prior discussion with maintainers on the list,
* as usually it hides a deeper problem.
* - whether or not the keyword is supported for dynamic servers added at
* run time on the CLI (0 = not supported, 1 = supported). Please do not
* add unsupported keywords without a prior discussion with maintainers
* on the list, as usually it hides a deeper problem.
*
* - please also add a short comment reminding what the keyword does.
*
* - please test your changes with default-server and dynamic servers on the
* CLI (see "add server" in the management guide).
*
*** P L E A S E R E A D A B O V E B E F O R E T O U C H I N G !!! ***
*
MEDIUM: server: move parsing of keyword "id" to server.c This is the first keyword to be moved to server.c.
2012-10-10 11:51:05 -04:00
* Optional keywords are also declared with a NULL ->parse() function so that
* the config parser can report an appropriate error when a known keyword was
* not enabled.
*/
static struct srv_kw_list srv_kws = { "ALL", { }, {
DOC: server: document what to check for when adding new server keywords It's too easy to overlook the dynamic servers when adding new server keywords, and the fields on each keyword line are totally obscure. This commit adds a title to each column of the table and explains what is expected and what to check for when adding a keyword.
2024-09-10 12:50:12 -04:00
/* { "keyword", parsing_function, args, def, dyn }, */
MINOR: server: Add parser support for set-proxy-v2-tlv-fmt This commit introduces a generic server-side parsing of type-value pair arguments and allocation of a TLV list via a new keyword called set-proxy-v2-tlv-fmt. This allows to 1) forward any TLV type with the help of fc_pp_tlv, 2) generally, send out any TLV type and value via a log format expression. To have this fully working the connection will need to be updated in a follow-up commit to actually respect the new server TLV list. default-server support has also been implemented.
2023-10-28 14:51:26 -04:00
{ "backup", srv_parse_backup, 0, 1, 1 }, /* Flag as backup server */
MINOR: server: allow cookie for dynamic servers This commit allows "cookie" keyword for dynamic servers. After code review, nothing was found which could prevent a dynamic server to use it. An extra warning is added under cli_parse_add_server() if cookie value is ignored due to a non HTTP backend. This patch is not considered a bugfix. However, it may backported if needed as its impact seems minimal.
2024-03-27 05:50:21 -04:00
{ "cookie", srv_parse_cookie, 1, 1, 1 }, /* Assign a cookie to the server */
MINOR: server: Add parser support for set-proxy-v2-tlv-fmt This commit introduces a generic server-side parsing of type-value pair arguments and allocation of a TLV list via a new keyword called set-proxy-v2-tlv-fmt. This allows to 1) forward any TLV type with the help of fc_pp_tlv, 2) generally, send out any TLV type and value via a log format expression. To have this fully working the connection will need to be updated in a follow-up commit to actually respect the new server TLV list. default-server support has also been implemented.
2023-10-28 14:51:26 -04:00
{ "disabled", srv_parse_disabled, 0, 1, 1 }, /* Start the server in 'disabled' state */
BUG/MINOR: server: reject enabled for dynamic server Since their first implementation, dynamic servers are created into maintenance state. This has been done purposely to avoid immediate activation of a newly inserted server. However, this principle is incompatible if "enabled" keyword is used on "add server". The newly created instance will be unreacheable as proxy load-balancing algorithm is not informed of its presence via srv_lb_propagate(). The new server could be unblocked by toggling its state with "disable server" / "enable server" commands, which will trigger srv_lb_propagate() invocation. To avoid this unexpected state, simply forbid "enabled" keyword for dynamic servers. In the long-term, it could be possible to re authorize it but at least this requires to call srv_lb_propagate() on dynamic server creation. This should fix github issue #2497. This patch should not be backported as-is, to avoid breaking dynamic servers API on stable versions. "enabled" should instead be ignored for them. This will be implemented in a dedicated patch on top of 2.9.
2024-03-22 12:40:16 -04:00
{ "enabled", srv_parse_enabled, 0, 1, 0 }, /* Start the server in 'enabled' state */
MINOR: server: Add parser support for set-proxy-v2-tlv-fmt This commit introduces a generic server-side parsing of type-value pair arguments and allocation of a TLV list via a new keyword called set-proxy-v2-tlv-fmt. This allows to 1) forward any TLV type with the help of fc_pp_tlv, 2) generally, send out any TLV type and value via a log format expression. To have this fully working the connection will need to be updated in a follow-up commit to actually respect the new server TLV list. default-server support has also been implemented.
2023-10-28 14:51:26 -04:00
{ "error-limit", srv_parse_error_limit, 1, 1, 1 }, /* Configure the consecutive count of check failures to consider a server on error */
MINOR: server: implement GUID support This commit is similar to previous one, except that it implements GUID support for server instances. A guid_node field is inserted into server structure. A new "guid" server keyword is defined.
2024-03-26 10:01:35 -04:00
{ "guid", srv_parse_guid, 1, 0, 1 }, /* Set global unique ID of the server */
MINOR: server: Add parser support for set-proxy-v2-tlv-fmt This commit introduces a generic server-side parsing of type-value pair arguments and allocation of a TLV list via a new keyword called set-proxy-v2-tlv-fmt. This allows to 1) forward any TLV type with the help of fc_pp_tlv, 2) generally, send out any TLV type and value via a log format expression. To have this fully working the connection will need to be updated in a follow-up commit to actually respect the new server TLV list. default-server support has also been implemented.
2023-10-28 14:51:26 -04:00
{ "ws", srv_parse_ws, 1, 1, 1 }, /* websocket protocol */
MEDIUM: lb-chash: Deterministic node hashes based on server address Motivation: When services are discovered through DNS resolution, the order in which DNS records get resolved and assigned to servers is arbitrary. Therefore, even though two HAProxy instances using chash balancing might agree that a particular request should go to server3, it is likely the case that they have assigned different IPs and ports to the server in that slot. This patch adds a server option, "hash-key <key>" which can be set to "id" (the existing behaviour, default), "addr", or "addr-port". By deriving the keys for the chash tree nodes from a server's address and port we ensure that independent HAProxy instances will agree on routing decisions. If an address is not known then the key is derived from the server's puid as it was previously. When adjusting a server's weight, we now check whether the server's hash has changed. If it has, we have to remove all its nodes first, since the node keys will also have to change.
2024-02-16 16:00:35 -05:00
{ "hash-key", srv_parse_hash_key, 1, 1, 1 }, /* Configure how chash keys are computed */
MINOR: server: Add parser support for set-proxy-v2-tlv-fmt This commit introduces a generic server-side parsing of type-value pair arguments and allocation of a TLV list via a new keyword called set-proxy-v2-tlv-fmt. This allows to 1) forward any TLV type with the help of fc_pp_tlv, 2) generally, send out any TLV type and value via a log format expression. To have this fully working the connection will need to be updated in a follow-up commit to actually respect the new server TLV list. default-server support has also been implemented.
2023-10-28 14:51:26 -04:00
{ "id", srv_parse_id, 1, 0, 1 }, /* set id# of server */
MEDIUM: server/mux-h2: implement idle-ping on backend side This commit implements support for idle-ping on the backend side. First, a new server keyword "idle-ping" is defined in configuration parsing. It is used to set the corresponding new server member. The second part of this commit implements idle-ping support on H2 MUX. A new inlined function conn_idle_ping() is defined to access connection idle-ping value. Two new connection flags are defined H2_CF_IDL_PING and H2_CF_IDL_PING_SENT. The first one is set for idle connections via h2c_update_timeout(). On h2_timeout_task() handler, if first flag is set, instead of releasing the connection as before, the second flag is set and tasklet is scheduled. As both flags are now set, h2_process_mux() will proceed to PING emission. The timer has also been rearmed to the idle-ping value. If a PING ACK is received before next timeout, connection timer is refreshed. Else, the connection is released, as with timer expiration. Also of importance, special care is needed when a backend connection is going to idle. In this case, idle-ping timer must be rearmed. Thus a new invokation of h2c_update_timeout() is performed on h2_detach().
2025-04-08 05:09:06 -04:00
{ "idle-ping", srv_parse_idle_ping, 1, 1, 1 }, /* Activate idle ping if mux support it */
MINOR: server: Add parser support for set-proxy-v2-tlv-fmt This commit introduces a generic server-side parsing of type-value pair arguments and allocation of a TLV list via a new keyword called set-proxy-v2-tlv-fmt. This allows to 1) forward any TLV type with the help of fc_pp_tlv, 2) generally, send out any TLV type and value via a log format expression. To have this fully working the connection will need to be updated in a follow-up commit to actually respect the new server TLV list. default-server support has also been implemented.
2023-10-28 14:51:26 -04:00
{ "init-addr", srv_parse_init_addr, 1, 1, 0 }, /* */
MINOR: server: allow init-state for dynamic servers Commit 50322df introduced the init-state keyword, but it didn't enable it for dynamic servers. However, this feature is perfectly desirable for virtual servers too, where someone would like a server inlived through "set server be1/srv1 state ready" to be put out of maintenance in down state until the next health check succeeds. At reading the code, it seems that it's only a matter of allowing this keyword for dynamic servers, as current code path calls srv_adm_set_ready() which incidentally triggers a call to _srv_update_status_adm().
2024-09-10 10:52:42 -04:00
{ "init-state", srv_parse_init_state, 1, 1, 1 }, /* Set the initial state of the server */
MINOR: server: Add parser support for set-proxy-v2-tlv-fmt This commit introduces a generic server-side parsing of type-value pair arguments and allocation of a TLV list via a new keyword called set-proxy-v2-tlv-fmt. This allows to 1) forward any TLV type with the help of fc_pp_tlv, 2) generally, send out any TLV type and value via a log format expression. To have this fully working the connection will need to be updated in a follow-up commit to actually respect the new server TLV list. default-server support has also been implemented.
2023-10-28 14:51:26 -04:00
{ "log-bufsize", srv_parse_log_bufsize, 1, 1, 0 }, /* Set the ring bufsize for log server (only for log backends) */
{ "log-proto", srv_parse_log_proto, 1, 1, 0 }, /* Set the protocol for event messages, only relevant in a log or ring section */
{ "maxconn", srv_parse_maxconn, 1, 1, 1 }, /* Set the max number of concurrent connection */
{ "maxqueue", srv_parse_maxqueue, 1, 1, 1 }, /* Set the max number of connection to put in queue */
{ "max-reuse", srv_parse_max_reuse, 1, 1, 0 }, /* Set the max number of requests on a connection, -1 means unlimited */
{ "minconn", srv_parse_minconn, 1, 1, 1 }, /* Enable a dynamic maxconn limit */
{ "namespace", srv_parse_namespace, 1, 1, 0 }, /* Namespace the server socket belongs to (if supported) */
{ "no-backup", srv_parse_no_backup, 0, 1, 1 }, /* Flag as non-backup server */
{ "no-send-proxy", srv_parse_no_send_proxy, 0, 1, 1 }, /* Disable use of PROXY V1 protocol */
{ "no-send-proxy-v2", srv_parse_no_send_proxy_v2, 0, 1, 1 }, /* Disable use of PROXY V2 protocol */
{ "no-tfo", srv_parse_no_tfo, 0, 1, 1 }, /* Disable use of TCP Fast Open */
{ "non-stick", srv_parse_non_stick, 0, 1, 0 }, /* Disable stick-table persistence */
{ "observe", srv_parse_observe, 1, 1, 1 }, /* Enables health adjusting based on observing communication with the server */
{ "on-error", srv_parse_on_error, 1, 1, 1 }, /* Configure the action on check failure */
{ "on-marked-down", srv_parse_on_marked_down, 1, 1, 1 }, /* Configure the action when a server is marked down */
{ "on-marked-up", srv_parse_on_marked_up, 1, 1, 1 }, /* Configure the action when a server is marked up */
MINOR: server: define pool-conn-name keyword Define a new server keyword pool-conn-name. The purpose of this keyword will be to identify connections inside the idle connections pool, replacing SNI in case SSL is not wanted. This keyword uses a sample expression argument. It thus can reuse existing function parse_srv_expr() for parsing. In the future, it may be necessary to define a keyword variant which uses a logformat for extensability. This patch only implement parsing. Argument is stored inside new server field <pool_conn_name> and expression is generated in _srv_parse_finalize() into <pool_conn_name_expr>. If pool-conn-name is not set but SNI is, the latter is reused automatically as pool-conn-name via _srv_parse_finalize(). This ensures current reuse behavior remains compatible and idle connection reuse will not mix connections with different SNIs by mistake. Main usage will be for rhttp when SSL is not wanted between the two haproxy instances. Previously, it was possible to use "sni" keyword even without SSL on a server line which have a similar effect. However, having a dedicated "pool-conn-name" keyword is deemed clearer. Besides, it would allow for more complex configuration where pool-conn-name and SNI are use in parallel with different values.
2024-05-23 05:14:13 -04:00
{ "pool-conn-name", srv_parse_pool_conn_name, 1, 1, 1 }, /* Define expression to identify connections in idle pool */
MINOR: server: Add parser support for set-proxy-v2-tlv-fmt This commit introduces a generic server-side parsing of type-value pair arguments and allocation of a TLV list via a new keyword called set-proxy-v2-tlv-fmt. This allows to 1) forward any TLV type with the help of fc_pp_tlv, 2) generally, send out any TLV type and value via a log format expression. To have this fully working the connection will need to be updated in a follow-up commit to actually respect the new server TLV list. default-server support has also been implemented.
2023-10-28 14:51:26 -04:00
{ "pool-low-conn", srv_parse_pool_low_conn, 1, 1, 1 }, /* Set the min number of orphan idle connecbefore being allowed to pick from other threads */
{ "pool-max-conn", srv_parse_pool_max_conn, 1, 1, 1 }, /* Set the max number of orphan idle connections, -1 means unlimited */
{ "pool-purge-delay", srv_parse_pool_purge_delay, 1, 1, 1 }, /* Set the time before we destroy orphan idle connections, defaults to 1s */
{ "proto", srv_parse_proto, 1, 1, 1 }, /* Set the proto to use for all outgoing connections */
{ "proxy-v2-options", srv_parse_proxy_v2_options, 1, 1, 1 }, /* options for send-proxy-v2 */
{ "redir", srv_parse_redir, 1, 1, 0 }, /* Enable redirection mode */
{ "resolve-net", srv_parse_resolve_net, 1, 1, 0 }, /* Set the preferred network range for name resolution */
{ "resolve-opts", srv_parse_resolve_opts, 1, 1, 0 }, /* Set options for name resolution */
{ "resolve-prefer", srv_parse_resolve_prefer, 1, 1, 0 }, /* Set the preferred family for name resolution */
{ "resolvers", srv_parse_resolvers, 1, 1, 0 }, /* Configure the resolver to use for name resolution */
{ "send-proxy", srv_parse_send_proxy, 0, 1, 1 }, /* Enforce use of PROXY V1 protocol */
{ "send-proxy-v2", srv_parse_send_proxy_v2, 0, 1, 1 }, /* Enforce use of PROXY V2 protocol */
{ "set-proxy-v2-tlv-fmt", srv_parse_set_proxy_v2_tlv_fmt, 0, 1, 1 }, /* Set TLV of PROXY V2 protocol */
{ "shard", srv_parse_shard, 1, 1, 1 }, /* Server shard (only in peers protocol context) */
{ "slowstart", srv_parse_slowstart, 1, 1, 1 }, /* Set the warm-up timer for a previously failed server */
{ "source", srv_parse_source, -1, 1, 1 }, /* Set the source address to be used to connect to the server */
{ "stick", srv_parse_stick, 0, 1, 0 }, /* Enable stick-table persistence */
MEDIUM: servers: Add strict-maxconn. Maxconn is a bit of a misnomer when it comes to servers, as it doesn't control the maximum number of connections we establish to a server, but the maximum number of simultaneous requests. So add "strict-maxconn", that will make it so we will never establish more connections than maxconn. It extends the meaning of the "restricted" setting of tune.takeover-other-tg-connections, as it will also attempt to get idle connections from other thread groups if strict-maxconn is set.
2025-02-06 11:07:48 -05:00
{ "strict-maxconn", srv_parse_strict_maxconn, 0, 1, 1 }, /* Strictly enforces maxconn */
MINOR: server: Add parser support for set-proxy-v2-tlv-fmt This commit introduces a generic server-side parsing of type-value pair arguments and allocation of a TLV list via a new keyword called set-proxy-v2-tlv-fmt. This allows to 1) forward any TLV type with the help of fc_pp_tlv, 2) generally, send out any TLV type and value via a log format expression. To have this fully working the connection will need to be updated in a follow-up commit to actually respect the new server TLV list. default-server support has also been implemented.
2023-10-28 14:51:26 -04:00
{ "tfo", srv_parse_tfo, 0, 1, 1 }, /* enable TCP Fast Open of server */
{ "track", srv_parse_track, 1, 1, 1 }, /* Set the current state of the server, tracking another one */
{ "socks4", srv_parse_socks4, 1, 1, 0 }, /* Set the socks4 proxy of the server*/
{ "usesrc", srv_parse_usesrc, 0, 1, 1 }, /* safe-guard against usesrc without preceding <source> keyword */
{ "weight", srv_parse_weight, 1, 1, 1 }, /* Set the load-balancing weight */
MEDIUM: server: move parsing of keyword "id" to server.c This is the first keyword to be moved to server.c.
2012-10-10 11:51:05 -04:00
{ NULL, NULL, 0 },
}};
MEDIUM: init: convert all trivial registration calls to initcalls This switches explicit calls to various trivial registration methods for keywords, muxes or protocols from constructors to INITCALL1 at stage STG_REGISTER. All these calls have in common to consume a single pointer and return void. Doing this removes 26 constructors. The following calls were addressed : - acl_register_keywords - bind_register_keywords - cfg_register_keywords - cli_register_kw - flt_register_keywords - http_req_keywords_register - http_res_keywords_register - protocol_register - register_mux_proto - sample_register_convs - sample_register_fetches - srv_register_keywords - tcp_req_conn_keywords_register - tcp_req_cont_keywords_register - tcp_req_sess_keywords_register - tcp_res_cont_keywords_register - flt_register_keywords
2018-11-25 13:14:37 -05:00
INITCALL1(STG_REGISTER, srv_register_keywords, &srv_kws);
MEDIUM: server: move parsing of keyword "id" to server.c This is the first keyword to be moved to server.c.
2012-10-10 11:51:05 -04:00
BUG/MAJOR: server: weight calculation fails for map-based algorithms A crash was reported by Igor at owind when changing a server's weight on the CLI. Lukas Tribus could reproduce a related bug where setting a server's weight would result in the new weight being multiplied by the initial one. The two bugs are the same. The incorrect weight calculation results in the total farm weight being larger than what was initially allocated, causing the map index to be out of bounds on some hashes. It's easy to reproduce using "balance url_param" with a variable param, or with "balance static-rr". It appears that the calculation is made at many places and is not always right and not always wrong the same way. Thus, this patch introduces a new function "server_recalc_eweight()" which is dedicated to this task of computing ->eweight from many other elements including uweight and current time (for slowstart), and all users now switch to use this function. The patch is a bit large but the code was not trivially fixable in a way that could guarantee this situation would not occur anymore. The fix is much more readable and has been verified to work with all algorithms, with both consistent and map-based hashes, and even with static-rr. Slowstart was tested as well, just like enable/disable server. The same bug is very likely present in 1.4 as well, so the patch will probably need to be backported eventhough it will not apply as-is. Thanks to Lukas and Igor for the information they provided to reproduce it.
2013-11-21 05:22:01 -05:00
/* Recomputes the server's eweight based on its state, uweight, the current time,
CLEANUP: assorted typo fixes in the code and comments This is 9th iteration of typo fixes
2020-05-05 15:53:22 -04:00
* and the proxy's algorithm. To be used after updating sv->uweight. The warmup
MAJOR: server: make server state changes synchronous again Now we try to synchronously push updates as they come using the new rdv point, so that the call to the server update function from the main poll loop is not needed anymore. It further reduces the apparent latency in the health checks as the response time almost always appears as 0 ms, resulting in a slightly higher check rate of ~1960 conn/s. Despite this, the CPU consumption has slightly dropped again to ~32% for the same test. The only trick is that the checks code is built with a bit of recursivity because srv_update_status() calls server_recalc_eweight(), and the latter needs to signal srv_update_status() in case of updates. Thus we added an extra argument to this function to indicate whether or not it must propagate updates (no if it comes from srv_update_status).
2018-08-02 05:48:52 -04:00
* state is automatically disabled if the time is elapsed. If <must_update> is
* not zero, the update will be propagated immediately.
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
*
* Must be called with the server lock held.
BUG/MAJOR: server: weight calculation fails for map-based algorithms A crash was reported by Igor at owind when changing a server's weight on the CLI. Lukas Tribus could reproduce a related bug where setting a server's weight would result in the new weight being multiplied by the initial one. The two bugs are the same. The incorrect weight calculation results in the total farm weight being larger than what was initially allocated, causing the map index to be out of bounds on some hashes. It's easy to reproduce using "balance url_param" with a variable param, or with "balance static-rr". It appears that the calculation is made at many places and is not always right and not always wrong the same way. Thus, this patch introduces a new function "server_recalc_eweight()" which is dedicated to this task of computing ->eweight from many other elements including uweight and current time (for slowstart), and all users now switch to use this function. The patch is a bit large but the code was not trivially fixable in a way that could guarantee this situation would not occur anymore. The fix is much more readable and has been verified to work with all algorithms, with both consistent and map-based hashes, and even with static-rr. Slowstart was tested as well, just like enable/disable server. The same bug is very likely present in 1.4 as well, so the patch will probably need to be backported eventhough it will not apply as-is. Thanks to Lukas and Igor for the information they provided to reproduce it.
2013-11-21 05:22:01 -05:00
*/
MAJOR: server: make server state changes synchronous again Now we try to synchronously push updates as they come using the new rdv point, so that the call to the server update function from the main poll loop is not needed anymore. It further reduces the apparent latency in the health checks as the response time almost always appears as 0 ms, resulting in a slightly higher check rate of ~1960 conn/s. Despite this, the CPU consumption has slightly dropped again to ~32% for the same test. The only trick is that the checks code is built with a bit of recursivity because srv_update_status() calls server_recalc_eweight(), and the latter needs to signal srv_update_status() in case of updates. Thus we added an extra argument to this function to indicate whether or not it must propagate updates (no if it comes from srv_update_status).
2018-08-02 05:48:52 -04:00
void server_recalc_eweight(struct server *sv, int must_update)
BUG/MAJOR: server: weight calculation fails for map-based algorithms A crash was reported by Igor at owind when changing a server's weight on the CLI. Lukas Tribus could reproduce a related bug where setting a server's weight would result in the new weight being multiplied by the initial one. The two bugs are the same. The incorrect weight calculation results in the total farm weight being larger than what was initially allocated, causing the map index to be out of bounds on some hashes. It's easy to reproduce using "balance url_param" with a variable param, or with "balance static-rr". It appears that the calculation is made at many places and is not always right and not always wrong the same way. Thus, this patch introduces a new function "server_recalc_eweight()" which is dedicated to this task of computing ->eweight from many other elements including uweight and current time (for slowstart), and all users now switch to use this function. The patch is a bit large but the code was not trivially fixable in a way that could guarantee this situation would not occur anymore. The fix is much more readable and has been verified to work with all algorithms, with both consistent and map-based hashes, and even with static-rr. Slowstart was tested as well, just like enable/disable server. The same bug is very likely present in 1.4 as well, so the patch will probably need to be backported eventhough it will not apply as-is. Thanks to Lukas and Igor for the information they provided to reproduce it.
2013-11-21 05:22:01 -05:00
{
struct proxy *px = sv->proxy;
unsigned w;
MEDIUM: server: add and use a separate last_change variable for internal use last_change server metric is used for 2 separate purposes. First it is used to report last server state change date for stats and other related metrics. But it is also used internally, including in sensitive paths, such as lb related stuff to take decision or perform computations (ie: in srv_dynamic_maxconn()). Due to last_change counter now being split over thread groups since 16eb0fa ("MAJOR: counters: dispatch counters over thread groups"), reading the aggregated value has a cost, and we cannot afford to consult last_change value from srv_dynamic_maxconn() anymore. Moreover, since the value is used to take decision for the current process we don't wan't the variable to be updated by another process in our back. To prevent performance regression and sharing issues, let's instead add a separate srv->last_change value, which is not updated atomically (given how rare the updates are), and only serves for places where the use of the aggregated last_change counter/stats (split over thread groups) is too costly.
2025-06-30 04:57:29 -04:00
if (ns_to_sec(now_ns) < sv->last_change || ns_to_sec(now_ns) >= sv->last_change + sv->slowstart) {
BUG/MINOR: server: fix slowstart behavior We observed that a dynamic server which health check is down for longer than slowstart delay at startup doesn't trigger the warmup phase, it receives full traffic immediately. This has been confirmed by checking haproxy UI, weight is immediately the full one (e.g. 75/75), without any throttle applied. Further tests showed that it was similar if it was in maintenance, and even when entering a down or maintenance state after being up. Another issue is that if the server is down for less time than slowstart, when it comes back up, it briefly has a much higher weight than expected for a slowstart. An easy way to reproduce is to do the following: - Add a server with e.g. a 20s slowstart and a weight of 10 in config file - Put it in maintenance using CLI (set server be1/srv1 state maint) - Wait more than 20s, enable it again (set server be1/srv1 state ready) - Observe UI, weight will show 10/10 immediately. If server was down for less than 20s, you'd briefly see a weight and throttle value that is inconsistent, e.g. 50% throttle value and a weight of 5 if server comes back up after 10s before going back to 6% after a second or two. Code analysis shows that the logic in server_recalc_eweight stops the warmup task by setting server's next state to SRV_ST_RUNNING if it didn't change state for longer than the slowstart duration, regardless of its current state. As a consequence, a server being down or disabled for longer than the slowstart duration will never enter the warmup phase when it will be up again. Regarding the weight when server comes back up, issue is that even if the server is down, we still compute its next weight as if it was up, hence when it comes back up, it can briefly have a much higher weight than expected during slowstart, until the warmup task is called again after last_change is updated. This patch aims to fix both issues.
2024-04-09 11:37:07 -04:00
/* go to full throttle if the slowstart interval is reached unless server is currently down */
if ((sv->cur_state != SRV_ST_STOPPED) && (sv->next_state == SRV_ST_STARTING))
MEDIUM: check: server states and weight propagation re-work The server state and weight was reworked to handle "pending" values updated by checks/CLI/LUA/agent. These values are commited to be propagated to the LB stack. In further dev related to multi-thread, the commit will be handled into a sync point. Pending values are named using the prefix 'next_' Current values used by the LB stack are named 'cur_'
2017-08-31 08:41:55 -04:00
sv->next_state = SRV_ST_RUNNING;
BUG/MAJOR: server: weight calculation fails for map-based algorithms A crash was reported by Igor at owind when changing a server's weight on the CLI. Lukas Tribus could reproduce a related bug where setting a server's weight would result in the new weight being multiplied by the initial one. The two bugs are the same. The incorrect weight calculation results in the total farm weight being larger than what was initially allocated, causing the map index to be out of bounds on some hashes. It's easy to reproduce using "balance url_param" with a variable param, or with "balance static-rr". It appears that the calculation is made at many places and is not always right and not always wrong the same way. Thus, this patch introduces a new function "server_recalc_eweight()" which is dedicated to this task of computing ->eweight from many other elements including uweight and current time (for slowstart), and all users now switch to use this function. The patch is a bit large but the code was not trivially fixable in a way that could guarantee this situation would not occur anymore. The fix is much more readable and has been verified to work with all algorithms, with both consistent and map-based hashes, and even with static-rr. Slowstart was tested as well, just like enable/disable server. The same bug is very likely present in 1.4 as well, so the patch will probably need to be backported eventhough it will not apply as-is. Thanks to Lukas and Igor for the information they provided to reproduce it.
2013-11-21 05:22:01 -05:00
}
/* We must take care of not pushing the server to full throttle during slow starts.
* It must also start immediately, at least at the minimal step when leaving maintenance.
*/
BUG/MINOR: server: fix slowstart behavior We observed that a dynamic server which health check is down for longer than slowstart delay at startup doesn't trigger the warmup phase, it receives full traffic immediately. This has been confirmed by checking haproxy UI, weight is immediately the full one (e.g. 75/75), without any throttle applied. Further tests showed that it was similar if it was in maintenance, and even when entering a down or maintenance state after being up. Another issue is that if the server is down for less time than slowstart, when it comes back up, it briefly has a much higher weight than expected for a slowstart. An easy way to reproduce is to do the following: - Add a server with e.g. a 20s slowstart and a weight of 10 in config file - Put it in maintenance using CLI (set server be1/srv1 state maint) - Wait more than 20s, enable it again (set server be1/srv1 state ready) - Observe UI, weight will show 10/10 immediately. If server was down for less than 20s, you'd briefly see a weight and throttle value that is inconsistent, e.g. 50% throttle value and a weight of 5 if server comes back up after 10s before going back to 6% after a second or two. Code analysis shows that the logic in server_recalc_eweight stops the warmup task by setting server's next state to SRV_ST_RUNNING if it didn't change state for longer than the slowstart duration, regardless of its current state. As a consequence, a server being down or disabled for longer than the slowstart duration will never enter the warmup phase when it will be up again. Regarding the weight when server comes back up, issue is that even if the server is down, we still compute its next weight as if it was up, hence when it comes back up, it can briefly have a much higher weight than expected during slowstart, until the warmup task is called again after last_change is updated. This patch aims to fix both issues.
2024-04-09 11:37:07 -04:00
if ((sv->cur_state == SRV_ST_STOPPED) && (sv->next_state == SRV_ST_STARTING) && (px->lbprm.algo & BE_LB_PROP_DYN))
w = 1;
else if ((sv->next_state == SRV_ST_STARTING) && (px->lbprm.algo & BE_LB_PROP_DYN))
MEDIUM: server: add and use a separate last_change variable for internal use last_change server metric is used for 2 separate purposes. First it is used to report last server state change date for stats and other related metrics. But it is also used internally, including in sensitive paths, such as lb related stuff to take decision or perform computations (ie: in srv_dynamic_maxconn()). Due to last_change counter now being split over thread groups since 16eb0fa ("MAJOR: counters: dispatch counters over thread groups"), reading the aggregated value has a cost, and we cannot afford to consult last_change value from srv_dynamic_maxconn() anymore. Moreover, since the value is used to take decision for the current process we don't wan't the variable to be updated by another process in our back. To prevent performance regression and sharing issues, let's instead add a separate srv->last_change value, which is not updated atomically (given how rare the updates are), and only serves for places where the use of the aggregated last_change counter/stats (split over thread groups) is too costly.
2025-06-30 04:57:29 -04:00
w = (px->lbprm.wdiv * (ns_to_sec(now_ns) - sv->last_change) + sv->slowstart) / sv->slowstart;
BUG/MAJOR: server: weight calculation fails for map-based algorithms A crash was reported by Igor at owind when changing a server's weight on the CLI. Lukas Tribus could reproduce a related bug where setting a server's weight would result in the new weight being multiplied by the initial one. The two bugs are the same. The incorrect weight calculation results in the total farm weight being larger than what was initially allocated, causing the map index to be out of bounds on some hashes. It's easy to reproduce using "balance url_param" with a variable param, or with "balance static-rr". It appears that the calculation is made at many places and is not always right and not always wrong the same way. Thus, this patch introduces a new function "server_recalc_eweight()" which is dedicated to this task of computing ->eweight from many other elements including uweight and current time (for slowstart), and all users now switch to use this function. The patch is a bit large but the code was not trivially fixable in a way that could guarantee this situation would not occur anymore. The fix is much more readable and has been verified to work with all algorithms, with both consistent and map-based hashes, and even with static-rr. Slowstart was tested as well, just like enable/disable server. The same bug is very likely present in 1.4 as well, so the patch will probably need to be backported eventhough it will not apply as-is. Thanks to Lukas and Igor for the information they provided to reproduce it.
2013-11-21 05:22:01 -05:00
else
w = px->lbprm.wdiv;
MEDIUM: check: server states and weight propagation re-work The server state and weight was reworked to handle "pending" values updated by checks/CLI/LUA/agent. These values are commited to be propagated to the LB stack. In further dev related to multi-thread, the commit will be handled into a sync point. Pending values are named using the prefix 'next_' Current values used by the LB stack are named 'cur_'
2017-08-31 08:41:55 -04:00
sv->next_eweight = (sv->uweight * w + px->lbprm.wmult - 1) / px->lbprm.wmult;
BUG/MAJOR: server: weight calculation fails for map-based algorithms A crash was reported by Igor at owind when changing a server's weight on the CLI. Lukas Tribus could reproduce a related bug where setting a server's weight would result in the new weight being multiplied by the initial one. The two bugs are the same. The incorrect weight calculation results in the total farm weight being larger than what was initially allocated, causing the map index to be out of bounds on some hashes. It's easy to reproduce using "balance url_param" with a variable param, or with "balance static-rr". It appears that the calculation is made at many places and is not always right and not always wrong the same way. Thus, this patch introduces a new function "server_recalc_eweight()" which is dedicated to this task of computing ->eweight from many other elements including uweight and current time (for slowstart), and all users now switch to use this function. The patch is a bit large but the code was not trivially fixable in a way that could guarantee this situation would not occur anymore. The fix is much more readable and has been verified to work with all algorithms, with both consistent and map-based hashes, and even with static-rr. Slowstart was tested as well, just like enable/disable server. The same bug is very likely present in 1.4 as well, so the patch will probably need to be backported eventhough it will not apply as-is. Thanks to Lukas and Igor for the information they provided to reproduce it.
2013-11-21 05:22:01 -05:00
MAJOR: server: make server state changes synchronous again Now we try to synchronously push updates as they come using the new rdv point, so that the call to the server update function from the main poll loop is not needed anymore. It further reduces the apparent latency in the health checks as the response time almost always appears as 0 ms, resulting in a slightly higher check rate of ~1960 conn/s. Despite this, the CPU consumption has slightly dropped again to ~32% for the same test. The only trick is that the checks code is built with a bit of recursivity because srv_update_status() calls server_recalc_eweight(), and the latter needs to signal srv_update_status() in case of updates. Thus we added an extra argument to this function to indicate whether or not it must propagate updates (no if it comes from srv_update_status).
2018-08-02 05:48:52 -04:00
/* propagate changes only if needed (i.e. not recursively) */
BUG/MEDIUM: check/threads: do not involve the rendez-vous point for status updates thread_isolate() is currently being called with the server lock held. This is not acceptable because it prevents other threads from reaching the rendez-vous point. Now that the LB algos are thread-safe, let's get rid of this call. No backport is nedeed.
2018-08-21 13:54:09 -04:00
if (must_update)
MINOR: server: pass adm and op cause to srv_update_status() Operational and administrative state change causes are not propagated through srv_update_status(), instead they are directly consumed within the function to provide additional info during the call when required. Thus, there is no valid reason for keeping adm and op causes within server struct. We are wasting space and keeping uneeded complexity. We now exlicitly pass change type (operational or administrative) and associated cause to srv_update_status() so that no extra storage is needed since those values are only relevant from srv_update_status().
2023-04-18 05:00:17 -04:00
srv_update_status(sv, 0, SRV_OP_STCHGC_NONE);
BUG/MAJOR: server: weight calculation fails for map-based algorithms A crash was reported by Igor at owind when changing a server's weight on the CLI. Lukas Tribus could reproduce a related bug where setting a server's weight would result in the new weight being multiplied by the initial one. The two bugs are the same. The incorrect weight calculation results in the total farm weight being larger than what was initially allocated, causing the map index to be out of bounds on some hashes. It's easy to reproduce using "balance url_param" with a variable param, or with "balance static-rr". It appears that the calculation is made at many places and is not always right and not always wrong the same way. Thus, this patch introduces a new function "server_recalc_eweight()" which is dedicated to this task of computing ->eweight from many other elements including uweight and current time (for slowstart), and all users now switch to use this function. The patch is a bit large but the code was not trivially fixable in a way that could guarantee this situation would not occur anymore. The fix is much more readable and has been verified to work with all algorithms, with both consistent and map-based hashes, and even with static-rr. Slowstart was tested as well, just like enable/disable server. The same bug is very likely present in 1.4 as well, so the patch will probably need to be backported eventhough it will not apply as-is. Thanks to Lukas and Igor for the information they provided to reproduce it.
2013-11-21 05:22:01 -05:00
}
MEDIUM: server: allocate a tasklet for asyncronous requeuing This creates a tasklet that only expects to be called when the LB algorithm is under contention when trying to reposition the server in its tree. Indeed, that's one of the operations that usually requires to take a write lock on a highly contended area, often for very little benefits under contention; indeed, under load, if a server keeps its previous position for a few extra microseconds, usually there's no harm. Thus this new tasklet can be woken up by the LB algo to ask the server to later call lbprm.server_requeue(). It does nothing else.
2025-02-11 11:18:36 -05:00
/* requeuing tasklet used to asynchronously queue the server into its tree in
* case of extreme contention. It is woken up by the code that failed to grab
* an important lock.
*/
struct task *server_requeue(struct task *t, void *context, unsigned int state)
{
struct server *srv = context;
/* let's call the LB's requeue function. If it fails, it will itself
* wake us up.
*/
if (srv->proxy->lbprm.server_requeue)
srv->proxy->lbprm.server_requeue(srv);
return t;
}
MEDIUM: server: Break out set weight processing code Break out set weight processing code. This is in preparation for reusing the code. Also, remove duplicate check in nested if clauses. {px->lbprm.algo & BE_LB_PROP_DYN) is checked by the immediate outer if clause, so there is no need to check it a second time. Signed-off-by: Simon Horman <horms@verge.net.au>
2013-02-11 20:45:51 -05:00
/*
* Parses weight_str and configures sv accordingly.
* Returns NULL on success, error message string otherwise.
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
*
* Must be called with the server lock held.
MEDIUM: server: Break out set weight processing code Break out set weight processing code. This is in preparation for reusing the code. Also, remove duplicate check in nested if clauses. {px->lbprm.algo & BE_LB_PROP_DYN) is checked by the immediate outer if clause, so there is no need to check it a second time. Signed-off-by: Simon Horman <horms@verge.net.au>
2013-02-11 20:45:51 -05:00
*/
const char *server_parse_weight_change_request(struct server *sv,
const char *weight_str)
{
struct proxy *px;
MEDIUM: server: Tighten up parsing of weight string Detect: * Empty weight string, including no digits before '%' in relative weight string * Trailing garbage, including between the last integer and '%' in relative weights The motivation for this is to allow the weight string to be safely logged if successfully parsed by this function Signed-off-by: Simon Horman <horms@verge.net.au>
2013-02-11 20:45:53 -05:00
long int w;
char *end;
MEDIUM: server: Break out set weight processing code Break out set weight processing code. This is in preparation for reusing the code. Also, remove duplicate check in nested if clauses. {px->lbprm.algo & BE_LB_PROP_DYN) is checked by the immediate outer if clause, so there is no need to check it a second time. Signed-off-by: Simon Horman <horms@verge.net.au>
2013-02-11 20:45:51 -05:00
px = sv->proxy;
/* if the weight is terminated with '%', it is set relative to
* the initial weight, otherwise it is absolute.
*/
if (!*weight_str)
return "Require <weight> or <weight%>.\n";
MEDIUM: server: Tighten up parsing of weight string Detect: * Empty weight string, including no digits before '%' in relative weight string * Trailing garbage, including between the last integer and '%' in relative weights The motivation for this is to allow the weight string to be safely logged if successfully parsed by this function Signed-off-by: Simon Horman <horms@verge.net.au>
2013-02-11 20:45:53 -05:00
w = strtol(weight_str, &end, 10);
if (end == weight_str)
BUG/MINOR: server/cli: add missing LF at the end of certain notice/error lines Some cli_err(), cli_msg() or even ha_error() etc are missing the trailing LF, which breaks the continuity of the CLI parsing: the extra LF that serves to mark the end of the command is in fact taken as the missing LF and no extra one is added. This patch adds the missing LF on identified messages. It might be worth trying to proceed in a more generic way with this, given the amount of code that is possibly at risk.
2024-02-08 11:43:14 -05:00
return "Empty weight string empty or preceded by garbage\n";
MEDIUM: server: Tighten up parsing of weight string Detect: * Empty weight string, including no digits before '%' in relative weight string * Trailing garbage, including between the last integer and '%' in relative weights The motivation for this is to allow the weight string to be safely logged if successfully parsed by this function Signed-off-by: Simon Horman <horms@verge.net.au>
2013-02-11 20:45:53 -05:00
else if (end[0] == '%' && end[1] == '\0') {
MEDIUM: server: Allow relative weights greater than 100% Allow relative weights greater than 100%, capping the absolute value to 256 which is the largest supported absolute weight. Signed-off-by: Simon Horman <horms@verge.net.au>
2013-02-11 20:45:52 -05:00
if (w < 0)
MEDIUM: server: Break out set weight processing code Break out set weight processing code. This is in preparation for reusing the code. Also, remove duplicate check in nested if clauses. {px->lbprm.algo & BE_LB_PROP_DYN) is checked by the immediate outer if clause, so there is no need to check it a second time. Signed-off-by: Simon Horman <horms@verge.net.au>
2013-02-11 20:45:51 -05:00
return "Relative weight must be positive.\n";
MEDIUM: server: Allow relative weights greater than 100% Allow relative weights greater than 100%, capping the absolute value to 256 which is the largest supported absolute weight. Signed-off-by: Simon Horman <horms@verge.net.au>
2013-02-11 20:45:52 -05:00
/* Avoid integer overflow */
if (w > 25600)
w = 25600;
MEDIUM: server: Break out set weight processing code Break out set weight processing code. This is in preparation for reusing the code. Also, remove duplicate check in nested if clauses. {px->lbprm.algo & BE_LB_PROP_DYN) is checked by the immediate outer if clause, so there is no need to check it a second time. Signed-off-by: Simon Horman <horms@verge.net.au>
2013-02-11 20:45:51 -05:00
w = sv->iweight * w / 100;
MEDIUM: server: Allow relative weights greater than 100% Allow relative weights greater than 100%, capping the absolute value to 256 which is the largest supported absolute weight. Signed-off-by: Simon Horman <horms@verge.net.au>
2013-02-11 20:45:52 -05:00
if (w > 256)
w = 256;
MEDIUM: server: Break out set weight processing code Break out set weight processing code. This is in preparation for reusing the code. Also, remove duplicate check in nested if clauses. {px->lbprm.algo & BE_LB_PROP_DYN) is checked by the immediate outer if clause, so there is no need to check it a second time. Signed-off-by: Simon Horman <horms@verge.net.au>
2013-02-11 20:45:51 -05:00
}
else if (w < 0 || w > 256)
return "Absolute weight can only be between 0 and 256 inclusive.\n";
MEDIUM: server: Tighten up parsing of weight string Detect: * Empty weight string, including no digits before '%' in relative weight string * Trailing garbage, including between the last integer and '%' in relative weights The motivation for this is to allow the weight string to be safely logged if successfully parsed by this function Signed-off-by: Simon Horman <horms@verge.net.au>
2013-02-11 20:45:53 -05:00
else if (end[0] != '\0')
BUG/MINOR: server/cli: add missing LF at the end of certain notice/error lines Some cli_err(), cli_msg() or even ha_error() etc are missing the trailing LF, which breaks the continuity of the CLI parsing: the extra LF that serves to mark the end of the command is in fact taken as the missing LF and no extra one is added. This patch adds the missing LF on identified messages. It might be worth trying to proceed in a more generic way with this, given the amount of code that is possibly at risk.
2024-02-08 11:43:14 -05:00
return "Trailing garbage in weight string\n";
MEDIUM: server: Break out set weight processing code Break out set weight processing code. This is in preparation for reusing the code. Also, remove duplicate check in nested if clauses. {px->lbprm.algo & BE_LB_PROP_DYN) is checked by the immediate outer if clause, so there is no need to check it a second time. Signed-off-by: Simon Horman <horms@verge.net.au>
2013-02-11 20:45:51 -05:00
if (w && w != sv->iweight && !(px->lbprm.algo & BE_LB_PROP_DYN))
return "Backend is using a static LB algorithm and only accepts weights '0%' and '100%'.\n";
sv->uweight = w;
MAJOR: server: make server state changes synchronous again Now we try to synchronously push updates as they come using the new rdv point, so that the call to the server update function from the main poll loop is not needed anymore. It further reduces the apparent latency in the health checks as the response time almost always appears as 0 ms, resulting in a slightly higher check rate of ~1960 conn/s. Despite this, the CPU consumption has slightly dropped again to ~32% for the same test. The only trick is that the checks code is built with a bit of recursivity because srv_update_status() calls server_recalc_eweight(), and the latter needs to signal srv_update_status() in case of updates. Thus we added an extra argument to this function to indicate whether or not it must propagate updates (no if it comes from srv_update_status).
2018-08-02 05:48:52 -04:00
server_recalc_eweight(sv, 1);
MEDIUM: server: Break out set weight processing code Break out set weight processing code. This is in preparation for reusing the code. Also, remove duplicate check in nested if clauses. {px->lbprm.algo & BE_LB_PROP_DYN) is checked by the immediate outer if clause, so there is no need to check it a second time. Signed-off-by: Simon Horman <horms@verge.net.au>
2013-02-11 20:45:51 -05:00
return NULL;
}
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
/*
* Must be called with the server lock held.
*/
MINOR: Add ability for agent-check to set server maxconn This is very useful in complex architecture systems where HAproxy is balancing DB connections for example. We want to keep the maxconn high in order to avoid issues with queueing on the LB level when there is slowness on another part of the system. Example is a case of an architecture where each thread opens multiple DB connections, which if get stuck in queue cause a snowball effect (old connections aren't closed, new ones cannot be established). These connections are mostly idle and the DB server has no problem handling thousands of them. Allowing us to dynamically set maxconn depending on the backend usage (LA, CPU, memory, etc.) enables us to have high maxconn for situations like above, but lowering it in case there are real issues where the backend servers become overloaded (cache issues, DB gets hit hard).
2016-04-24 17:10:06 -04:00
const char *server_parse_maxconn_change_request(struct server *sv,
const char *maxconn_str)
{
long int v;
char *end;
if (!*maxconn_str)
return "Require <maxconn>.\n";
v = strtol(maxconn_str, &end, 10);
if (end == maxconn_str)
BUG/MINOR: server/cli: add missing LF at the end of certain notice/error lines Some cli_err(), cli_msg() or even ha_error() etc are missing the trailing LF, which breaks the continuity of the CLI parsing: the extra LF that serves to mark the end of the command is in fact taken as the missing LF and no extra one is added. This patch adds the missing LF on identified messages. It might be worth trying to proceed in a more generic way with this, given the amount of code that is possibly at risk.
2024-02-08 11:43:14 -05:00
return "maxconn string empty or preceded by garbage\n";
MINOR: Add ability for agent-check to set server maxconn This is very useful in complex architecture systems where HAproxy is balancing DB connections for example. We want to keep the maxconn high in order to avoid issues with queueing on the LB level when there is slowness on another part of the system. Example is a case of an architecture where each thread opens multiple DB connections, which if get stuck in queue cause a snowball effect (old connections aren't closed, new ones cannot be established). These connections are mostly idle and the DB server has no problem handling thousands of them. Allowing us to dynamically set maxconn depending on the backend usage (LA, CPU, memory, etc.) enables us to have high maxconn for situations like above, but lowering it in case there are real issues where the backend servers become overloaded (cache issues, DB gets hit hard).
2016-04-24 17:10:06 -04:00
else if (end[0] != '\0')
BUG/MINOR: server/cli: add missing LF at the end of certain notice/error lines Some cli_err(), cli_msg() or even ha_error() etc are missing the trailing LF, which breaks the continuity of the CLI parsing: the extra LF that serves to mark the end of the command is in fact taken as the missing LF and no extra one is added. This patch adds the missing LF on identified messages. It might be worth trying to proceed in a more generic way with this, given the amount of code that is possibly at risk.
2024-02-08 11:43:14 -05:00
return "Trailing garbage in maxconn string\n";
MINOR: Add ability for agent-check to set server maxconn This is very useful in complex architecture systems where HAproxy is balancing DB connections for example. We want to keep the maxconn high in order to avoid issues with queueing on the LB level when there is slowness on another part of the system. Example is a case of an architecture where each thread opens multiple DB connections, which if get stuck in queue cause a snowball effect (old connections aren't closed, new ones cannot be established). These connections are mostly idle and the DB server has no problem handling thousands of them. Allowing us to dynamically set maxconn depending on the backend usage (LA, CPU, memory, etc.) enables us to have high maxconn for situations like above, but lowering it in case there are real issues where the backend servers become overloaded (cache issues, DB gets hit hard).
2016-04-24 17:10:06 -04:00
if (sv->maxconn == sv->minconn) { // static maxconn
sv->maxconn = sv->minconn = v;
} else { // dynamic maxconn
sv->maxconn = v;
}
if (may_dequeue_tasks(sv, sv->proxy))
MEDIUM: queue: simplify again the process_srv_queue() API (v2) This basically undoes the API changes that were performed by commit 0274286dd ("BUG/MAJOR: server: fix deadlock when changing maxconn via agent-check") to address the deadlock issue: since process_srv_queue() doesn't use the server lock anymore, it doesn't need the "server_locked" argument, so let's get rid of it before it gets used again.
2021-06-22 12:47:51 -04:00
process_srv_queue(sv);
MINOR: Add ability for agent-check to set server maxconn This is very useful in complex architecture systems where HAproxy is balancing DB connections for example. We want to keep the maxconn high in order to avoid issues with queueing on the LB level when there is slowness on another part of the system. Example is a case of an architecture where each thread opens multiple DB connections, which if get stuck in queue cause a snowball effect (old connections aren't closed, new ones cannot be established). These connections are mostly idle and the DB server has no problem handling thousands of them. Allowing us to dynamically set maxconn depending on the backend usage (LA, CPU, memory, etc.) enables us to have high maxconn for situations like above, but lowering it in case there are real issues where the backend servers become overloaded (cache issues, DB gets hit hard).
2016-04-24 17:10:06 -04:00
return NULL;
}
MINOR: server: generalize sni expr parsing Two functions exists for server sni sample expression parsing. This is confusing so this commit aims at clarifying this. Functions are renamed with the following identifiers. First function is named parse_srv_expr() and can be used during parsing. Besides expression parsing, it has ensure sample fetch validity in the context of a server line. Second function is renamed _parse_srv_expr() and is used internally by parse_srv_expr(). It only implements sample parsing without extra checks. It is already use for server instantiation derived from server-template as checks were already performed. Also, it is now used in http-client code as SNI is a fixed string. Finally, both functions are generalized to remove any reference to SNI. This will allow to reuse it to parse other server keywords which use an expression. This will be the case for the future keyword pool-conn-name.
2024-05-23 04:59:20 -04:00
/* Interpret <expr> as sample expression. This function is reserved for
* internal server allocation. On parsing use parse_srv_expr() for extra sample
* check validity.
*
* Returns the allocated sample on success or NULL on error.
*/
struct sample_expr *_parse_srv_expr(char *expr, struct arg_list *args_px,
const char *file, int linenum, char **err)
MINOR: server: Make 'default-server' support 'sni' keyword. This patch makes 'default-server' directives support 'sni' settings. A field 'sni_expr' has been added to 'struct server' to temporary stores SNI expressions as strings during both 'default-server' and 'server' lines parsing. So, to duplicate SNI expressions from 'default-server' 'sni' setting for new 'server' instances we only have to "strdup" these strings as this is often done for most of the 'server' settings. Then, sample expressions are computed calling sample_parse_expr() (only for 'server' instances). A new function has been added to produce the same error output as before in case of any error during 'sni' settings parsing (display_parser_err()). Should not break anything.
2017-03-20 09:54:41 -04:00
{
int idx;
const char *args[] = {
MINOR: server: generalize sni expr parsing Two functions exists for server sni sample expression parsing. This is confusing so this commit aims at clarifying this. Functions are renamed with the following identifiers. First function is named parse_srv_expr() and can be used during parsing. Besides expression parsing, it has ensure sample fetch validity in the context of a server line. Second function is renamed _parse_srv_expr() and is used internally by parse_srv_expr(). It only implements sample parsing without extra checks. It is already use for server instantiation derived from server-template as checks were already performed. Also, it is now used in http-client code as SNI is a fixed string. Finally, both functions are generalized to remove any reference to SNI. This will allow to reuse it to parse other server keywords which use an expression. This will be the case for the future keyword pool-conn-name.
2024-05-23 04:59:20 -04:00
expr,
MINOR: server: Make 'default-server' support 'sni' keyword. This patch makes 'default-server' directives support 'sni' settings. A field 'sni_expr' has been added to 'struct server' to temporary stores SNI expressions as strings during both 'default-server' and 'server' lines parsing. So, to duplicate SNI expressions from 'default-server' 'sni' setting for new 'server' instances we only have to "strdup" these strings as this is often done for most of the 'server' settings. Then, sample expressions are computed calling sample_parse_expr() (only for 'server' instances). A new function has been added to produce the same error output as before in case of any error during 'sni' settings parsing (display_parser_err()). Should not break anything.
2017-03-20 09:54:41 -04:00
NULL,
};
idx = 0;
MINOR: server: generalize sni expr parsing Two functions exists for server sni sample expression parsing. This is confusing so this commit aims at clarifying this. Functions are renamed with the following identifiers. First function is named parse_srv_expr() and can be used during parsing. Besides expression parsing, it has ensure sample fetch validity in the context of a server line. Second function is renamed _parse_srv_expr() and is used internally by parse_srv_expr(). It only implements sample parsing without extra checks. It is already use for server instantiation derived from server-template as checks were already performed. Also, it is now used in http-client code as SNI is a fixed string. Finally, both functions are generalized to remove any reference to SNI. This will allow to reuse it to parse other server keywords which use an expression. This will be the case for the future keyword pool-conn-name.
2024-05-23 04:59:20 -04:00
args_px->ctx = ARGC_SRV;
MINOR: server: Make 'default-server' support 'sni' keyword. This patch makes 'default-server' directives support 'sni' settings. A field 'sni_expr' has been added to 'struct server' to temporary stores SNI expressions as strings during both 'default-server' and 'server' lines parsing. So, to duplicate SNI expressions from 'default-server' 'sni' setting for new 'server' instances we only have to "strdup" these strings as this is often done for most of the 'server' settings. Then, sample expressions are computed calling sample_parse_expr() (only for 'server' instances). A new function has been added to produce the same error output as before in case of any error during 'sni' settings parsing (display_parser_err()). Should not break anything.
2017-03-20 09:54:41 -04:00
MINOR: server: generalize sni expr parsing Two functions exists for server sni sample expression parsing. This is confusing so this commit aims at clarifying this. Functions are renamed with the following identifiers. First function is named parse_srv_expr() and can be used during parsing. Besides expression parsing, it has ensure sample fetch validity in the context of a server line. Second function is renamed _parse_srv_expr() and is used internally by parse_srv_expr(). It only implements sample parsing without extra checks. It is already use for server instantiation derived from server-template as checks were already performed. Also, it is now used in http-client code as SNI is a fixed string. Finally, both functions are generalized to remove any reference to SNI. This will allow to reuse it to parse other server keywords which use an expression. This will be the case for the future keyword pool-conn-name.
2024-05-23 04:59:20 -04:00
return sample_parse_expr((char **)args, &idx, file, linenum, err, args_px, NULL);
MINOR: server: Extract the code which finalizes server initializations after 'server' lines parsing. This patch moves the code which is responsible of finalizing server initializations after having fully parsed a 'server' line (health-check, agent check and SNI expression initializations) from parse_server() to new functions.
2017-03-30 11:32:36 -04:00
}
MINOR: server: generalize sni expr parsing Two functions exists for server sni sample expression parsing. This is confusing so this commit aims at clarifying this. Functions are renamed with the following identifiers. First function is named parse_srv_expr() and can be used during parsing. Besides expression parsing, it has ensure sample fetch validity in the context of a server line. Second function is renamed _parse_srv_expr() and is used internally by parse_srv_expr(). It only implements sample parsing without extra checks. It is already use for server instantiation derived from server-template as checks were already performed. Also, it is now used in http-client code as SNI is a fixed string. Finally, both functions are generalized to remove any reference to SNI. This will allow to reuse it to parse other server keywords which use an expression. This will be the case for the future keyword pool-conn-name.
2024-05-23 04:59:20 -04:00
/* Interpret <str> if not empty as a sample expression and store it into <out>.
* Contrary to _parse_srv_expr(), fetch scope validity is checked to ensure it
* is valid on a server line context. It also updates <px> HTTP mode
* requirement depending on fetch method used.
*
* Returns 0 on success else non zero.
*/
static int parse_srv_expr(char *str, struct sample_expr **out, struct proxy *px,
char **err)
MINOR: server: Extract the code which finalizes server initializations after 'server' lines parsing. This patch moves the code which is responsible of finalizing server initializations after having fully parsed a 'server' line (health-check, agent check and SNI expression initializations) from parse_server() to new functions.
2017-03-30 11:32:36 -04:00
{
struct sample_expr *expr;
MINOR: server: generalize sni expr parsing Two functions exists for server sni sample expression parsing. This is confusing so this commit aims at clarifying this. Functions are renamed with the following identifiers. First function is named parse_srv_expr() and can be used during parsing. Besides expression parsing, it has ensure sample fetch validity in the context of a server line. Second function is renamed _parse_srv_expr() and is used internally by parse_srv_expr(). It only implements sample parsing without extra checks. It is already use for server instantiation derived from server-template as checks were already performed. Also, it is now used in http-client code as SNI is a fixed string. Finally, both functions are generalized to remove any reference to SNI. This will allow to reuse it to parse other server keywords which use an expression. This will be the case for the future keyword pool-conn-name.
2024-05-23 04:59:20 -04:00
if (!str)
return 0;
expr = _parse_srv_expr(str, &px->conf.args, px->conf.file, px->conf.line, err);
if (!expr)
MINOR: server: Make 'default-server' support 'sni' keyword. This patch makes 'default-server' directives support 'sni' settings. A field 'sni_expr' has been added to 'struct server' to temporary stores SNI expressions as strings during both 'default-server' and 'server' lines parsing. So, to duplicate SNI expressions from 'default-server' 'sni' setting for new 'server' instances we only have to "strdup" these strings as this is often done for most of the 'server' settings. Then, sample expressions are computed calling sample_parse_expr() (only for 'server' instances). A new function has been added to produce the same error output as before in case of any error during 'sni' settings parsing (display_parser_err()). Should not break anything.
2017-03-20 09:54:41 -04:00
return ERR_ALERT | ERR_FATAL;
if (!(expr->fetch->val & SMP_VAL_BE_SRV_CON)) {
MINOR: server: generalize sni expr parsing Two functions exists for server sni sample expression parsing. This is confusing so this commit aims at clarifying this. Functions are renamed with the following identifiers. First function is named parse_srv_expr() and can be used during parsing. Besides expression parsing, it has ensure sample fetch validity in the context of a server line. Second function is renamed _parse_srv_expr() and is used internally by parse_srv_expr(). It only implements sample parsing without extra checks. It is already use for server instantiation derived from server-template as checks were already performed. Also, it is now used in http-client code as SNI is a fixed string. Finally, both functions are generalized to remove any reference to SNI. This will allow to reuse it to parse other server keywords which use an expression. This will be the case for the future keyword pool-conn-name.
2024-05-23 04:59:20 -04:00
memprintf(err, "fetch method '%s' extracts information from '%s', "
CLEANUP: server: fix cosmetic of error message on sni parsing Fix memprintf used in server_parse_sni_expr. Error messages should not be ending with a newline as it will be inserted in the parent function on the ha_alert invocation.
2021-05-28 05:01:22 -04:00
"none of which is available here.",
MINOR: server: generalize sni expr parsing Two functions exists for server sni sample expression parsing. This is confusing so this commit aims at clarifying this. Functions are renamed with the following identifiers. First function is named parse_srv_expr() and can be used during parsing. Besides expression parsing, it has ensure sample fetch validity in the context of a server line. Second function is renamed _parse_srv_expr() and is used internally by parse_srv_expr(). It only implements sample parsing without extra checks. It is already use for server instantiation derived from server-template as checks were already performed. Also, it is now used in http-client code as SNI is a fixed string. Finally, both functions are generalized to remove any reference to SNI. This will allow to reuse it to parse other server keywords which use an expression. This will be the case for the future keyword pool-conn-name.
2024-05-23 04:59:20 -04:00
str, sample_src_names(expr->fetch->use));
MINOR: server: Make 'default-server' support 'sni' keyword. This patch makes 'default-server' directives support 'sni' settings. A field 'sni_expr' has been added to 'struct server' to temporary stores SNI expressions as strings during both 'default-server' and 'server' lines parsing. So, to duplicate SNI expressions from 'default-server' 'sni' setting for new 'server' instances we only have to "strdup" these strings as this is often done for most of the 'server' settings. Then, sample expressions are computed calling sample_parse_expr() (only for 'server' instances). A new function has been added to produce the same error output as before in case of any error during 'sni' settings parsing (display_parser_err()). Should not break anything.
2017-03-20 09:54:41 -04:00
return ERR_ALERT | ERR_FATAL;
}
px->http_needed |= !!(expr->fetch->use & SMP_USE_HTTP_ANY);
MINOR: server: generalize sni expr parsing Two functions exists for server sni sample expression parsing. This is confusing so this commit aims at clarifying this. Functions are renamed with the following identifiers. First function is named parse_srv_expr() and can be used during parsing. Besides expression parsing, it has ensure sample fetch validity in the context of a server line. Second function is renamed _parse_srv_expr() and is used internally by parse_srv_expr(). It only implements sample parsing without extra checks. It is already use for server instantiation derived from server-template as checks were already performed. Also, it is now used in http-client code as SNI is a fixed string. Finally, both functions are generalized to remove any reference to SNI. This will allow to reuse it to parse other server keywords which use an expression. This will be the case for the future keyword pool-conn-name.
2024-05-23 04:59:20 -04:00
release_sample_expr(*out);
*out = expr;
MINOR: server: Make 'default-server' support 'sni' keyword. This patch makes 'default-server' directives support 'sni' settings. A field 'sni_expr' has been added to 'struct server' to temporary stores SNI expressions as strings during both 'default-server' and 'server' lines parsing. So, to duplicate SNI expressions from 'default-server' 'sni' setting for new 'server' instances we only have to "strdup" these strings as this is often done for most of the 'server' settings. Then, sample expressions are computed calling sample_parse_expr() (only for 'server' instances). A new function has been added to produce the same error output as before in case of any error during 'sni' settings parsing (display_parser_err()). Should not break anything.
2017-03-20 09:54:41 -04:00
return 0;
}
MINOR: server: respect warning and alert semantic Error codes ERR_WARN and ERR_ALERT are used to signal that the error given is of the corresponding level. All errors are displayed as ALERT in the display_parser_err() function. Differentiate the display level based on the error code. If both ERR_WARN and ERR_ALERT are used, ERR_ALERT is given priority.
2020-02-11 05:42:38 -05:00
static void display_parser_err(const char *file, int linenum, char **args, int cur_arg, int err_code, char **err)
MINOR: server: Make 'default-server' support 'sni' keyword. This patch makes 'default-server' directives support 'sni' settings. A field 'sni_expr' has been added to 'struct server' to temporary stores SNI expressions as strings during both 'default-server' and 'server' lines parsing. So, to duplicate SNI expressions from 'default-server' 'sni' setting for new 'server' instances we only have to "strdup" these strings as this is often done for most of the 'server' settings. Then, sample expressions are computed calling sample_parse_expr() (only for 'server' instances). A new function has been added to produce the same error output as before in case of any error during 'sni' settings parsing (display_parser_err()). Should not break anything.
2017-03-20 09:54:41 -04:00
{
MINOR: server: respect warning and alert semantic Error codes ERR_WARN and ERR_ALERT are used to signal that the error given is of the corresponding level. All errors are displayed as ALERT in the display_parser_err() function. Differentiate the display level based on the error code. If both ERR_WARN and ERR_ALERT are used, ERR_ALERT is given priority.
2020-02-11 05:42:38 -05:00
char *msg = "error encountered while processing ";
char *quote = "'";
char *token = args[cur_arg];
MINOR: server: Make 'default-server' support 'sni' keyword. This patch makes 'default-server' directives support 'sni' settings. A field 'sni_expr' has been added to 'struct server' to temporary stores SNI expressions as strings during both 'default-server' and 'server' lines parsing. So, to duplicate SNI expressions from 'default-server' 'sni' setting for new 'server' instances we only have to "strdup" these strings as this is often done for most of the 'server' settings. Then, sample expressions are computed calling sample_parse_expr() (only for 'server' instances). A new function has been added to produce the same error output as before in case of any error during 'sni' settings parsing (display_parser_err()). Should not break anything.
2017-03-20 09:54:41 -04:00
if (err && *err) {
indent_msg(err, 2);
MINOR: server: respect warning and alert semantic Error codes ERR_WARN and ERR_ALERT are used to signal that the error given is of the corresponding level. All errors are displayed as ALERT in the display_parser_err() function. Differentiate the display level based on the error code. If both ERR_WARN and ERR_ALERT are used, ERR_ALERT is given priority.
2020-02-11 05:42:38 -05:00
msg = *err;
quote = "";
token = "";
MINOR: server: Make 'default-server' support 'sni' keyword. This patch makes 'default-server' directives support 'sni' settings. A field 'sni_expr' has been added to 'struct server' to temporary stores SNI expressions as strings during both 'default-server' and 'server' lines parsing. So, to duplicate SNI expressions from 'default-server' 'sni' setting for new 'server' instances we only have to "strdup" these strings as this is often done for most of the 'server' settings. Then, sample expressions are computed calling sample_parse_expr() (only for 'server' instances). A new function has been added to produce the same error output as before in case of any error during 'sni' settings parsing (display_parser_err()). Should not break anything.
2017-03-20 09:54:41 -04:00
}
MINOR: server: respect warning and alert semantic Error codes ERR_WARN and ERR_ALERT are used to signal that the error given is of the corresponding level. All errors are displayed as ALERT in the display_parser_err() function. Differentiate the display level based on the error code. If both ERR_WARN and ERR_ALERT are used, ERR_ALERT is given priority.
2020-02-11 05:42:38 -05:00
if (err_code & ERR_WARN && !(err_code & ERR_ALERT))
REORG: server: use parsing ctx for server parsing Use the parsing context in parse_server. Remove redundant manual format-string specifying the current file/line/server parsed.
2021-05-28 05:00:18 -04:00
ha_warning("%s%s%s%s.\n", msg, quote, token, quote);
MINOR: server: Make 'default-server' support 'sni' keyword. This patch makes 'default-server' directives support 'sni' settings. A field 'sni_expr' has been added to 'struct server' to temporary stores SNI expressions as strings during both 'default-server' and 'server' lines parsing. So, to duplicate SNI expressions from 'default-server' 'sni' setting for new 'server' instances we only have to "strdup" these strings as this is often done for most of the 'server' settings. Then, sample expressions are computed calling sample_parse_expr() (only for 'server' instances). A new function has been added to produce the same error output as before in case of any error during 'sni' settings parsing (display_parser_err()). Should not break anything.
2017-03-20 09:54:41 -04:00
else
REORG: server: use parsing ctx for server parsing Use the parsing context in parse_server. Remove redundant manual format-string specifying the current file/line/server parsed.
2021-05-28 05:00:18 -04:00
ha_alert("%s%s%s%s.\n", msg, quote, token, quote);
MINOR: server: Make 'default-server' support 'sni' keyword. This patch makes 'default-server' directives support 'sni' settings. A field 'sni_expr' has been added to 'struct server' to temporary stores SNI expressions as strings during both 'default-server' and 'server' lines parsing. So, to duplicate SNI expressions from 'default-server' 'sni' setting for new 'server' instances we only have to "strdup" these strings as this is often done for most of the 'server' settings. Then, sample expressions are computed calling sample_parse_expr() (only for 'server' instances). A new function has been added to produce the same error output as before in case of any error during 'sni' settings parsing (display_parser_err()). Should not break anything.
2017-03-20 09:54:41 -04:00
}
MINOR: server: Constify source server to copy its settings The source server used to initialize a new server, in srv_settings_cpy() and sub-functions, is now a constant. This patch is mandatory to fix a bug.
2022-08-03 05:21:14 -04:00
static void srv_conn_src_sport_range_cpy(struct server *srv, const struct server *src)
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
{
int range_sz;
range_sz = src->conn_src.sport_range->size;
if (range_sz > 0) {
srv->conn_src.sport_range = port_range_alloc_range(range_sz);
if (srv->conn_src.sport_range != NULL) {
int i;
for (i = 0; i < range_sz; i++) {
srv->conn_src.sport_range->ports[i] =
src->conn_src.sport_range->ports[i];
}
}
}
}
/*
* Copy <src> server connection source settings to <srv> server everything needed.
*/
MINOR: server: Constify source server to copy its settings The source server used to initialize a new server, in srv_settings_cpy() and sub-functions, is now a constant. This patch is mandatory to fix a bug.
2022-08-03 05:21:14 -04:00
static void srv_conn_src_cpy(struct server *srv, const struct server *src)
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
{
srv->conn_src.opts = src->conn_src.opts;
srv->conn_src.source_addr = src->conn_src.source_addr;
/* Source port range copy. */
if (src->conn_src.sport_range != NULL)
srv_conn_src_sport_range_cpy(srv, src);
#ifdef CONFIG_HAP_TRANSPARENT
if (src->conn_src.bind_hdr_name != NULL) {
srv->conn_src.bind_hdr_name = strdup(src->conn_src.bind_hdr_name);
srv->conn_src.bind_hdr_len = strlen(src->conn_src.bind_hdr_name);
}
srv->conn_src.bind_hdr_occ = src->conn_src.bind_hdr_occ;
srv->conn_src.tproxy_addr = src->conn_src.tproxy_addr;
#endif
BUG/MINOR: server: 'source' interface ignored from 'default-server' directive Sebastien Gross reported that 'interface' keyword ('source' subargument) is silently ignored when used from 'default-server' directive despite the documentation implicitly stating that the keyword should be supported there. When support for 'source' keyword was added to 'default-server' directive in dba97077 ("MINOR: server: Make 'default-server' support 'source' keyword."), we properly duplicated the conn iface_name from the default- server but we forgot to copy the conn iface_len which must be set as well since it is used as setsockopt()'s 'optlen' argument in tcp_connect_server(). It should be backported to all stable versions.
2024-03-26 05:42:48 -04:00
if (src->conn_src.iface_name != NULL) {
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
srv->conn_src.iface_name = strdup(src->conn_src.iface_name);
BUG/MINOR: server: 'source' interface ignored from 'default-server' directive Sebastien Gross reported that 'interface' keyword ('source' subargument) is silently ignored when used from 'default-server' directive despite the documentation implicitly stating that the keyword should be supported there. When support for 'source' keyword was added to 'default-server' directive in dba97077 ("MINOR: server: Make 'default-server' support 'source' keyword."), we properly duplicated the conn iface_name from the default- server but we forgot to copy the conn iface_len which must be set as well since it is used as setsockopt()'s 'optlen' argument in tcp_connect_server(). It should be backported to all stable versions.
2024-03-26 05:42:48 -04:00
srv->conn_src.iface_len = src->conn_src.iface_len;
}
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
}
/*
* Copy <src> server SSL settings to <srv> server allocating
* everything needed.
*/
#if defined(USE_OPENSSL)
MINOR: server: Constify source server to copy its settings The source server used to initialize a new server, in srv_settings_cpy() and sub-functions, is now a constant. This patch is mandatory to fix a bug.
2022-08-03 05:21:14 -04:00
static void srv_ssl_settings_cpy(struct server *srv, const struct server *src)
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
{
BUG/MINOR: server: Don't rely on last default-server to init server SSL context During post-parsing stage, the SSL context of a server is initialized if SSL is configured on the server or its default-server. It is required to be able to enable SSL at runtime. However a regression was introduced, because the last parsed default-server is used. But it is not necessarily the default-server line used to configure the server. This may lead to erroneously initialize the SSL context for a server without SSL parameter or the skip it while it should be done. The problem is the default-server used to configure a server is not saved during configuration parsing. So, the information is lost during the post-parsing. To fix the bug, the SRV_F_DEFSRV_USE_SSL flag is introduced. It is used to know when a server was initialized with a default-server using SSL. For the record, the commit f63704488e ("MEDIUM: cli/ssl: configure ssl on server at runtime") has introduced the bug. This patch must be backported as far as 2.4.
2021-12-01 03:50:41 -05:00
/* <src> is the current proxy's default server and SSL is enabled */
BUG/MEDIUM: ssl: initialize correctly ssl w/ default-server This bug was introduced by d817dc73 ("MEDIUM: ssl: Load client certificates in a ckch for backend servers") in which the creation of the SSL_CTX for a server was moved to the configuration parser when using a "crt" keyword instead of being done in ssl_sock_prepare_srv_ctx(). The patch 0498fa40 ("BUG/MINOR: ssl: Default-server configuration ignored by server") made it worse by setting the same SSL_CTX for every servers using a default-server. Resulting in any SSL option on a server applied to every server in its backend. This patch fixes the issue by reintroducing a string which store the path of certificate inside the server structure, and loading the certificate in ssl_sock_prepare_srv_ctx() again. This is a quick fix to backport, a cleaner way can be achieve by always creating the SSL_CTX in ssl_sock_prepare_srv_ctx() and splitting properly the ssl_sock_load_srv_cert() function. This patch fixes issue #1488. Must be backported as far as 2.4.
2021-12-28 12:47:17 -05:00
BUG_ON(src->ssl_ctx.ctx != NULL); /* the SSL_CTX must never be initialized in a default-server */
MEDIUM: proxy: take the defsrv out of the struct proxy The server struct has gone huge over time (~3.8kB), and having a copy of it in the defsrv section of the struct proxy costs a lot of RAM, that is not needed anymore at run time. This patch replaces this struct with a dynamically allocated one. The field is allocated and initialized during alloc_new_proxy() and is freed when the proxy is destroyed for now. But the goal will be to support freeing it after parsing the section.
2025-07-10 10:16:24 -04:00
if (srv->proxy && src == srv->proxy->defsrv && src->use_ssl == 1)
BUG/MINOR: server: Don't rely on last default-server to init server SSL context During post-parsing stage, the SSL context of a server is initialized if SSL is configured on the server or its default-server. It is required to be able to enable SSL at runtime. However a regression was introduced, because the last parsed default-server is used. But it is not necessarily the default-server line used to configure the server. This may lead to erroneously initialize the SSL context for a server without SSL parameter or the skip it while it should be done. The problem is the default-server used to configure a server is not saved during configuration parsing. So, the information is lost during the post-parsing. To fix the bug, the SRV_F_DEFSRV_USE_SSL flag is introduced. It is used to know when a server was initialized with a default-server using SSL. For the record, the commit f63704488e ("MEDIUM: cli/ssl: configure ssl on server at runtime") has introduced the bug. This patch must be backported as far as 2.4.
2021-12-01 03:50:41 -05:00
srv->flags |= SRV_F_DEFSRV_USE_SSL;
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
if (src->ssl_ctx.ca_file != NULL)
srv->ssl_ctx.ca_file = strdup(src->ssl_ctx.ca_file);
if (src->ssl_ctx.crl_file != NULL)
srv->ssl_ctx.crl_file = strdup(src->ssl_ctx.crl_file);
BUG/MEDIUM: ssl: initialize correctly ssl w/ default-server This bug was introduced by d817dc73 ("MEDIUM: ssl: Load client certificates in a ckch for backend servers") in which the creation of the SSL_CTX for a server was moved to the configuration parser when using a "crt" keyword instead of being done in ssl_sock_prepare_srv_ctx(). The patch 0498fa40 ("BUG/MINOR: ssl: Default-server configuration ignored by server") made it worse by setting the same SSL_CTX for every servers using a default-server. Resulting in any SSL option on a server applied to every server in its backend. This patch fixes the issue by reintroducing a string which store the path of certificate inside the server structure, and loading the certificate in ssl_sock_prepare_srv_ctx() again. This is a quick fix to backport, a cleaner way can be achieve by always creating the SSL_CTX in ssl_sock_prepare_srv_ctx() and splitting properly the ssl_sock_load_srv_cert() function. This patch fixes issue #1488. Must be backported as far as 2.4.
2021-12-28 12:47:17 -05:00
if (src->ssl_ctx.client_crt != NULL)
srv->ssl_ctx.client_crt = strdup(src->ssl_ctx.client_crt);
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
srv->ssl_ctx.verify = src->ssl_ctx.verify;
MINOR: ssl: Add "renegotiate" server option This "renegotiate" option can be set on SSL backends to allow secure renegotiation. It is mostly useful with SSL libraries that disable secure regotiation by default (such as AWS-LC). The "no-renegotiate" one can be used the other way around, to disable secure renegotation that could be allowed by default. Those two options can be set via "ssl-default-server-options" as well.
2025-06-12 09:08:28 -04:00
srv->ssl_ctx.renegotiate = src->ssl_ctx.renegotiate;
BUG/MINOR: ssl: Default-server configuration ignored by server When a default-server line specified a client certificate to use, the frontend would not take it into account and create an empty SSL context, which would raise an error on the backend side ("peer did not return a certificate"). This bug was introduced by d817dc733eacfd7cf5bb0bbc6128f44644db078e in which the SSL contexts are created earlier than before (during the default-server line parsing) without setting it in the corresponding server structures. It then made the server create an empty SSL context in ssl_sock_prepare_srv_ctx because it thought it needed one. It was raised on redmine, in Bug #3906. It can be backported to 2.4.
2021-07-13 12:28:22 -04:00
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
if (src->ssl_ctx.verify_host != NULL)
srv->ssl_ctx.verify_host = strdup(src->ssl_ctx.verify_host);
if (src->ssl_ctx.ciphers != NULL)
srv->ssl_ctx.ciphers = strdup(src->ssl_ctx.ciphers);
BUG/MINOR: ssl: default settings for ssl server options are not used Documentation states that default settings for ssl server options can be set using either ssl-default-server-options or default-server directives. In practice, not all ssl server options can have default values, such as ssl-min-ver, ssl-max-ver, etc.. This patch adds the missing ssl options in srv_ssl_settings_cpy() and srv_parse_ssl(), making it possible to write configurations like the following examples, and have them behave as expected. global ssl-default-server-options ssl-max-ver TLSv1.2 defaults mode http listen l1 bind 1.2.3.4:80 default-server ssl verify none server s1 1.2.3.5:443 listen l2 bind 2.2.3.4:80 default-server ssl verify none ssl-max-ver TLSv1.3 ssl-min-ver TLSv1.2 server s1 1.2.3.6:443 This should be backported as far as 1.8. This fixes issue #595.
2020-04-22 05:40:18 -04:00
if (src->ssl_ctx.options)
srv->ssl_ctx.options = src->ssl_ctx.options;
if (src->ssl_ctx.methods.flags)
srv->ssl_ctx.methods.flags = src->ssl_ctx.methods.flags;
if (src->ssl_ctx.methods.min)
srv->ssl_ctx.methods.min = src->ssl_ctx.methods.min;
if (src->ssl_ctx.methods.max)
srv->ssl_ctx.methods.max = src->ssl_ctx.methods.max;
MEDIUM: ssl: add support for ciphersuites option for TLSv1.3 OpenSSL released support for TLSv1.3. It also added a separate function SSL_CTX_set_ciphersuites that is used to set the ciphers used in the TLS 1.3 handshake. This change adds support for that new configuration option by adding a ciphersuites configuration variable that works essentially the same as the existing ciphers setting. Note that it should likely be backported to 1.8 in order to ease usage of the now released openssl-1.1.1.
2018-09-14 05:14:21 -04:00
if (src->ssl_ctx.ciphersuites != NULL)
srv->ssl_ctx.ciphersuites = strdup(src->ssl_ctx.ciphersuites);
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
if (src->sni_expr != NULL)
srv->sni_expr = strdup(src->sni_expr);
MINOR: server: Add "alpn" and "npn" keywords. Add new keywords to "server" lines, alpn and npn. If set, when connecting through SSL, those alpn/npn will be negociated during the SSL handshake.
2018-11-20 17:33:50 -05:00
if (src->ssl_ctx.alpn_str) {
srv->ssl_ctx.alpn_str = malloc(src->ssl_ctx.alpn_len);
if (srv->ssl_ctx.alpn_str) {
memcpy(srv->ssl_ctx.alpn_str, src->ssl_ctx.alpn_str,
src->ssl_ctx.alpn_len);
srv->ssl_ctx.alpn_len = src->ssl_ctx.alpn_len;
}
}
CLEANUP: server: always include the storage for SSL settings The SSL stuff in struct server takes less than 3% of it and requires lots of annoying ifdefs in the code just to take care of the cases where the field is absent. Let's get rid of this and stop including openssl-compat from server.c to detect NPN and ALPN capabilities. This reduces the total LoC by another 0.4%.
2021-10-06 08:48:37 -04:00
MINOR: server: Add "alpn" and "npn" keywords. Add new keywords to "server" lines, alpn and npn. If set, when connecting through SSL, those alpn/npn will be negociated during the SSL handshake.
2018-11-20 17:33:50 -05:00
if (src->ssl_ctx.npn_str) {
srv->ssl_ctx.npn_str = malloc(src->ssl_ctx.npn_len);
if (srv->ssl_ctx.npn_str) {
memcpy(srv->ssl_ctx.npn_str, src->ssl_ctx.npn_str,
src->ssl_ctx.npn_len);
srv->ssl_ctx.npn_len = src->ssl_ctx.npn_len;
}
}
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
}
CLEANUP: ssl/server: move ssl_sock_set_srv() to srv_set_ssl() in server.c This one has nothing to do with ssl_sock as it manipulates the struct server only. Let's move it to server.c and remove unneeded dependencies on ssl_sock.h. This further reduces by 10% the number of includes of opensslconf.h and by 0.5% the number of compiled lines.
2021-10-06 05:48:34 -04:00
/* Activate ssl on server <s>.
* do nothing if there is no change to apply
*
* Must be called with the server lock held.
*/
BUG/MEDIUM: server: Use sni as pool connection name for SSL server only By default, for a given server, when no pool-conn-name is specified, the configured sni is used. However, this must only be done when SSL is in-use for the server. Of course, it is uncommon to have a sni expression for now-ssl server. But this may happen. In addition, the SSL may be disabled via the CLI. In that case, the pool-conn-name must be discarded if it was copied from the sni. And, we must of course take care to set it if the ssl is enabled. Finally, when the attac-srv action is checked, we now checked the pool-conn-name expression. This patch should be backported as far as 3.0. It relies on "MINOR: server: Parse sni and pool-conn-name expressions in a dedicated function" which should be backported too.
2025-09-03 09:29:56 -04:00
int srv_set_ssl(struct server *s, int use_ssl)
CLEANUP: ssl/server: move ssl_sock_set_srv() to srv_set_ssl() in server.c This one has nothing to do with ssl_sock as it manipulates the struct server only. Let's move it to server.c and remove unneeded dependencies on ssl_sock.h. This further reduces by 10% the number of includes of opensslconf.h and by 0.5% the number of compiled lines.
2021-10-06 05:48:34 -04:00
{
if (s->use_ssl == use_ssl)
BUG/MEDIUM: server: Use sni as pool connection name for SSL server only By default, for a given server, when no pool-conn-name is specified, the configured sni is used. However, this must only be done when SSL is in-use for the server. Of course, it is uncommon to have a sni expression for now-ssl server. But this may happen. In addition, the SSL may be disabled via the CLI. In that case, the pool-conn-name must be discarded if it was copied from the sni. And, we must of course take care to set it if the ssl is enabled. Finally, when the attac-srv action is checked, we now checked the pool-conn-name expression. This patch should be backported as far as 3.0. It relies on "MINOR: server: Parse sni and pool-conn-name expressions in a dedicated function" which should be backported too.
2025-09-03 09:29:56 -04:00
return 0;
CLEANUP: ssl/server: move ssl_sock_set_srv() to srv_set_ssl() in server.c This one has nothing to do with ssl_sock as it manipulates the struct server only. Let's move it to server.c and remove unneeded dependencies on ssl_sock.h. This further reduces by 10% the number of includes of opensslconf.h and by 0.5% the number of compiled lines.
2021-10-06 05:48:34 -04:00
s->use_ssl = use_ssl;
BUG/MEDIUM: server: Use sni as pool connection name for SSL server only By default, for a given server, when no pool-conn-name is specified, the configured sni is used. However, this must only be done when SSL is in-use for the server. Of course, it is uncommon to have a sni expression for now-ssl server. But this may happen. In addition, the SSL may be disabled via the CLI. In that case, the pool-conn-name must be discarded if it was copied from the sni. And, we must of course take care to set it if the ssl is enabled. Finally, when the attac-srv action is checked, we now checked the pool-conn-name expression. This patch should be backported as far as 3.0. It relies on "MINOR: server: Parse sni and pool-conn-name expressions in a dedicated function" which should be backported too.
2025-09-03 09:29:56 -04:00
if (s->use_ssl) {
MEDIUM: server/ssl: Base the SNI value to the HTTP host header by default For HTTPS outgoing connections, the SNI is now automatically set using the Host header value if no other value is already set (via the "sni" server keyword). It is now the default behavior. It could be disabled with the "no-sni-auto" server keyword. And eventually "sni-auto" server keyword may be used to reset any previous "no-sni-auto" setting. This option can be inherited from "default-server" settings. Finally, if no connection name is set via "pool-conn-name" setting, the selected value is used. The automatic selection of the SNI is enabled by default for all outgoing connections. But it is concretely used for HTTPS connections only. The expression used is "req.hdr(host),host_only". This patch should paritally fix the issue #3081. It only covers the server part. Another patch will add the feature for HTTP health-checks.
2025-09-04 04:12:19 -04:00
if (server_parse_exprs(s, s->proxy, NULL))
BUG/MEDIUM: server: Use sni as pool connection name for SSL server only By default, for a given server, when no pool-conn-name is specified, the configured sni is used. However, this must only be done when SSL is in-use for the server. Of course, it is uncommon to have a sni expression for now-ssl server. But this may happen. In addition, the SSL may be disabled via the CLI. In that case, the pool-conn-name must be discarded if it was copied from the sni. And, we must of course take care to set it if the ssl is enabled. Finally, when the attac-srv action is checked, we now checked the pool-conn-name expression. This patch should be backported as far as 3.0. It relies on "MINOR: server: Parse sni and pool-conn-name expressions in a dedicated function" which should be backported too.
2025-09-03 09:29:56 -04:00
return -1;
CLEANUP: ssl/server: move ssl_sock_set_srv() to srv_set_ssl() in server.c This one has nothing to do with ssl_sock as it manipulates the struct server only. Let's move it to server.c and remove unneeded dependencies on ssl_sock.h. This further reduces by 10% the number of includes of opensslconf.h and by 0.5% the number of compiled lines.
2021-10-06 05:48:34 -04:00
s->xprt = xprt_get(XPRT_SSL);
BUG/MEDIUM: server: Use sni as pool connection name for SSL server only By default, for a given server, when no pool-conn-name is specified, the configured sni is used. However, this must only be done when SSL is in-use for the server. Of course, it is uncommon to have a sni expression for now-ssl server. But this may happen. In addition, the SSL may be disabled via the CLI. In that case, the pool-conn-name must be discarded if it was copied from the sni. And, we must of course take care to set it if the ssl is enabled. Finally, when the attac-srv action is checked, we now checked the pool-conn-name expression. This patch should be backported as far as 3.0. It relies on "MINOR: server: Parse sni and pool-conn-name expressions in a dedicated function" which should be backported too.
2025-09-03 09:29:56 -04:00
}
else {
if (s->sni_expr && s->pool_conn_name && strcmp(s->sni_expr, s->pool_conn_name) == 0) {
release_sample_expr(s->pool_conn_name_expr);
s->pool_conn_name_expr = NULL;
}
BUG/MEDIUM: server: avoid changing healthcheck ctx with set server ssl While giving a fresh try to `set server ssl` (which I wrote), I realised the behavior is a bit inconsistent. Indeed when using this command over a server with ssl enabled for the data path but also for the health check path we have: - data and health check done using tls - emit `set server be_foo/srv0 ssl off` - data path and health check path becomes plain text - emit `set server be_foo/srv0 ssl on` - data path becomes tls and health check path remains plain text while I thought the end result would be: - data path and health check path comes back in tls In the current code we indeed erase all connections while deactivating, but restore only the data path while activating. I made this mistake in the past because I was testing with a case where the health check plain text by default. There are several ways to solve this issue. The cleanest one would probably be to avoid changing the health check connection when we use `set server ssl` command, and create a new command `set server ssl-check` to change this. For now I assumed this would be ok to simply avoid changing the health check path and be more consistent. This patch tries to address that and also update the documentation. It should not break the existing usage with health check on plain text, as in this case they should have `no-check-ssl` in defaults. Without this patch, it makes the command unusable in an env where you have a list of server to add along the way with initial `server-template`, and all using tls for data and healthcheck path. For 2.6 we should probably reconsider and add `set server ssl-check` command for better granularity of cases. If this solution is accepted, this patch should be backported up to >= 2.4. The alternative solution was to restore the previous state, but I believe this will create even more confusion in the future. Signed-off-by: William Dauchy <wdauchy@gmail.com>
2022-01-06 10:57:15 -05:00
s->xprt = xprt_get(XPRT_RAW);
BUG/MEDIUM: server: Use sni as pool connection name for SSL server only By default, for a given server, when no pool-conn-name is specified, the configured sni is used. However, this must only be done when SSL is in-use for the server. Of course, it is uncommon to have a sni expression for now-ssl server. But this may happen. In addition, the SSL may be disabled via the CLI. In that case, the pool-conn-name must be discarded if it was copied from the sni. And, we must of course take care to set it if the ssl is enabled. Finally, when the attac-srv action is checked, we now checked the pool-conn-name expression. This patch should be backported as far as 3.0. It relies on "MINOR: server: Parse sni and pool-conn-name expressions in a dedicated function" which should be backported too.
2025-09-03 09:29:56 -04:00
}
BUG/MINOR: server: Update healthcheck when server settings are changed via CLI not all changes are concerned. But when the SSL is enabled or disabled for a server, the healthcheck xprt must be eventually be updated too. This happens when the healthcheck relies on the server settings. In the same spirit, when the healthcheck address and port are updated, we must fallback on the raw xprt if the SSL is not explicitly enabled for the healthcheck with a "check-ssl" parameter. This patch should be backported to all stable versions.
2025-09-03 10:36:25 -04:00
/* Check if we must rely on the server XPRT for the health-check */
if (!s->check.port && !is_addr(&s->check.addr) && !s->check.use_ssl)
s->check.xprt = s->xprt;
BUG/MEDIUM: server: Use sni as pool connection name for SSL server only By default, for a given server, when no pool-conn-name is specified, the configured sni is used. However, this must only be done when SSL is in-use for the server. Of course, it is uncommon to have a sni expression for now-ssl server. But this may happen. In addition, the SSL may be disabled via the CLI. In that case, the pool-conn-name must be discarded if it was copied from the sni. And, we must of course take care to set it if the ssl is enabled. Finally, when the attac-srv action is checked, we now checked the pool-conn-name expression. This patch should be backported as far as 3.0. It relies on "MINOR: server: Parse sni and pool-conn-name expressions in a dedicated function" which should be backported too.
2025-09-03 09:29:56 -04:00
return 0;
CLEANUP: ssl/server: move ssl_sock_set_srv() to srv_set_ssl() in server.c This one has nothing to do with ssl_sock as it manipulates the struct server only. Let's move it to server.c and remove unneeded dependencies on ssl_sock.h. This further reduces by 10% the number of includes of opensslconf.h and by 0.5% the number of compiled lines.
2021-10-06 05:48:34 -04:00
}
#endif /* USE_OPENSSL */
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
MINOR: server: Add server_template_init() function to initialize servers from a templates. This patch adds server_template_init() function used to initialize servers from server templates. It is called just after having parsed a 'server-template' line.
2017-04-14 07:28:00 -04:00
/*
MAJOR/REORG: dns: DNS resolution task and requester queues This patch is a major upgrade of the internal run-time DNS resolver in HAProxy and it brings the following 2 main changes: 1. DNS resolution task Up to now, DNS resolution was triggered by the health check task. From now, DNS resolution task is autonomous. It is started by HAProxy right after the scheduler is available and it is woken either when a network IO occurs for one of its nameserver or when a timeout is matched. From now, this means we can enable DNS resolution for a server without enabling health checking. 2. Introduction of a dns_requester structure Up to now, DNS resolution was purposely made for resolving server hostnames. The idea, is to ensure that any HAProxy internal object should be able to trigger a DNS resolution. For this purpose, 2 things has to be done: - clean up the DNS code from the server structure (this was already quite clean actually) and clean up the server's callbacks from manipulating too much DNS resolution - create an agnostic structure which allows linking a DNS resolution and a requester of any type (using obj_type enum) 3. Manage requesters through queues Up to now, there was an uniq relationship between a resolution and it's owner (aka the requester now). It's a shame, because in some cases, multiple objects may share the same hostname and may benefit from a resolution being performed by a third party. This patch introduces the notion of queues, which are basically lists of either currently running resolution or waiting ones. The resolutions are now available as a pool, which belongs to the resolvers. The pool has has a default size of 64 resolutions per resolvers and is allocated at configuration parsing.
2017-05-22 09:17:15 -04:00
* Prepare <srv> for hostname resolution.
MINOR: server: Add server_template_init() function to initialize servers from a templates. This patch adds server_template_init() function used to initialize servers from server templates. It is called just after having parsed a 'server-template' line.
2017-04-14 07:28:00 -04:00
* May be safely called with a default server as <src> argument (without hostname).
MINOR: server: cli: Add server FQDNs to server-state file and stats socket. This patch adds a new stats socket command to modify server FQDNs at run time. Its syntax: set server <backend>/<server> fqdn <FQDN> This patch also adds FQDNs to server state file at the end of each line for backward compatibility ("-" if not present).
2017-04-26 05:24:02 -04:00
* Returns -1 in case of any allocation failure, 0 if not.
MINOR: server: Add server_template_init() function to initialize servers from a templates. This patch adds server_template_init() function used to initialize servers from server templates. It is called just after having parsed a 'server-template' line.
2017-04-14 07:28:00 -04:00
*/
REORG: server: Export and rename some functions updating server info Some static functions are now exported and renamed to follow the same pattern of other exported functions. Here is the list : * update_server_fqdn: Renamed to srv_update_fqdn and exported * update_server_check_addr_port: renamed to srv_update_check_addr_port and exported * update_server_agent_addr_port: renamed to srv_update_agent_addr_port and exported * update_server_addr: renamed to srv_update_addr * update_server_addr_potr: renamed to srv_update_addr_port * srv_prepare_for_resolution: exported This change is mandatory to move all functions dealing with the server-state files in a separate file.
2021-02-16 06:07:47 -05:00
int srv_prepare_for_resolution(struct server *srv, const char *hostname)
MINOR: server: Add server_template_init() function to initialize servers from a templates. This patch adds server_template_init() function used to initialize servers from server templates. It is called just after having parsed a 'server-template' line.
2017-04-14 07:28:00 -04:00
{
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
char *hostname_dn;
int hostname_len, hostname_dn_len;
MINOR: server: Add server_template_init() function to initialize servers from a templates. This patch adds server_template_init() function used to initialize servers from server templates. It is called just after having parsed a 'server-template' line.
2017-04-14 07:28:00 -04:00
if (!hostname)
MINOR: server: cli: Add server FQDNs to server-state file and stats socket. This patch adds a new stats socket command to modify server FQDNs at run time. Its syntax: set server <backend>/<server> fqdn <FQDN> This patch also adds FQDNs to server state file at the end of each line for backward compatibility ("-" if not present).
2017-04-26 05:24:02 -04:00
return 0;
MINOR: server: Add server_template_init() function to initialize servers from a templates. This patch adds server_template_init() function used to initialize servers from server templates. It is called just after having parsed a 'server-template' line.
2017-04-14 07:28:00 -04:00
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
hostname_len = strlen(hostname);
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
hostname_dn = trash.area;
MINOR: resolvers: fix the resolv_str_to_dn_label() API about trailing zero This function is bogus at the API level: it demands that the input string is zero-terminated *and* that its length *including* the trailing zero is passed on input. While that already looks smelly, the trailing zero is copied as-is, and is then explicitly replaced with a zero... Not only all callers have to pass hostname_len+1 everywhere to work around this absurdity, but this requirement causes a bug in the do-resolve() action that passes random string lengths on input, and that will be fixed on a subsequent patch. Let's fix this API issue for now. This patch will have to be backported, and in versions 2.3 and older, the function is in dns.c and is called dns_str_to_dn_label().
2021-10-14 01:49:49 -04:00
hostname_dn_len = resolv_str_to_dn_label(hostname, hostname_len,
MINOR: resolvers: rework prototype suffixes to split resolving and dns. A lot of prototypes in dns.h are specific to resolvers and must be renamed to split resolving and DNS layers.
2020-12-23 12:49:16 -05:00
hostname_dn, trash.size);
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
if (hostname_dn_len == -1)
goto err;
MINOR: dns: functions to manage memory for a DNS resolution structure A couple of new functions to allocate and free memory for a DNS resolution structure. Main purpose is to to make the code related to DNS more consistent. They allocate or free memory for the structure itself. Later, if needed, they should also allocate / free the buffers, etc, used by this structure. They don't set/unset any parameters, this is the role of the caller. This patch also implement calls to these function eveywhere it is required.
2017-05-03 04:11:44 -04:00
MINOR: server: Add server_template_init() function to initialize servers from a templates. This patch adds server_template_init() function used to initialize servers from server templates. It is called just after having parsed a 'server-template' line.
2017-04-14 07:28:00 -04:00
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
free(srv->hostname);
free(srv->hostname_dn);
srv->hostname = strdup(hostname);
srv->hostname_dn = strdup(hostname_dn);
srv->hostname_dn_len = hostname_dn_len;
MAJOR/REORG: dns: DNS resolution task and requester queues This patch is a major upgrade of the internal run-time DNS resolver in HAProxy and it brings the following 2 main changes: 1. DNS resolution task Up to now, DNS resolution was triggered by the health check task. From now, DNS resolution task is autonomous. It is started by HAProxy right after the scheduler is available and it is woken either when a network IO occurs for one of its nameserver or when a timeout is matched. From now, this means we can enable DNS resolution for a server without enabling health checking. 2. Introduction of a dns_requester structure Up to now, DNS resolution was purposely made for resolving server hostnames. The idea, is to ensure that any HAProxy internal object should be able to trigger a DNS resolution. For this purpose, 2 things has to be done: - clean up the DNS code from the server structure (this was already quite clean actually) and clean up the server's callbacks from manipulating too much DNS resolution - create an agnostic structure which allows linking a DNS resolution and a requester of any type (using obj_type enum) 3. Manage requesters through queues Up to now, there was an uniq relationship between a resolution and it's owner (aka the requester now). It's a shame, because in some cases, multiple objects may share the same hostname and may benefit from a resolution being performed by a third party. This patch introduces the notion of queues, which are basically lists of either currently running resolution or waiting ones. The resolutions are now available as a pool, which belongs to the resolvers. The pool has has a default size of 64 resolutions per resolvers and is allocated at configuration parsing.
2017-05-22 09:17:15 -04:00
if (!srv->hostname || !srv->hostname_dn)
MINOR: server: Add server_template_init() function to initialize servers from a templates. This patch adds server_template_init() function used to initialize servers from server templates. It is called just after having parsed a 'server-template' line.
2017-04-14 07:28:00 -04:00
goto err;
MINOR: server: cli: Add server FQDNs to server-state file and stats socket. This patch adds a new stats socket command to modify server FQDNs at run time. Its syntax: set server <backend>/<server> fqdn <FQDN> This patch also adds FQDNs to server state file at the end of each line for backward compatibility ("-" if not present).
2017-04-26 05:24:02 -04:00
return 0;
MINOR: server: Add server_template_init() function to initialize servers from a templates. This patch adds server_template_init() function used to initialize servers from server templates. It is called just after having parsed a 'server-template' line.
2017-04-14 07:28:00 -04:00
err:
CLEANUP: tree-wide: replace free(x);x=NULL with ha_free(&x) This makes the code more readable and less prone to copy-paste errors. In addition, it allows to place some __builtin_constant_p() predicates to trigger a link-time error in case the compiler knows that the freed area is constant. It will also produce compile-time error if trying to free something that is not a regular pointer (e.g. a function). The DEBUG_MEM_STATS macro now also defines an instance for ha_free() so that all these calls can be checked. 178 occurrences were converted. The vast majority of them were handled by the following Coccinelle script, some slightly refined to better deal with "&*x" or with long lines: @ rule @ expression E; @@ - free(E); - E = NULL; + ha_free(&E); It was verified that the resulting code is the same, more or less a handful of cases where the compiler optimized slightly differently the temporary variable that holds the copy of the pointer. A non-negligible amount of {free(str);str=NULL;str_len=0;} are still present in the config part (mostly header names in proxies). These ones should also be cleaned for the same reasons, and probably be turned into ist strings.
2021-02-20 04:46:51 -05:00
ha_free(&srv->hostname);
ha_free(&srv->hostname_dn);
MINOR: server: cli: Add server FQDNs to server-state file and stats socket. This patch adds a new stats socket command to modify server FQDNs at run time. Its syntax: set server <backend>/<server> fqdn <FQDN> This patch also adds FQDNs to server state file at the end of each line for backward compatibility ("-" if not present).
2017-04-26 05:24:02 -04:00
return -1;
}
BUG/MEDIUM: server: fix dynamic servers initial settings Contrary to static servers, dynamic servers does not initialize their settings from a default server instance. As such, _srv_parse_init() was responsible to set a set of minimal values to have a correct behavior. However, some settings were not properly initialized. This caused dynamic servers to not behave as static ones without explicit parameters. Currently, the main issue detected is connection reuse which was completely impossible. This is due to incorrect pool_purge_delay and max_reuse settings incompatible with srv_add_to_idle_list(). To fix the connection reuse, but also more generally to ensure dynamic servers are aligned with other server instances, define a new function srv_settings_init(). This is used to set initial values for both default servers and dynamic servers. For static servers, srv_settings_cpy() is kept instead, using their default server as reference. This patch could have unexpected effects on dynamic servers behavior as it restored proper initial settings. Previously, they were set to 0 via calloc() invocation from new_server(). This should be backported up to 2.6, after a brief period of observation.
2024-02-27 09:33:59 -05:00
/* Initialize default values for <srv>. Used both for dynamic servers and
* default servers. The latter are not initialized via new_server(), hence this
* function purpose. For static servers, srv_settings_cpy() is used instead
* reusing their default server instance.
*/
void srv_settings_init(struct server *srv)
{
srv->check.inter = DEF_CHKINTR;
srv->check.fastinter = 0;
srv->check.downinter = 0;
srv->check.rise = DEF_RISETIME;
srv->check.fall = DEF_FALLTIME;
srv->check.port = 0;
srv->agent.inter = DEF_CHKINTR;
srv->agent.fastinter = 0;
srv->agent.downinter = 0;
srv->agent.rise = DEF_AGENT_RISETIME;
srv->agent.fall = DEF_AGENT_FALLTIME;
srv->agent.port = 0;
MEDIUM: server: add init-state Allow the user to set the "initial state" of a server. Context: Servers are always set in an UP status by default. In some cases, further checks are required to determine if the server is ready to receive client traffic. This introduces the "init-state {up|down}" configuration parameter to the server. - when set to 'fully-up', the server is considered immediately available and can turn to the DOWN sate when ALL health checks fail. - when set to 'up' (the default), the server is considered immediately available and will initiate a health check that can turn it to the DOWN state immediately if it fails. - when set to 'down', the server initially is considered unavailable and will initiate a health check that can turn it to the UP state immediately if it succeeds. - when set to 'fully-down', the server is initially considered unavailable and can turn to the UP state when ALL health checks succeed. The server's init-state is considered when the HAProxy instance is (re)started, a new server is detected (for example via service discovery / DNS resolution), a server exits maintenance, etc. Link: https://github.com/haproxy/haproxy/issues/51
2024-09-04 18:27:35 -04:00
srv->init_state = SRV_INIT_STATE_UP;
BUG/MEDIUM: server: fix dynamic servers initial settings Contrary to static servers, dynamic servers does not initialize their settings from a default server instance. As such, _srv_parse_init() was responsible to set a set of minimal values to have a correct behavior. However, some settings were not properly initialized. This caused dynamic servers to not behave as static ones without explicit parameters. Currently, the main issue detected is connection reuse which was completely impossible. This is due to incorrect pool_purge_delay and max_reuse settings incompatible with srv_add_to_idle_list(). To fix the connection reuse, but also more generally to ensure dynamic servers are aligned with other server instances, define a new function srv_settings_init(). This is used to set initial values for both default servers and dynamic servers. For static servers, srv_settings_cpy() is kept instead, using their default server as reference. This patch could have unexpected effects on dynamic servers behavior as it restored proper initial settings. Previously, they were set to 0 via calloc() invocation from new_server(). This should be backported up to 2.6, after a brief period of observation.
2024-02-27 09:33:59 -05:00
srv->maxqueue = 0;
srv->minconn = 0;
srv->maxconn = 0;
srv->max_reuse = -1;
srv->max_idle_conns = -1;
srv->pool_purge_delay = 5000;
srv->slowstart = 0;
srv->onerror = DEF_HANA_ONERR;
srv->consecutive_errors_limit = DEF_HANA_ERRLIMIT;
srv->uweight = srv->iweight = 1;
MINOR: quic: implement cc-algo server keyword Extend QUIC server configuration so that congestion algorithm and maximum window size can be set on the server line. This can be achieved using quic-cc-algo keyword with a syntax similar to a bind line. This should be backported up to 3.3 as this feature is considered as necessary for full QUIC backend support. Note that this relies on the serie of previous commits which should be picked first.
2025-11-27 10:25:42 -05:00
#ifdef USE_QUIC
srv->quic_max_cwnd = quic_tune.be.cc_max_win_size;
#endif
BUG/MEDIUM: server: fix dynamic servers initial settings Contrary to static servers, dynamic servers does not initialize their settings from a default server instance. As such, _srv_parse_init() was responsible to set a set of minimal values to have a correct behavior. However, some settings were not properly initialized. This caused dynamic servers to not behave as static ones without explicit parameters. Currently, the main issue detected is connection reuse which was completely impossible. This is due to incorrect pool_purge_delay and max_reuse settings incompatible with srv_add_to_idle_list(). To fix the connection reuse, but also more generally to ensure dynamic servers are aligned with other server instances, define a new function srv_settings_init(). This is used to set initial values for both default servers and dynamic servers. For static servers, srv_settings_cpy() is kept instead, using their default server as reference. This patch could have unexpected effects on dynamic servers behavior as it restored proper initial settings. Previously, they were set to 0 via calloc() invocation from new_server(). This should be backported up to 2.6, after a brief period of observation.
2024-02-27 09:33:59 -05:00
LIST_INIT(&srv->pp_tlvs);
}
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
/*
* Copy <src> server settings to <srv> server allocating
MINOR: proxy: add checks for defsrv's validity Now we only copy the default server's settings if such a default server exists, otherwise we only initialize it. At the moment it always exists. The change is mostly performed in srv_settings_cpy() since that's where each caller passes through, and there's no point duplicating that test everywhere.
2025-07-10 11:03:13 -04:00
* everything needed. This is used to pre-initialize a server from
* default-server settings. If the source is NULL (i.e. no defsrv)
* then we fall back to srv_settings_init() to pre-initialize a
* clean new server.
*
MINOR: server: Add server_template_init() function to initialize servers from a templates. This patch adds server_template_init() function used to initialize servers from server templates. It is called just after having parsed a 'server-template' line.
2017-04-14 07:28:00 -04:00
* This function is not supposed to be called at any time, but only
* during server settings parsing or during server allocations from
* a server template, and just after having calloc()'ed a new server.
* So, <src> may only be a default server (when parsing server settings)
* or a server template (during server allocations from a server template).
* <srv_tmpl> distinguishes these two cases (must be 1 if <srv> is a template,
* 0 if not).
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
*/
REORG: server: Export srv_settings_cpy() function This function will be used to init a proxy with settings of the default proxy. It is mandatory to fix a bug. To do so, it must be exposed.
2022-08-03 05:28:08 -04:00
void srv_settings_cpy(struct server *srv, const struct server *src, int srv_tmpl)
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
{
MINOR: server: Add parser support for set-proxy-v2-tlv-fmt This commit introduces a generic server-side parsing of type-value pair arguments and allocation of a TLV list via a new keyword called set-proxy-v2-tlv-fmt. This allows to 1) forward any TLV type with the help of fc_pp_tlv, 2) generally, send out any TLV type and value via a log format expression. To have this fully working the connection will need to be updated in a follow-up commit to actually respect the new server TLV list. default-server support has also been implemented.
2023-10-28 14:51:26 -04:00
struct srv_pp_tlv_list *srv_tlv = NULL, *new_srv_tlv = NULL;
MINOR: proxy: add checks for defsrv's validity Now we only copy the default server's settings if such a default server exists, otherwise we only initialize it. At the moment it always exists. The change is mostly performed in srv_settings_cpy() since that's where each caller passes through, and there's no point duplicating that test everywhere.
2025-07-10 11:03:13 -04:00
if (!src) {
srv_settings_init(srv);
return;
}
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
/* Connection source settings copy */
srv_conn_src_cpy(srv, src);
MINOR: server: Add server_template_init() function to initialize servers from a templates. This patch adds server_template_init() function used to initialize servers from server templates. It is called just after having parsed a 'server-template' line.
2017-04-14 07:28:00 -04:00
if (srv_tmpl) {
srv->addr = src->addr;
BUG/MEDIUM: server: invalid address (post)parsing checks This bug was introduced with 29b76ca ("BUG/MEDIUM: server/log: "mode log" after server keyword causes crash ") Indeed, we cannot safely rely on addr_proto being set when str2sa_range() returns in parse_server() (even if SRV_PARSE_PARSE_ADDR is set), because proto lookup might be bypassed when FQDN addresses are involved. Unfortunately, the above patch wrongly assumed that proto would always be set when SRV_PARSE_PARSE_ADDR was passed to parse_server() (so when str2sa_range() was called), resulting in invalid postparsing checks being performed, which could as well lead to crashes with log backends ("mode log" set) because some postparsing init was skipped as a result of proto not being set and this wasn't expected later in the init code. To fix this, we now make use of the previous patch to perform server's address compatibility checks on hints that are always set when str2sa_range() succesfully returns. For log backend, we're also adding a complementary test to check if the address family is of expected type, else we report an error, plus we're moving the postinit logic in log api since _srv_check_proxy_mode() is only meant to check proxy mode compatibility and we were abusing it. This patch depends on: - "MINOR: tools: make str2sa_range() directly return type hints" No backport required unless 29b76ca gets backported.
2023-11-09 07:45:03 -05:00
srv->addr_type = src->addr_type;
MINOR: server: Add server_template_init() function to initialize servers from a templates. This patch adds server_template_init() function used to initialize servers from server templates. It is called just after having parsed a 'server-template' line.
2017-04-14 07:28:00 -04:00
srv->svc_port = src->svc_port;
}
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
srv->pp_opts = src->pp_opts;
if (src->rdr_pfx != NULL) {
srv->rdr_pfx = strdup(src->rdr_pfx);
srv->rdr_len = src->rdr_len;
}
if (src->cookie != NULL) {
srv->cookie = strdup(src->cookie);
srv->cklen = src->cklen;
}
srv->use_ssl = src->use_ssl;
BUG/MINOR: server: make "agent-addr" work on default-server line As reported in issue #408, "agent-addr" doesn't work on default-server lines. This is due to the transcription of the old "addr" option in commit 6e5e0d8f9e ("MINOR: server: Make 'default-server' support 'addr' keyword.") which correctly assigns it to the check.addr and agent.addr fields, but which also copies the default check.addr into both the check's and the agent's addr fields. Thus the default agent's address is never used. This fix makes sure to copy the check from the check and the agent from the agent. However it's worth noting that if "addr" is specified on the server line, it will still overwrite both the check and the agent's addresses. This must be backported as far as 1.8.
2019-12-11 09:43:45 -05:00
srv->check.addr = src->check.addr;
srv->agent.addr = src->agent.addr;
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
srv->check.use_ssl = src->check.use_ssl;
srv->check.port = src->check.port;
BUG/MINOR: server: Duplicate healthcheck's sni inherited from default server It is not really an issue, but the "check-sni" value inerited from a default server is not duplicated while the paramter value is duplicated during the parsing. So here there is a small leak if several "check-sni" parameters are used on the same server line. The previous value is never released. But to fix this issue, the value inherited from the default server must also be duplicated. At the end it is safer this way and consistant with the parsing of the "sni" parameter. It is harmless so there is no reason to backport this patch.
2025-09-01 09:13:07 -04:00
if (src->check.sni != NULL)
srv->check.sni = strdup(src->check.sni);
BUG/MEDIUM: server: Duplicate healthcheck's alpn inherited from default server When "check-alpn" parameter is inherited from the default server, the value is not duplicated, the pointer of the default server is used. However, when this parameter is overridden, the old value is released. So the "check-alpn" value of the default server is released. So it is possible to have a UAF if if another server inherit from the same the default server. To fix the issue, the "check-alpn" parameter must be handled the same way the "alpn" is. The default value is duplicated. So it could be safely released if it is forced on the server line. This patch should fix the issue #3096. It must be backported to all stable versions.
2025-09-01 09:04:18 -04:00
if (src->check.alpn_str) {
srv->check.alpn_str = malloc(src->check.alpn_len);
if (srv->check.alpn_str) {
memcpy(srv->check.alpn_str, src->check.alpn_str,
src->check.alpn_len);
srv->check.alpn_len = src->check.alpn_len;
}
}
MINOR: server: activate automatically check reuse for rhttp@ protocol Without check-reuse-pool, it is impossible to perform check on server using @rhttp protocol. This is due to the inherent nature of the protocol which does not implement an active connect method. Thus, ensure that check-reuse-pool is always set when a reverse HTTP server is declared. This reduces server configuration and should prevent any omission. Note that it is still require to add "check" server keyword so activate server checks.
2025-04-02 12:30:46 -04:00
if (!(srv->flags & SRV_F_RHTTP))
srv->check.reuse_pool = src->check.reuse_pool;
MINOR: check: implement check-pool-conn-name srv keyword This commit is a direct follow-up of the previous one. It defines a new server keyword check-pool-conn-name. It is used as the default value for the name parameter of idle connection hash generation. Its behavior is similar to server keyword pool-conn-name, but reserved for checks reuse. If check-pool-conn-name is set, it is used in priority to match a connection for reuse. If unset, a fallback is performed on check-sni.
2025-04-03 09:58:49 -04:00
if (src->check.pool_conn_name)
srv->check.pool_conn_name = strdup(src->check.pool_conn_name);
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
/* Note: 'flags' field has potentially been already initialized. */
srv->flags |= src->flags;
srv->do_check = src->do_check;
srv->do_agent = src->do_agent;
srv->check.inter = src->check.inter;
srv->check.fastinter = src->check.fastinter;
srv->check.downinter = src->check.downinter;
srv->agent.use_ssl = src->agent.use_ssl;
srv->agent.port = src->agent.port;
MEDIUM: checks: Implement agent check using tcp-check rules A shared tcp-check ruleset is now created to support agent checks. The following sequence is used : tcp-check send "%[var(check.agent_string)] log-format tcp-check expect custom The custom function to evaluate the expect rule does the same that it was done to handle agent response when a custom check was used.
2020-04-06 11:54:24 -04:00
if (src->agent.tcpcheck_rules) {
srv->agent.tcpcheck_rules = calloc(1, sizeof(*srv->agent.tcpcheck_rules));
if (srv->agent.tcpcheck_rules) {
srv->agent.tcpcheck_rules->flags = src->agent.tcpcheck_rules->flags;
srv->agent.tcpcheck_rules->list = src->agent.tcpcheck_rules->list;
LIST_INIT(&srv->agent.tcpcheck_rules->preset_vars);
dup_tcpcheck_vars(&srv->agent.tcpcheck_rules->preset_vars,
&src->agent.tcpcheck_rules->preset_vars);
}
}
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
srv->agent.inter = src->agent.inter;
srv->agent.fastinter = src->agent.fastinter;
srv->agent.downinter = src->agent.downinter;
srv->maxqueue = src->maxqueue;
MEDIUM: server/backend: implement websocket protocol selection Handle properly websocket streams if the server uses an ALPN with both h1 and h2. Add a new field h2_ws in the server structure. If set to off, reuse is automatically disable on backend and ALPN is forced to http1.x if possible. Nothing is done if on. Implement a mechanism to be able to use a different http version for websocket streams. A new server member <ws> represents the algorithm to select the protocol. This can overrides the server <proto> configuration. If the connection uses ALPN for proto selection, it is updated for websocket streams to select the right protocol. Three mode of selection are implemented : - auto : use the same protocol between non-ws and ws streams. If ALPN is use, try to update it to "http/1.1"; this is only done if the server ALPN contains "http/1.1". - h1 : use http/1.1 - h2 : use http/2.0; this requires the server to support RFC8441 or an error will be returned by haproxy.
2021-10-18 08:39:57 -04:00
srv->ws = src->ws;
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
srv->minconn = src->minconn;
srv->maxconn = src->maxconn;
srv->slowstart = src->slowstart;
MEDIUM: lb-chash: Deterministic node hashes based on server address Motivation: When services are discovered through DNS resolution, the order in which DNS records get resolved and assigned to servers is arbitrary. Therefore, even though two HAProxy instances using chash balancing might agree that a particular request should go to server3, it is likely the case that they have assigned different IPs and ports to the server in that slot. This patch adds a server option, "hash-key <key>" which can be set to "id" (the existing behaviour, default), "addr", or "addr-port". By deriving the keys for the chash tree nodes from a server's address and port we ensure that independent HAProxy instances will agree on routing decisions. If an address is not known then the key is derived from the server's puid as it was previously. When adjusting a server's weight, we now check whether the server's hash has changed. If it has, we have to remove all its nodes first, since the node keys will also have to change.
2024-02-16 16:00:35 -05:00
srv->hash_key = src->hash_key;
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
srv->observe = src->observe;
srv->onerror = src->onerror;
srv->onmarkeddown = src->onmarkeddown;
srv->onmarkedup = src->onmarkedup;
if (src->trackit != NULL)
srv->trackit = strdup(src->trackit);
srv->consecutive_errors_limit = src->consecutive_errors_limit;
srv->uweight = srv->iweight = src->iweight;
srv->check.send_proxy = src->check.send_proxy;
/* health: up, but will fall down at first failure */
srv->check.rise = srv->check.health = src->check.rise;
srv->check.fall = src->check.fall;
/* Here we check if 'disabled' is the default server state */
MEDIUM: check: server states and weight propagation re-work The server state and weight was reworked to handle "pending" values updated by checks/CLI/LUA/agent. These values are commited to be propagated to the LB stack. In further dev related to multi-thread, the commit will be handled into a sync point. Pending values are named using the prefix 'next_' Current values used by the LB stack are named 'cur_'
2017-08-31 08:41:55 -04:00
if (src->next_admin & (SRV_ADMF_CMAINT | SRV_ADMF_FMAINT)) {
srv->next_admin |= SRV_ADMF_CMAINT | SRV_ADMF_FMAINT;
srv->next_state = SRV_ST_STOPPED;
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
srv->check.state |= CHK_ST_PAUSED;
srv->check.health = 0;
}
/* health: up but will fall down at first failure */
srv->agent.rise = srv->agent.health = src->agent.rise;
srv->agent.fall = src->agent.fall;
if (src->resolvers_id != NULL)
srv->resolvers_id = strdup(src->resolvers_id);
MINOR: resolvers: renames some dns prefixed types using resolv prefix. @@ -119,8 +119,8 @@ struct act_rule { - } dns; /* dns resolution */ + } resolv; /* resolving */ -struct dns_options { +struct resolv_options {
2020-12-23 12:01:04 -05:00
srv->resolv_opts.family_prio = src->resolv_opts.family_prio;
srv->resolv_opts.accept_duplicate_ip = src->resolv_opts.accept_duplicate_ip;
srv->resolv_opts.ignore_weight = src->resolv_opts.ignore_weight;
if (srv->resolv_opts.family_prio == AF_UNSPEC)
srv->resolv_opts.family_prio = AF_INET6;
memcpy(srv->resolv_opts.pref_net,
src->resolv_opts.pref_net,
sizeof srv->resolv_opts.pref_net);
srv->resolv_opts.pref_net_nb = src->resolv_opts.pref_net_nb;
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
srv->init_addr_methods = src->init_addr_methods;
srv->init_addr = src->init_addr;
MEDIUM: server: add init-state Allow the user to set the "initial state" of a server. Context: Servers are always set in an UP status by default. In some cases, further checks are required to determine if the server is ready to receive client traffic. This introduces the "init-state {up|down}" configuration parameter to the server. - when set to 'fully-up', the server is considered immediately available and can turn to the DOWN sate when ALL health checks fail. - when set to 'up' (the default), the server is considered immediately available and will initiate a health check that can turn it to the DOWN state immediately if it fails. - when set to 'down', the server initially is considered unavailable and will initiate a health check that can turn it to the UP state immediately if it succeeds. - when set to 'fully-down', the server is initially considered unavailable and can turn to the UP state when ALL health checks succeed. The server's init-state is considered when the HAProxy instance is (re)started, a new server is detected (for example via service discovery / DNS resolution), a server exits maintenance, etc. Link: https://github.com/haproxy/haproxy/issues/51
2024-09-04 18:27:35 -04:00
srv->init_state = src->init_state;
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
#if defined(USE_OPENSSL)
srv_ssl_settings_cpy(srv, src);
#endif
MINOR: proto-tcp: Add support for TCP MD5 signature for listeners and servers This patch adds the support for the RFC2385 (Protection of BGP Sessions via the + TCP MD5 Signature Option) for the listeners and the servers. The feature is only available on Linux. Keywords are not exposed otherwise. By setting "tcp-md5sig <password>" option on a bind line, TCP segments of all connections instantiated from the listening socket will be signed with a 16-byte MD5 digest. The same option can be set on a server line to protect outgoing connections to the corresponding server. The primary use case for this option is to allow BGP to protect itself against the introduction of spoofed TCP segments into the connection stream. But it can be useful for any very long-lived TCP connections. A reg-test was added and it will be executed only on linux. All other targets are excluded.
2025-07-03 09:16:47 -04:00
#ifdef TCP_MD5SIG
if (src->tcp_md5sig != NULL)
srv->tcp_md5sig = strdup(src->tcp_md5sig);
#endif
MINOR: server: add the "cc" keyword to set the TCP congestion controller It is possible on at least Linux and FreeBSD to set the congestion control algorithm to be used with outgoing connections, among the list of supported and permitted ones. Let's expose this setting with "cc". Unknown or forbidden algorithms will be ignored and the default one will continue to be used.
2025-09-17 11:15:12 -04:00
if (src->cc_algo != NULL)
srv->cc_algo = strdup(src->cc_algo);
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
#ifdef TCP_USER_TIMEOUT
srv->tcp_ut = src->tcp_ut;
#endif
MINOR: mux/server: Add 'proto' keyword to force the multiplexer's protocol For now, it is parsed but not used. Tests are done on it to check if the side and the mode are compatible with the server's definition.
2018-04-10 08:45:45 -04:00
srv->mux_proto = src->mux_proto;
MINOR: server: define pool-conn-name keyword Define a new server keyword pool-conn-name. The purpose of this keyword will be to identify connections inside the idle connections pool, replacing SNI in case SSL is not wanted. This keyword uses a sample expression argument. It thus can reuse existing function parse_srv_expr() for parsing. In the future, it may be necessary to define a keyword variant which uses a logformat for extensability. This patch only implement parsing. Argument is stored inside new server field <pool_conn_name> and expression is generated in _srv_parse_finalize() into <pool_conn_name_expr>. If pool-conn-name is not set but SNI is, the latter is reused automatically as pool-conn-name via _srv_parse_finalize(). This ensures current reuse behavior remains compatible and idle connection reuse will not mix connections with different SNIs by mistake. Main usage will be for rhttp when SSL is not wanted between the two haproxy instances. Previously, it was possible to use "sni" keyword even without SSL on a server line which have a similar effect. However, having a dedicated "pool-conn-name" keyword is deemed clearer. Besides, it would allow for more complex configuration where pool-conn-name and SNI are use in parallel with different values.
2024-05-23 05:14:13 -04:00
if (srv->pool_conn_name)
srv->pool_conn_name = strdup(srv->pool_conn_name);
MEDIUM: servers: Replace idle-timeout with pool-purge-delay. Instead of the old "idle-timeout" mechanism, add a new option, "pool-purge-delay", that sets the delay before purging idle connections. Each time the delay happens, we destroy half of the idle connections.
2018-12-14 12:15:36 -05:00
srv->pool_purge_delay = src->pool_purge_delay;
MEDIUM: server: add a new pool-low-conn server setting The problem with the way idle connections currently work is that it's easy for a thread to steal all of its siblings' connections, then release them, then it's done by another one, etc. This happens even more easily due to scheduling latencies, or merged events inside the same pool loop, which, when dealing with a fast server responding in sub-millisecond delays, can really result in one thread being fully at work at a time. In such a case, we perform a huge amount of takeover() which consumes CPU and requires quite some locking, sometimes resulting in lower performance than expected. In order to fight against this problem, this patch introduces a new server setting "pool-low-conn", whose purpose is to dictate when it is allowed to steal connections from a sibling. As long as the number of idle connections remains at least as high as this value, it is permitted to take over another connection. When the idle connection count becomes lower, a thread may only use its own connections or create a new one. By proceeding like this even with a low number (typically 2*nbthreads), we quickly end up in a situation where all active threads have a few connections. It then becomes possible to connect to a server without bothering other threads the vast majority of the time, while still being able to use these connections when the number of available FDs becomes low. We also use this threshold instead of global.nbthread in the connection release logic, allowing to keep more extra connections if needed. A test performed with 10000 concurrent HTTP/1 connections, 16 threads and 210 servers with 1 millisecond of server response time showed the following numbers: haproxy 2.1.7: 185000 requests per second haproxy 2.2: 314000 requests per second haproxy 2.2 lowconn 32: 352000 requests per second The takeover rate goes down from 300k/s to 13k/s. The difference is further amplified as the response time shrinks.
2020-07-01 01:43:51 -04:00
srv->low_idle_conns = src->low_idle_conns;
MEDIUM: servers: Add a command to limit the number of idling connections. Add a new command, "pool-max-conn" that sets the maximum number of connections waiting in the orphan idling connections list (as activated with idle-timeout). Using "-1" means unlimited. Using pools is now dependant on this.
2018-12-10 12:30:32 -05:00
srv->max_idle_conns = src->max_idle_conns;
MINOR: server: add a max-reuse parameter Some servers may wish to limit the total number of requests they execute over a connection because some of their components might leak resources. In HTTP/1 it was easy, they just had to emit a "connection: close" header field with the last response. In HTTP/2, it's less easy because the info is not always shared with the component dealing with the H2 protocol and it could be harder to advertise a GOAWAY with a stream limit. This patch provides a solution to this by adding a new "max-reuse" parameter to the server keyword. This parameter indicates how many times an idle connection may be reused for new requests. The information is made available and the underlying muxes will be able to use it at will. This patch should be backported to 1.9.
2019-01-23 04:21:49 -05:00
srv->max_reuse = src->max_reuse;
MINOR: mux/server: Add 'proto' keyword to force the multiplexer's protocol For now, it is parsed but not used. Tests are done on it to check if the side and the mode are compatible with the server's definition.
2018-04-10 08:45:45 -04:00
MINOR: quic: implement cc-algo server keyword Extend QUIC server configuration so that congestion algorithm and maximum window size can be set on the server line. This can be achieved using quic-cc-algo keyword with a syntax similar to a bind line. This should be backported up to 3.3 as this feature is considered as necessary for full QUIC backend support. Note that this relies on the serie of previous commits which should be picked first.
2025-11-27 10:25:42 -05:00
#ifdef USE_QUIC
srv->quic_cc_algo = src->quic_cc_algo;
srv->quic_max_cwnd = src->quic_max_cwnd;
#endif
MINOR: dns: Handle SRV records. Make it so for each server, instead of specifying a hostname, one can use a SRV label. When doing so, haproxy will first resolve the SRV label, then use the resulting hostnames, as well as port and weight (priority is ignored right now), to each server using the SRV label. It is resolved periodically, and any server disappearing from the SRV records will be removed, and any server appearing will be added, assuming there're free servers in haproxy.
2017-08-04 12:35:36 -04:00
if (srv_tmpl)
srv->srvrq = src->srvrq;
MEDIUM: connection: Upstream SOCKS4 proxy support Have "socks4" and "check-via-socks4" server keyword added. Implement handshake with SOCKS4 proxy server for tcp stream connection. See issue #82. I have the "SOCKS: A protocol for TCP proxy across firewalls" doc found at "https://www.openssh.com/txt/socks4.protocol". Please reference to it. [wt: for now connecting to the SOCKS4 proxy over unix sockets is not supported, and mixing IPv4/IPv6 is discouraged; indeed, the control layer is unique for a connection and will be used both for connecting and for target address manipulation. As such it may for example report incorrect destination addresses in logs if the proxy is reached over IPv6]
2019-05-22 07:44:48 -04:00
BUG/MINOR: server: inherit from netns in srv_settings_cpy() When support for 'namespace' keyword was added for the 'default-server' directive in 22f41a2 ("MINOR: server: Make 'default-server' support 'namespace' keyword."), we forgot to copy the attribute from the parent to the newly created server. This resulted in the 'namespace' keyword being parsed without errors when used from a 'default-server' directive, but in practise the option was simply ignored. There's no need to duplicate the netns struct because it is stored in a shared list, so copying the pointer does the job. This patch partially fixes GH #2038 and should be backported to all stable versions.
2023-06-14 03:53:32 -04:00
srv->netns = src->netns;
MEDIUM: connection: Upstream SOCKS4 proxy support Have "socks4" and "check-via-socks4" server keyword added. Implement handshake with SOCKS4 proxy server for tcp stream connection. See issue #82. I have the "SOCKS: A protocol for TCP proxy across firewalls" doc found at "https://www.openssh.com/txt/socks4.protocol". Please reference to it. [wt: for now connecting to the SOCKS4 proxy over unix sockets is not supported, and mixing IPv4/IPv6 is discouraged; indeed, the control layer is unique for a connection and will be used both for connecting and for target address manipulation. As such it may for example report incorrect destination addresses in logs if the proxy is reached over IPv6]
2019-05-22 07:44:48 -04:00
srv->check.via_socks4 = src->check.via_socks4;
srv->socks4_addr = src->socks4_addr;
MINOR: server: introduce "log-bufsize" kw "log-bufsize" may now be used for a log server (in a log backend) to configure the bufsize of implicit ring associated to the server (which defaults to BUFSIZE).
2023-10-04 04:32:45 -04:00
srv->log_bufsize = src->log_bufsize;
MINOR: server: Add parser support for set-proxy-v2-tlv-fmt This commit introduces a generic server-side parsing of type-value pair arguments and allocation of a TLV list via a new keyword called set-proxy-v2-tlv-fmt. This allows to 1) forward any TLV type with the help of fc_pp_tlv, 2) generally, send out any TLV type and value via a log format expression. To have this fully working the connection will need to be updated in a follow-up commit to actually respect the new server TLV list. default-server support has also been implemented.
2023-10-28 14:51:26 -04:00
LIST_INIT(&srv->pp_tlvs);
list_for_each_entry(srv_tlv, &src->pp_tlvs, list) {
CLEANUP: Re-apply xalloc_size.cocci (3) This reapplies the xalloc_size.cocci patch across the whole `src/` tree. see 16cc16dd8235e7eb6c38b7abd210bd1e1d96b1d9 see 63ee0e4c01b94aee5fc6c6dd98cfc4480ae5ea46 see 9fb57e8c175a0b852b06a0780f48eb8eaf321a47
2023-11-05 14:02:37 -05:00
new_srv_tlv = malloc(sizeof(*new_srv_tlv));
MINOR: server: Add parser support for set-proxy-v2-tlv-fmt This commit introduces a generic server-side parsing of type-value pair arguments and allocation of a TLV list via a new keyword called set-proxy-v2-tlv-fmt. This allows to 1) forward any TLV type with the help of fc_pp_tlv, 2) generally, send out any TLV type and value via a log format expression. To have this fully working the connection will need to be updated in a follow-up commit to actually respect the new server TLV list. default-server support has also been implemented.
2023-10-28 14:51:26 -04:00
if (unlikely(!new_srv_tlv)) {
break;
}
new_srv_tlv->fmt_string = strdup(srv_tlv->fmt_string);
if (unlikely(!new_srv_tlv->fmt_string)) {
free(new_srv_tlv);
break;
}
new_srv_tlv->type = srv_tlv->type;
BUG/MEDIUM: server: properly initialize PROXY v2 TLVs The PROXY v2 TLVs were not properly initialized when defined with "set-proxy-v2-tlv-fmt" keyword, which could have caused a crash when validating the configuration or malfunction (e.g. when used in combination with "server-template" and/or "default-server"). The issue was introduced with commit 6f4bfed3a ("MINOR: server: Add parser support for set-proxy-v2-tlv-fmt"). This should be backported up to 2.9.
2025-02-26 13:13:31 -05:00
lf_expr_init(&new_srv_tlv->fmt);
if (srv_tmpl) {
if (new_srv_tlv->fmt_string && unlikely(!parse_logformat_string(new_srv_tlv->fmt_string,
srv->proxy, &new_srv_tlv->fmt, 0, SMP_VAL_BE_SRV_CON, NULL))) {
free(new_srv_tlv->fmt_string);
free(new_srv_tlv);
break;
}
}
MINOR: server: Add parser support for set-proxy-v2-tlv-fmt This commit introduces a generic server-side parsing of type-value pair arguments and allocation of a TLV list via a new keyword called set-proxy-v2-tlv-fmt. This allows to 1) forward any TLV type with the help of fc_pp_tlv, 2) generally, send out any TLV type and value via a log format expression. To have this fully working the connection will need to be updated in a follow-up commit to actually respect the new server TLV list. default-server support has also been implemented.
2023-10-28 14:51:26 -04:00
LIST_APPEND(&srv->pp_tlvs, &new_srv_tlv->list);
}
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
}
CLEANUP: assorted typo fixes in the code, commits and doc Corrected various spelling and phrasing errors to improve clarity and consistency.
2025-07-09 15:05:55 -04:00
/* Allocates a server, attaches it to the global servers_list
MEDIUM: server: automatically add server to proxy list in new_server() while new_server() takes the parent proxy as argument and even assigns srv->proxy to the parent proxy, it didn't actually inserted the server to the parent proxy server list on success. The result is that sometimes we add the server to the list after new_server() is called, and sometimes we don't. This is really error-prone and because of that hooks such as REGISTER_POST_SERVER_CHECK() which as run for all servers listed in all proxies may not be relied upon for servers which are not actually inserted in their parent proxy server list. Plus it feels very strange to have a server that points to a proxy, but then the proxy doesn't know about it because it cannot find it in its server list. To prevent errors and make proxy->srv list reliable, we move the insertion logic directly under new_server(). This requires to know if we are called during parsing or during runtime to either insert or append the server to the parent proxy list. For that we use PR_FL_CHECKED flag from the parent proxy (if the flag is set, then the proxy was checked so we are past the init phase, thus we assume we are called during runtime) This implies that during startup if new_server() has to be cancelled on error paths we need to call srv_detach() (which is now exposed in server.h) before srv_drop(). The consequence of this commit is that REGISTER_POST_SERVER_CHECK() should not run reliably on all servers created using new_server() (without having to manually loop on global servers_list)
2025-05-09 13:24:55 -04:00
* and adds it to <proxy> server list. Before deleting the server with
* srv_drop(), srv_detach() must be called to remove it from the parent
* proxy list
*
* Returns the server on success, otherwise NULL.
MINOR: server: add a global list of all known servers It's a real pain not to have access to the list of all registered servers, because whenever there is a need to late adjust their configuration, only those attached to regular proxies are seen, but not the peers, lua, logs nor DNS. What this patch does is that new_server() will automatically add the newly created server to a global list, and it does so as well for the 1 or 2 statically allocated servers created for Lua. This way it will be possible to iterate over all of them.
2021-03-05 04:23:32 -05:00
*/
MINOR: server: export new_server() function The new_server() function will be useful to create a proxy for the master-worker.
2018-10-26 08:47:32 -04:00
struct server *new_server(struct proxy *proxy)
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
{
struct server *srv;
MEDIUM: server: introduce srv_alloc()/srv_free() to alloc/free a server It happens that we free servers at various places in the code, both on error paths and at runtime thanks to the "server delete" feature. In order to switch to an aligned struct, we'll need to change the calloc() and free() calls. Let's first spot them and switch them to srv_alloc() and srv_free() instead of using calloc() and either free() or ha_free(). An easy trap to fall into is that some of them are default-server entries. The new srv_free() function also resets the pointer like ha_free() does. This was done by running the following coccinelle script all over the code: @@ struct server *srv; @@ ( - free(srv) + srv_free(&srv) | - ha_free(&srv) + srv_free(&srv) ) @@ struct server *srv; expression e1; expression e2; @@ ( - srv = malloc(e1) + srv = srv_alloc() | - srv = calloc(e1, e2) + srv = srv_alloc() ) This is marked medium because despite spotting all call places, we can never rule out the possibility that some out-of-tree patches would allocate their own servers and continue to use the old API... at their own risk.
2025-08-13 05:52:59 -04:00
srv = srv_alloc();
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
if (!srv)
return NULL;
MEDIUM: server: extend refcount for all servers In a future patch, it will be possible to remove at runtime every servers, both static and dynamic. This requires to extend the server refcount for all instances. First, refcount manipulation functions have been renamed to better express the API usage. * srv_refcount_use -> srv_take The refcount is always initialize to 1 on the server creation in new_server. It's also incremented for each check/agent configured on a server instance. * free_server -> srv_drop This decrements the refcount and if null, the server is freed, so code calling it must not use the server reference after it. As a bonus, this function now returns the next server instance. This is useful when calling on the server loop without having to save the next pointer before each invocation. In these functions, remove the checks that prevent refcount on non-dynamic servers. Each reference to "dynamic" in variable/function naming have been eliminated as well.
2021-08-25 09:34:53 -04:00
srv_take(srv);
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
srv->obj_type = OBJ_TYPE_SERVER;
srv->proxy = proxy;
BUG/MEDIUM: server: fix race on servers_list during server deletion Each server is inserted in a global list named servers_list on new_server(). This list is then only used to finalize servers initialization after parsing. On dynamic server creation, there is no issue as new_server() is under thread isolation. However, when a server is deleted after its refcount reached zero, srv_drop() removes it from servers_list without lock protection. In the longterm, this can cause list corruption and crashes, especially if multiple adjacent servers are removed in parallel. To fix this, convert servers_list to a mt_list. This should not impact performance as servers_list is not used during runtime outside of server creation/deletion. This should fix github issue #2733. Thanks to Chris Staite who first found the issue here. This must be backported up to 2.6.
2024-10-23 12:18:48 -04:00
MT_LIST_APPEND(&servers_list, &srv->global_list);
MEDIUM: resolvers: add a ref between servers and srv request or used SRV record This patch add a ref into servers to register them onto the record answer item used to set their hostnames. It also adds a head list into 'srvrq' to register servers free to be affected to a SRV record. A head of a tree is also added to srvrq to put servers which present a hotname in server state file. To re-link them fastly to the matching record as soon an item present the same name. This results in better performances on SRV record response parsing. This is an optimization but it could avoid to trigger the haproxy's internal wathdog in some circumstances. And for this reason it should be backported as far we can (2.0 ?)
2021-06-11 04:48:45 -04:00
LIST_INIT(&srv->srv_rec_item);
MEDIUM: resolvers: add a ref on server to the used A/AAAA answer item This patch adds a head list into answer items on servers which use this record to set their IPs. It makes lookup on duplicated ip faster and allow to check immediatly if an item is still valid renewing the IP. This results in better performances on A/AAAA resolutions. This is an optimization but it could avoid to trigger the haproxy's internal wathdog in some circumstances. And for this reason it should be backported as far we can (2.0 ?)
2021-06-11 04:08:05 -04:00
LIST_INIT(&srv->ip_rec_item);
MINOR: server: Add parser support for set-proxy-v2-tlv-fmt This commit introduces a generic server-side parsing of type-value pair arguments and allocation of a TLV list via a new keyword called set-proxy-v2-tlv-fmt. This allows to 1) forward any TLV type with the help of fc_pp_tlv, 2) generally, send out any TLV type and value via a log format expression. To have this fully working the connection will need to be updated in a follow-up commit to actually respect the new server TLV list. default-server support has also been implemented.
2023-10-28 14:51:26 -04:00
LIST_INIT(&srv->pp_tlvs);
MINOR: server/event_hdl: add support for SERVER_ADD and SERVER_DEL events Basic support for ADD and DEL server events are added through this commit: SERVER_ADD is published on dynamic server addition through cli. SERVER_DEL is published on dynamic server deletion through cli. This work depends on: "MINOR: event_hdl: add event handler base api" "MINOR: server: add srv->rid (revision id) value"
2022-11-17 04:37:58 -05:00
event_hdl_sub_list_init(&srv->e_subs);
BUG/MINOR: server: set rid default value in new_server() srv->rid default value is set in _srv_parse_init() after the server is succesfully allocated using new_server(). This is wrong because new_server() can be used independently so rid value assignment would be skipped in this case. Hopefully new_server() allocates server data using calloc() so srv->rid is already set to 0 in practise. But if calloc() is replaced by malloc() or other memory allocating function that doesn't zero-initialize srv members, this could lead to rid being uninitialized in some cases. This should be backported in 2.8 with 61e3894dfe ("MINOR: server: add srv->rid (revision id) value")
2023-07-07 09:19:36 -04:00
srv->rid = 0; /* rid defaults to 0 */
MEDIUM: threads/server: Make connection list (priv/idle/safe) thread-safe For now, we have a list of each type per thread. So there is no need to lock them. This is the easiest solution for now, but not the best one because there is no sharing between threads. An idle connection on a thread will not be able be used by a stream on another thread. So it could be a good idea to rework this patch later.
2017-07-03 09:41:01 -04:00
MEDIUM: check: server states and weight propagation re-work The server state and weight was reworked to handle "pending" values updated by checks/CLI/LUA/agent. These values are commited to be propagated to the LB stack. In further dev related to multi-thread, the commit will be handled into a sync point. Pending values are named using the prefix 'next_' Current values used by the LB stack are named 'cur_'
2017-08-31 08:41:55 -04:00
srv->next_state = SRV_ST_RUNNING; /* early server setup */
MEDIUM: server: add and use a separate last_change variable for internal use last_change server metric is used for 2 separate purposes. First it is used to report last server state change date for stats and other related metrics. But it is also used internally, including in sensitive paths, such as lb related stuff to take decision or perform computations (ie: in srv_dynamic_maxconn()). Due to last_change counter now being split over thread groups since 16eb0fa ("MAJOR: counters: dispatch counters over thread groups"), reading the aggregated value has a cost, and we cannot afford to consult last_change value from srv_dynamic_maxconn() anymore. Moreover, since the value is used to take decision for the current process we don't wan't the variable to be updated by another process in our back. To prevent performance regression and sharing issues, let's instead add a separate srv->last_change value, which is not updated atomically (given how rare the updates are), and only serves for places where the use of the aggregated last_change counter/stats (split over thread groups) is too costly.
2025-06-30 04:57:29 -04:00
srv->last_change = ns_to_sec(now_ns);
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
MINOR: checks/obj_type: Add a new object type for checks An object type is now affected to the check structure.
2020-04-21 05:46:40 -04:00
srv->check.obj_type = OBJ_TYPE_CHECK;
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
srv->check.status = HCHK_STATUS_INI;
srv->check.server = srv;
MINOR: checks: Store the proxy in checks. Instead of assuming we have a server, store the proxy directly in struct check, and use it instead of s->server. This should be a no-op for now, but will be useful later when we change mail checks to avoid having a server. This should be backported to 1.9.
2019-01-11 12:17:17 -05:00
srv->check.proxy = proxy;
MEDIUM: checks: Add a shared list of tcp-check rules A global list to tcp-check ruleset can now be used to share common rulesets with all backends without any duplication. It is mandatory to convert all specific protocol checks (redis, pgsql...) to tcp-check healthchecks. To do so, a flag is now attached to each tcp-check ruleset to know if it is a shared ruleset or not. tcp-check rules defined in a backend are still directly attached to the proxy and not shared. In addition a second flag is used to know if the ruleset is inherited from the defaults section.
2020-03-30 14:34:34 -04:00
srv->check.tcpcheck_rules = &proxy->tcpcheck_rules;
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
MINOR: checks/obj_type: Add a new object type for checks An object type is now affected to the check structure.
2020-04-21 05:46:40 -04:00
srv->agent.obj_type = OBJ_TYPE_CHECK;
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
srv->agent.status = HCHK_STATUS_INI;
srv->agent.server = srv;
BUG/MEDIUM: checks: fix recent regression on agent-check making it crash In order to address the mailers issues, we needed to store the proxy into the checks struct, which was done by commit c98aa1f18 ("MINOR: checks: Store the proxy in checks."). However this one did it only for the health checks and not for the agent checks, resulting in an immediate crash when the agent is enabled on a random config like this one : listen agent bind :8000 server s1 255.255.255.255:1 agent-check agent-port 1 Thanks to Seri Kim for reporting it and providing a reproducer in issue #20. This fix must be backported to 1.9.
2019-01-21 01:48:26 -05:00
srv->agent.proxy = proxy;
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
srv->xprt = srv->check.xprt = srv->agent.xprt = xprt_get(XPRT_RAW);
MINOR: server: implement GUID support This commit is similar to previous one, except that it implements GUID support for server instances. A guid_node field is inserted into server structure. A new "guid" server keyword is defined.
2024-03-26 10:01:35 -04:00
guid_init(&srv->guid);
BUG/MEDIUM: stats/server: use watcher to track server during stats dump If a server A is deleted while a stats dump is currently on it, deletion is delayed thanks to reference counting. Server A is nonetheless removed from the proxy list. However, this list is a single linked list. If the next server B is deleted and freed immediately, server A would still point to it. This problem has been solved by the prev_deleted list in servers. This model seems correct, but it is difficult to ensure completely its validity. In particular, it implies when stats dump is resumed, server A elements will be accessed despite the server being in a half-deleted state. Thus, it has been decided to completely ditch the refcount mechanism for stats dump. Instead, use the watcher element to register every stats dump currently tracking a server instance. Each time a server is deleted on the CLI, each stats dump element which may points to it are updated to access the next server instance, or NULL if this is the last server. This ensures that a server which was deleted via CLI but not completely freed is never accessed on stats dump resumption. Currently, no race condition related to dynamic servers and stats dump is known. However, as described above, the previous model is deemed too fragile, as such this patch is labelled as bug-fix. It should be backported up to 2.6, after a reasonable period of observation. It relies on the following patch : MINOR: list: define a watcher type
2024-10-23 05:33:34 -04:00
MT_LIST_INIT(&srv->watcher_list);
MINOR: server: implement GUID support This commit is similar to previous one, except that it implements GUID support for server instances. A guid_node field is inserted into server structure. A new "guid" server keyword is defined.
2024-03-26 10:01:35 -04:00
BUG/MEDIUM: stats: prevent crash if counters not alloc with dummy one Define a per-thread counters allocated with the greatest size of any stat module counters. This variable is named trash_counters. When using a proxy without allocated counters, return the trash counters from EXTRA_COUNTERS_GET instead of a dangling pointer to prevent segfault. This is useful for all the proxies used internally and not belonging to the global proxy list. As these objects does not appears on the stat report, it does not matter to use the dummy counters. For this fix to be functional, the extra counters are explicitly initialized to NULL on proxy/server/listener init functions. Most notably, the crash has already been detected with the following vtc: - reg-tests/lua/txn_get_priv.vtc - reg-tests/peers/tls_basic_sync.vtc - reg-tests/peers/tls_basic_sync_wo_stkt_backend.vtc There is probably other parts that may be impacted (SPOE for example). This bug was introduced in the current release and do not need to be backported. The faulty commits are "MINOR: ssl: count client hello for stats" and "MINOR: ssl: add counters for ssl sessions".
2020-11-10 08:24:31 -05:00
srv->extra_counters = NULL;
MEDIUM: ssl: add a rwlock for SSL server session cache When adding the server side support for certificate update over the CLI we encountered a design problem with the SSL session cache which was not locked. Indeed, once a certificate is updated we need to flush the cache, but we also need to ensure that the cache is not used during the update. To prevent the use of the cache during an update, this patch introduce a rwlock for the SSL server session cache. In the SSL session part this patch only lock in read, even if it writes. The reason behind this, is that in the session part, there is one cache storage per thread so it is not a problem to write in the cache from several threads. The problem is only when trying to write in the cache from the CLI (which could be on any thread) when a session is trying to access the cache. So there is a write lock in the CLI part to prevent simultaneous access by a session and the CLI. This patch also remove the thread_isolate attempt which is eating too much CPU time and was not protecting from the use of a free ptr in the session.
2021-02-08 04:43:44 -05:00
#ifdef USE_OPENSSL
HA_RWLOCK_INIT(&srv->ssl_ctx.lock);
#endif
BUG/MEDIUM: stats: prevent crash if counters not alloc with dummy one Define a per-thread counters allocated with the greatest size of any stat module counters. This variable is named trash_counters. When using a proxy without allocated counters, return the trash counters from EXTRA_COUNTERS_GET instead of a dangling pointer to prevent segfault. This is useful for all the proxies used internally and not belonging to the global proxy list. As these objects does not appears on the stat report, it does not matter to use the dummy counters. For this fix to be functional, the extra counters are explicitly initialized to NULL on proxy/server/listener init functions. Most notably, the crash has already been detected with the following vtc: - reg-tests/lua/txn_get_priv.vtc - reg-tests/peers/tls_basic_sync.vtc - reg-tests/peers/tls_basic_sync_wo_stkt_backend.vtc There is probably other parts that may be impacted (SPOE for example). This bug was introduced in the current release and do not need to be backported. The faulty commits are "MINOR: ssl: count client hello for stats" and "MINOR: ssl: add counters for ssl sessions".
2020-11-10 08:24:31 -05:00
MEDIUM: server: automatically add server to proxy list in new_server() while new_server() takes the parent proxy as argument and even assigns srv->proxy to the parent proxy, it didn't actually inserted the server to the parent proxy server list on success. The result is that sometimes we add the server to the list after new_server() is called, and sometimes we don't. This is really error-prone and because of that hooks such as REGISTER_POST_SERVER_CHECK() which as run for all servers listed in all proxies may not be relied upon for servers which are not actually inserted in their parent proxy server list. Plus it feels very strange to have a server that points to a proxy, but then the proxy doesn't know about it because it cannot find it in its server list. To prevent errors and make proxy->srv list reliable, we move the insertion logic directly under new_server(). This requires to know if we are called during parsing or during runtime to either insert or append the server to the parent proxy list. For that we use PR_FL_CHECKED flag from the parent proxy (if the flag is set, then the proxy was checked so we are past the init phase, thus we assume we are called during runtime) This implies that during startup if new_server() has to be cancelled on error paths we need to call srv_detach() (which is now exposed in server.h) before srv_drop(). The consequence of this commit is that REGISTER_POST_SERVER_CHECK() should not run reliably on all servers created using new_server() (without having to manually loop on global servers_list)
2025-05-09 13:24:55 -04:00
// add server to proxy list:
/* TODO use a double-linked list for px->srv */
if (!(proxy->flags & PR_FL_CHECKED) || !proxy->srv) {
/* they are linked backwards first during parsing
* This will be restablished after parsing.
*/
srv->next = proxy->srv;
proxy->srv = srv;
}
else {
struct server *sv = proxy->srv;
// runtime, add the server at the end of the list
while (sv && sv->next)
sv = sv->next;
sv->next = srv;
}
BUG/MEDIUM: server: Add a rwlock to path parameter Add a rwlock to control the server's path_parameter, to make sure multiple threads don't set it at the same time, and it can't be seen in an inconsistent state. Also don't set the parameter every time, only set them if they have changed, to prevent needless writes. This does not need to be backported.
2025-11-04 10:46:50 -05:00
HA_RWLOCK_INIT(&srv->path_params.param_lock);
MINOR: proxy: remove proxy_preset_defaults() Function proxy_preset_defaults() purpose has evolved over time. Originally, it was only used to initialize defaults proxies instances. Until today, it was extended so that all proxies use it. Its objective is to initialize settings to common default values. To remove the confusion, this function is now removed. Its content is integrated directly into init_new_proxy().
2026-01-20 05:41:37 -05:00
MINOR: server: Extract the code responsible of copying default-server settings. This patch moves the code responsible of copying default server settings to a new server instance from parse_server() function to new defsrv_*_cpy() functions which may be used both during server lines parsing and during server templates initializations to come. These defsrv_*_cpy() do not make any reference to anything else than default server settings.
2017-03-30 08:18:30 -04:00
return srv;
}
MEDIUM: server: extend refcount for all servers In a future patch, it will be possible to remove at runtime every servers, both static and dynamic. This requires to extend the server refcount for all instances. First, refcount manipulation functions have been renamed to better express the API usage. * srv_refcount_use -> srv_take The refcount is always initialize to 1 on the server creation in new_server. It's also incremented for each check/agent configured on a server instance. * free_server -> srv_drop This decrements the refcount and if null, the server is freed, so code calling it must not use the server reference after it. As a bonus, this function now returns the next server instance. This is useful when calling on the server loop without having to save the next pointer before each invocation. In these functions, remove the checks that prevent refcount on non-dynamic servers. Each reference to "dynamic" in variable/function naming have been eliminated as well.
2021-08-25 09:34:53 -04:00
/* Increment the server refcount. */
void srv_take(struct server *srv)
MINOR: server: implement a refcount for dynamic servers It is necessary to have a refcount mechanism on dynamic servers to be able to enable check support. Indeed, when deleting a dynamic server with check activated, the check will be asynchronously removed. This is mandatory to properly free the check resources in a thread-safe manner. The server instance must be kept alive for this.
2021-08-02 09:50:00 -04:00
{
MEDIUM: server: extend refcount for all servers In a future patch, it will be possible to remove at runtime every servers, both static and dynamic. This requires to extend the server refcount for all instances. First, refcount manipulation functions have been renamed to better express the API usage. * srv_refcount_use -> srv_take The refcount is always initialize to 1 on the server creation in new_server. It's also incremented for each check/agent configured on a server instance. * free_server -> srv_drop This decrements the refcount and if null, the server is freed, so code calling it must not use the server reference after it. As a bonus, this function now returns the next server instance. This is useful when calling on the server loop without having to save the next pointer before each invocation. In these functions, remove the checks that prevent refcount on non-dynamic servers. Each reference to "dynamic" in variable/function naming have been eliminated as well.
2021-08-25 09:34:53 -04:00
HA_ATOMIC_INC(&srv->refcount);
MINOR: server: implement a refcount for dynamic servers It is necessary to have a refcount mechanism on dynamic servers to be able to enable check support. Indeed, when deleting a dynamic server with check activated, the check will be asynchronously removed. This is mandatory to properly free the check resources in a thread-safe manner. The server instance must be kept alive for this.
2021-08-02 09:50:00 -04:00
}
BUG/MINOR: proxy/server: free default-server on deinit proxy default-server is a specific type of server that is not allocated using new_server(): it is directly stored within the parent proxy structure. However, since it may contain some default config options that may be inherited by regular servers, it is also subject to dynamic members (strings, structures..) that needs to be deallocated when the parent proxy is cleaned up. Unfortunately, srv_drop() may not be used directly from p->defsrv since this function is meant to be used on regular servers only (those created using new_server()). To circumvent this, we're splitting srv_drop() to make a new function called srv_free_params() that takes care of the member cleaning which originally takes place in srv_drop(). This function is exposed through server.h, so it may be called from outside server.c. Thanks to this, calling srv_free_params(&p->defsrv) from free_proxy() prevents any memory leaks due to dynamic parameters allocated when parsing a default-server line from a proxy section. This partially fixes GH #2173 and may be backported to 2.8. [While it could also be relevant for other stable versions, the patch won't apply due to architectural changes / name changes between 2.4 => 2.6 and then 2.6 => 2.8. Considering this is a minor fix that only makes memory analyzers happy during deinit paths (at least for <= 2.8), it might not be worth the trouble to backport them any further?]
2023-06-01 06:07:43 -04:00
/* deallocate common server parameters (may be used by default-servers) */
void srv_free_params(struct server *srv)
{
BUG/MINOR: server: free PROXY v2 TLVs on srv drop Dynamically allocated servers PROXY TLVs were not freed on server release. This patch fixes this leak by extending srv_free_params(). Every server line with set-proxy-v2-tlv-fmt keyword is impacted. For static servers, issue is minimal as it will only cause leak on deinit(). However, this could be aggravated when performing multiple removal of dynamic servers. This should be backported up to 2.9.
2024-05-21 05:00:37 -04:00
struct srv_pp_tlv_list *srv_tlv = NULL;
BUG/MINOR: proxy/server: free default-server on deinit proxy default-server is a specific type of server that is not allocated using new_server(): it is directly stored within the parent proxy structure. However, since it may contain some default config options that may be inherited by regular servers, it is also subject to dynamic members (strings, structures..) that needs to be deallocated when the parent proxy is cleaned up. Unfortunately, srv_drop() may not be used directly from p->defsrv since this function is meant to be used on regular servers only (those created using new_server()). To circumvent this, we're splitting srv_drop() to make a new function called srv_free_params() that takes care of the member cleaning which originally takes place in srv_drop(). This function is exposed through server.h, so it may be called from outside server.c. Thanks to this, calling srv_free_params(&p->defsrv) from free_proxy() prevents any memory leaks due to dynamic parameters allocated when parsing a default-server line from a proxy section. This partially fixes GH #2173 and may be backported to 2.8. [While it could also be relevant for other stable versions, the patch won't apply due to architectural changes / name changes between 2.4 => 2.6 and then 2.6 => 2.8. Considering this is a minor fix that only makes memory analyzers happy during deinit paths (at least for <= 2.8), it might not be worth the trouble to backport them any further?]
2023-06-01 06:07:43 -04:00
free(srv->cookie);
BUG/MINOR: server: add missing free for server->rdr_pfx rdr_pfx was not being free during server cleanup, leading to small memory leak when "redir" argument was used on a server line (HTTP only). This should be backported to every stable versions. [For 2.6 and 2.7: the free should be performed in srv_drop() directly. For older versions: free in deinit() function near the free for the cookie string]
2023-09-14 18:42:55 -04:00
free(srv->rdr_pfx);
BUG/MINOR: proxy/server: free default-server on deinit proxy default-server is a specific type of server that is not allocated using new_server(): it is directly stored within the parent proxy structure. However, since it may contain some default config options that may be inherited by regular servers, it is also subject to dynamic members (strings, structures..) that needs to be deallocated when the parent proxy is cleaned up. Unfortunately, srv_drop() may not be used directly from p->defsrv since this function is meant to be used on regular servers only (those created using new_server()). To circumvent this, we're splitting srv_drop() to make a new function called srv_free_params() that takes care of the member cleaning which originally takes place in srv_drop(). This function is exposed through server.h, so it may be called from outside server.c. Thanks to this, calling srv_free_params(&p->defsrv) from free_proxy() prevents any memory leaks due to dynamic parameters allocated when parsing a default-server line from a proxy section. This partially fixes GH #2173 and may be backported to 2.8. [While it could also be relevant for other stable versions, the patch won't apply due to architectural changes / name changes between 2.4 => 2.6 and then 2.6 => 2.8. Considering this is a minor fix that only makes memory analyzers happy during deinit paths (at least for <= 2.8), it might not be worth the trouble to backport them any further?]
2023-06-01 06:07:43 -04:00
free(srv->hostname);
free(srv->hostname_dn);
free((char*)srv->conf.file);
OPTIM: server: start to use aligned allocs in server This is currently for per-thread arrays like idle conns etc. We're now cache-aligning the per-thread arrays so as to put an end to false sharing. A comparative test between no alignment and alignment on a simple config with round robin between 4 servers showed an average rate of 1.75M/s vs 1.72M/s before for 100M requests. The gain seems to be more commonly less than 1% however. This should mostly help make measurements more reproducible across multiple runs.
2025-08-11 11:43:51 -04:00
ha_aligned_free(srv->per_thr);
ha_aligned_free(srv->per_tgrp);
ha_aligned_free(srv->curr_idle_thr);
MINOR: server: define pool-conn-name keyword Define a new server keyword pool-conn-name. The purpose of this keyword will be to identify connections inside the idle connections pool, replacing SNI in case SSL is not wanted. This keyword uses a sample expression argument. It thus can reuse existing function parse_srv_expr() for parsing. In the future, it may be necessary to define a keyword variant which uses a logformat for extensability. This patch only implement parsing. Argument is stored inside new server field <pool_conn_name> and expression is generated in _srv_parse_finalize() into <pool_conn_name_expr>. If pool-conn-name is not set but SNI is, the latter is reused automatically as pool-conn-name via _srv_parse_finalize(). This ensures current reuse behavior remains compatible and idle connection reuse will not mix connections with different SNIs by mistake. Main usage will be for rhttp when SSL is not wanted between the two haproxy instances. Previously, it was possible to use "sni" keyword even without SSL on a server line which have a similar effect. However, having a dedicated "pool-conn-name" keyword is deemed clearer. Besides, it would allow for more complex configuration where pool-conn-name and SNI are use in parallel with different values.
2024-05-23 05:14:13 -04:00
free(srv->pool_conn_name);
release_sample_expr(srv->pool_conn_name_expr);
BUG/MINOR: proxy/server: free default-server on deinit proxy default-server is a specific type of server that is not allocated using new_server(): it is directly stored within the parent proxy structure. However, since it may contain some default config options that may be inherited by regular servers, it is also subject to dynamic members (strings, structures..) that needs to be deallocated when the parent proxy is cleaned up. Unfortunately, srv_drop() may not be used directly from p->defsrv since this function is meant to be used on regular servers only (those created using new_server()). To circumvent this, we're splitting srv_drop() to make a new function called srv_free_params() that takes care of the member cleaning which originally takes place in srv_drop(). This function is exposed through server.h, so it may be called from outside server.c. Thanks to this, calling srv_free_params(&p->defsrv) from free_proxy() prevents any memory leaks due to dynamic parameters allocated when parsing a default-server line from a proxy section. This partially fixes GH #2173 and may be backported to 2.8. [While it could also be relevant for other stable versions, the patch won't apply due to architectural changes / name changes between 2.4 => 2.6 and then 2.6 => 2.8. Considering this is a minor fix that only makes memory analyzers happy during deinit paths (at least for <= 2.8), it might not be worth the trouble to backport them any further?]
2023-06-01 06:07:43 -04:00
free(srv->resolvers_id);
MINOR: server: add the "cc" keyword to set the TCP congestion controller It is possible on at least Linux and FreeBSD to set the congestion control algorithm to be used with outgoing connections, among the list of supported and permitted ones. Let's expose this setting with "cc". Unknown or forbidden algorithms will be ignored and the default one will continue to be used.
2025-09-17 11:15:12 -04:00
free(srv->cc_algo);
MINOR: proto-tcp: Add support for TCP MD5 signature for listeners and servers This patch adds the support for the RFC2385 (Protection of BGP Sessions via the + TCP MD5 Signature Option) for the listeners and the servers. The feature is only available on Linux. Keywords are not exposed otherwise. By setting "tcp-md5sig <password>" option on a bind line, TCP segments of all connections instantiated from the listening socket will be signed with a 16-byte MD5 digest. The same option can be set on a server line to protect outgoing connections to the corresponding server. The primary use case for this option is to allow BGP to protect itself against the introduction of spoofed TCP segments into the connection stream. But it can be useful for any very long-lived TCP connections. A reg-test was added and it will be executed only on linux. All other targets are excluded.
2025-07-03 09:16:47 -04:00
free(srv->tcp_md5sig);
MEDIUM: server: switch addr_node to cebis_tree This contains the text representation of the server's address, for use with stick-tables with "srvkey addr". Switching them to a compact node saves 24 more bytes from this structure. The key was moved to an external pointer "addr_key" right after the node. The server struct is now 3968 bytes (down from 4032) due to alignment, and the proxy struct shrinks by 8 bytes to 3152.
2025-07-07 09:13:15 -04:00
free(srv->addr_key);
MEDIUM: stats: avoid 1 indirection by storing the shared stats directly in counters struct Between 3.2 and 3.3-dev we noticed a noticeable performance regression due to stats handling. After bisecting, Willy found out that recent work to split stats computing accross multiple thread groups (stats sharding) was responsible for that performance regression. We're looking at roughly 20% performance loss. More precisely, it is the added indirections, multiplied by the number of statistics that are updated for each request, which in the end causes a significant amount of time being spent resolving pointers. We noticed that the fe_counters_shared and be_counters_shared structures which are currently allocated in dedicated memory since a0dcab5c ("MAJOR: counters: add shared counters base infrastructure") are no longer huge since 16eb0fab31 ("MAJOR: counters: dispatch counters over thread groups") because they now essentially hold flags plus the per-thread group id pointer mapping, not the counters themselves. As such we decided to try merging fe_counters_shared and be_counters_shared in their parent structures. The cost is slight memory overhead for the parent structure, but it allows to get rid of one pointer indirection. This patch alone yields visible performance gains and almost restores 3.2 stats performance. counters_fe_shared_get() was renamed to counters_fe_shared_prepare() and now returns either failure or success instead of a pointer because we don't need to retrieve a shared pointer anymore, the function takes care of initializing existing pointer.
2025-07-22 11:15:02 -04:00
counters_be_shared_drop(&srv->counters.shared);
MEDIUM: log/balance: support FQDN for UDP log servers In previous log backend implementation, we created a pseudo log target for each declared log server, and we made the log target's address point to the actual server address to save some time and prevent unecessary copies. But this was done without knowing that when FQDN is involved (more broadly when dns/resolution is involved), the "port" part of server addr should not be relied upon, and we should explicitly use ->svc_port for that purpose. With that in mind and thanks to the previous commit, some changes were required: we allocate a dedicated addr within the log target when target is in DGRAM mode. The addr is first initialized with known values and it is then updated automatically by _srv_set_inetaddr() during runtime. (the change is atomic so readers don't need to worry about it) addr from server "log target" (INET/DGRAM mode) is made of the combination of server's address (lacking the port part) and server's svc_port.
2023-11-09 10:57:01 -05:00
if (srv->log_target) {
deinit_log_target(srv->log_target);
free(srv->log_target);
}
BUG/MINOR: server: fix the "server-template" prefix memory leak The srv->tmpl_info.prefix was not freed in srv_free_params(). This could be backported to all stable versions.
2025-02-26 16:56:41 -05:00
free(srv->tmpl_info.prefix);
BUG/MINOR: proxy/server: free default-server on deinit proxy default-server is a specific type of server that is not allocated using new_server(): it is directly stored within the parent proxy structure. However, since it may contain some default config options that may be inherited by regular servers, it is also subject to dynamic members (strings, structures..) that needs to be deallocated when the parent proxy is cleaned up. Unfortunately, srv_drop() may not be used directly from p->defsrv since this function is meant to be used on regular servers only (those created using new_server()). To circumvent this, we're splitting srv_drop() to make a new function called srv_free_params() that takes care of the member cleaning which originally takes place in srv_drop(). This function is exposed through server.h, so it may be called from outside server.c. Thanks to this, calling srv_free_params(&p->defsrv) from free_proxy() prevents any memory leaks due to dynamic parameters allocated when parsing a default-server line from a proxy section. This partially fixes GH #2173 and may be backported to 2.8. [While it could also be relevant for other stable versions, the patch won't apply due to architectural changes / name changes between 2.4 => 2.6 and then 2.6 => 2.8. Considering this is a minor fix that only makes memory analyzers happy during deinit paths (at least for <= 2.8), it might not be worth the trouble to backport them any further?]
2023-06-01 06:07:43 -04:00
if (xprt_get(XPRT_SSL) && xprt_get(XPRT_SSL)->destroy_srv)
xprt_get(XPRT_SSL)->destroy_srv(srv);
MINOR: server: support QUIC for dynamic servers To properly support QUIC for dynamic servers, it is required to extend add server CLI handler : * ensure conformity between server address and proto * automatically set proto to QUIC if not specified * prepare_srv callback must be called to initialize required SSL context Prior to this patch, crashes may occur when trying to use QUIC with dynamic servers. Also, destroy_srv callback must be called when a dynamic server is deallocated. This ensures that there is no memory leak due to SSL context. No need to backport.
2025-07-07 05:42:25 -04:00
else if (xprt_get(XPRT_QUIC) && xprt_get(XPRT_QUIC)->destroy_srv)
xprt_get(XPRT_QUIC)->destroy_srv(srv);
BUG/MINOR: server: free PROXY v2 TLVs on srv drop Dynamically allocated servers PROXY TLVs were not freed on server release. This patch fixes this leak by extending srv_free_params(). Every server line with set-proxy-v2-tlv-fmt keyword is impacted. For static servers, issue is minimal as it will only cause leak on deinit(). However, this could be aggravated when performing multiple removal of dynamic servers. This should be backported up to 2.9.
2024-05-21 05:00:37 -04:00
while (!LIST_ISEMPTY(&srv->pp_tlvs)) {
srv_tlv = LIST_ELEM(srv->pp_tlvs.n, struct srv_pp_tlv_list *, list);
LIST_DEL_INIT(&srv_tlv->list);
lf_expr_deinit(&srv_tlv->fmt);
ha_free(&srv_tlv->fmt_string);
ha_free(&srv_tlv);
}
BUG/MINOR: proxy/server: free default-server on deinit proxy default-server is a specific type of server that is not allocated using new_server(): it is directly stored within the parent proxy structure. However, since it may contain some default config options that may be inherited by regular servers, it is also subject to dynamic members (strings, structures..) that needs to be deallocated when the parent proxy is cleaned up. Unfortunately, srv_drop() may not be used directly from p->defsrv since this function is meant to be used on regular servers only (those created using new_server()). To circumvent this, we're splitting srv_drop() to make a new function called srv_free_params() that takes care of the member cleaning which originally takes place in srv_drop(). This function is exposed through server.h, so it may be called from outside server.c. Thanks to this, calling srv_free_params(&p->defsrv) from free_proxy() prevents any memory leaks due to dynamic parameters allocated when parsing a default-server line from a proxy section. This partially fixes GH #2173 and may be backported to 2.8. [While it could also be relevant for other stable versions, the patch won't apply due to architectural changes / name changes between 2.4 => 2.6 and then 2.6 => 2.8. Considering this is a minor fix that only makes memory analyzers happy during deinit paths (at least for <= 2.8), it might not be worth the trouble to backport them any further?]
2023-06-01 06:07:43 -04:00
}
BUG/MINOR: server: do not use refcount in free_server in stopping mode Currently there is a leak at process shutdown with dynamic servers with check/agent-check activated. Check purges are not executed on process stopping, so the server is not liberated due to its refcount. The solution is simply to ignore the refcount on process stopping mode and free the server on the first free_server invocation. This should not be backported, unless dynamic server checks are backported. In this case, the following commit must be backported first. 7afa5c1843521ec3be7549592d2b38ccc9d68b73 MINOR: global: define MODE_STOPPING
2021-08-09 09:08:54 -04:00
/* Deallocate a server <srv> and its member. <srv> must be allocated. For
* dynamic servers, its refcount is decremented first. The free operations are
MINOR: server: correctly free servers on deinit() srv_drop() function is reponsible for freeing the server when the refcount reaches 0. There is one exception: when global.mode has the MODE_STOPPING flag set, srv_drop() will ignore the refcount and free the server on first invocation. This logic has been implemented with 13f2e2ce ("BUG/MINOR: server: do not use refcount in free_server in stopping mode") and back then doing so was not a problem since dynamic server API was just implemented and srv_take() and srv_drop() were not widely used. Now that dynamic server API is starting to get more popular we cannot afford to keep the current logic: some modules or lua scripts may hold references to existing server and also do their cleanup in deinit phases In this kind of situation, it would be easy to trigger double-frees since every call to srv_drop() on a specific server will try to free it. To fix this, we take a different approach and try to fix the issue at the source: we now properly drop server references involved with checks/agent_checks in deinit_srv_check() and deinit_srv_agent_check(). While this could theorically be backported up to 2.6, it is not very relevant for now since srv_drop() usage in older versions is very limited and we're only starting to face the issue in mid 2.8 developments. (ie: lua core updates)
2023-03-09 05:56:14 -05:00
* conducted only if the refcount is nul.
MINOR: server: return the next srv instance on free_server As a convenience, return the next server instance from servers list on free_server. This is particularily useful when using this function on the servers list without having to save of the next pointer before calling it.
2021-08-25 09:03:46 -04:00
*
BUG/MINOR: server: dont depend on proxy for server cleanup in srv_drop() In commit b5ee8bebfc ("MINOR: server: always call ssl->destroy_srv when available"), we made it so srv_drop() doesn't depend on proxy to perform server cleanup. It turns out this is now mandatory, because during deinit, free_proxy() can occur before the final srv_drop(). This is the case when using Lua scripts for instance. In 2a9436f96 ("MINOR: lbprm: Add method to deinit server and proxy") we added a freeing check under srv_drop() that depends on the proxy. Because of that UAF may occur during deinit when using a Lua script that manipulate server objects. To fix the issue, let's perform the lbprm server deinit logic under free_proxy() directly, where the DEINIT server hooks are evaluated. Also, to prevent similar bugs in the future, let's explicitly document in srv_drop() that server cleanups should assume that the proxy may already be freed. No backport needed unless 2a9436f96 is.
2025-05-12 10:09:15 -04:00
* A general rule is to assume that proxy may already be freed, so cleanup checks
* must not depend on the proxy
*
MINOR: server: return the next srv instance on free_server As a convenience, return the next server instance from servers list on free_server. This is particularily useful when using this function on the servers list without having to save of the next pointer before calling it.
2021-08-25 09:03:46 -04:00
* As a convenience, <srv.next> is returned if srv is not NULL. It may be useful
MEDIUM: server: extend refcount for all servers In a future patch, it will be possible to remove at runtime every servers, both static and dynamic. This requires to extend the server refcount for all instances. First, refcount manipulation functions have been renamed to better express the API usage. * srv_refcount_use -> srv_take The refcount is always initialize to 1 on the server creation in new_server. It's also incremented for each check/agent configured on a server instance. * free_server -> srv_drop This decrements the refcount and if null, the server is freed, so code calling it must not use the server reference after it. As a bonus, this function now returns the next server instance. This is useful when calling on the server loop without having to save the next pointer before each invocation. In these functions, remove the checks that prevent refcount on non-dynamic servers. Each reference to "dynamic" in variable/function naming have been eliminated as well.
2021-08-25 09:34:53 -04:00
* when calling srv_drop on the list of servers.
REORG: server: add a free server function Create a new server function named free_server. It can be used to deallocate a server and its member.
2021-03-16 12:20:15 -04:00
*/
MEDIUM: server: extend refcount for all servers In a future patch, it will be possible to remove at runtime every servers, both static and dynamic. This requires to extend the server refcount for all instances. First, refcount manipulation functions have been renamed to better express the API usage. * srv_refcount_use -> srv_take The refcount is always initialize to 1 on the server creation in new_server. It's also incremented for each check/agent configured on a server instance. * free_server -> srv_drop This decrements the refcount and if null, the server is freed, so code calling it must not use the server reference after it. As a bonus, this function now returns the next server instance. This is useful when calling on the server loop without having to save the next pointer before each invocation. In these functions, remove the checks that prevent refcount on non-dynamic servers. Each reference to "dynamic" in variable/function naming have been eliminated as well.
2021-08-25 09:34:53 -04:00
struct server *srv_drop(struct server *srv)
REORG: server: add a free server function Create a new server function named free_server. It can be used to deallocate a server and its member.
2021-03-16 12:20:15 -04:00
{
MINOR: server: return the next srv instance on free_server As a convenience, return the next server instance from servers list on free_server. This is particularily useful when using this function on the servers list without having to save of the next pointer before calling it.
2021-08-25 09:03:46 -04:00
struct server *next = NULL;
MINOR: server: take proxy refcount when deleting a server When a server is deleted via "del server", increment refcount of its parent backend. This is necessary as the server is not referenced anymore in the backend, but can still access it via its own <proxy> member. Thus, backend removal must not happen until the complete purge of the server. The proxy refcount is released in srv_drop() if the flag SRV_F_DELETED is set, which indicates that "del server" was used. This operation is performed after the complete release of the server instance to ensure no access will be performed on the proxy via itself. The refcount must not be decremented if a server is freed without "del server" invokation. Another solution could be for servers to always increment the refcount. However, for now in haproxy refcount usage is limited, so the current approach is preferred. It should also ensure that if the refcount is still incremented, it may indicate that some servers are not completely purged themselves. Note that this patch may cause issues if "del backend" are used in parallel with LUA scripts referencing servers. Currently, any servers referenced by LUA must be released by its garbage collector to ensure it can be finally freed. However, it appeas that in some case the gc does not run for several minutes. At least this has been observed with Lua version 5.4.8. In the end, this will result in indefinitely blocking of "del backend" commands.
2026-01-06 10:28:36 -05:00
struct proxy *px = NULL;
BUG/MINOR: quic/server: free quic_retry_token on srv drop A recent patch has implemented caching of QUIC token received from a NEW_TOKEN frame into the server cache. This value is stored per thread into a <quic_retry_token> field. This field is an ist, first set to an empty string. Via qc_try_store_new_token(), it is reallocated to fit the size of the newly stored token. Prior to this patch, the field was never freed so this causes a memory leak. Fix this by using istfree() on <quic_retry_token> field during srv_drop(). No need to backport.
2025-11-24 08:25:14 -05:00
int i __maybe_unused;
MINOR: server: return the next srv instance on free_server As a convenience, return the next server instance from servers list on free_server. This is particularily useful when using this function on the servers list without having to save of the next pointer before calling it.
2021-08-25 09:03:46 -04:00
MINOR: server: check if srv is NULL in free_server() Check if srv is NULL before trying to do anything in free_server(), like most free()-like function do.
2021-08-20 04:10:15 -04:00
if (!srv)
MINOR: server: return the next srv instance on free_server As a convenience, return the next server instance from servers list on free_server. This is particularily useful when using this function on the servers list without having to save of the next pointer before calling it.
2021-08-25 09:03:46 -04:00
goto end;
next = srv->next;
MINOR: server: check if srv is NULL in free_server() Check if srv is NULL before trying to do anything in free_server(), like most free()-like function do.
2021-08-20 04:10:15 -04:00
MINOR: server: take proxy refcount when deleting a server When a server is deleted via "del server", increment refcount of its parent backend. This is necessary as the server is not referenced anymore in the backend, but can still access it via its own <proxy> member. Thus, backend removal must not happen until the complete purge of the server. The proxy refcount is released in srv_drop() if the flag SRV_F_DELETED is set, which indicates that "del server" was used. This operation is performed after the complete release of the server instance to ensure no access will be performed on the proxy via itself. The refcount must not be decremented if a server is freed without "del server" invokation. Another solution could be for servers to always increment the refcount. However, for now in haproxy refcount usage is limited, so the current approach is preferred. It should also ensure that if the refcount is still incremented, it may indicate that some servers are not completely purged themselves. Note that this patch may cause issues if "del backend" are used in parallel with LUA scripts referencing servers. Currently, any servers referenced by LUA must be released by its garbage collector to ensure it can be finally freed. However, it appeas that in some case the gc does not run for several minutes. At least this has been observed with Lua version 5.4.8. In the end, this will result in indefinitely blocking of "del backend" commands.
2026-01-06 10:28:36 -05:00
/* If srv was deleted, a proxy refcount must be dropped. */
if (srv->flags & SRV_F_DELETED)
px = srv->proxy;
MINOR: server: implement a refcount for dynamic servers It is necessary to have a refcount mechanism on dynamic servers to be able to enable check support. Indeed, when deleting a dynamic server with check activated, the check will be asynchronously removed. This is mandatory to properly free the check resources in a thread-safe manner. The server instance must be kept alive for this.
2021-08-02 09:50:00 -04:00
/* For dynamic servers, decrement the reference counter. Only free the
* server when reaching zero.
*/
MINOR: server: correctly free servers on deinit() srv_drop() function is reponsible for freeing the server when the refcount reaches 0. There is one exception: when global.mode has the MODE_STOPPING flag set, srv_drop() will ignore the refcount and free the server on first invocation. This logic has been implemented with 13f2e2ce ("BUG/MINOR: server: do not use refcount in free_server in stopping mode") and back then doing so was not a problem since dynamic server API was just implemented and srv_take() and srv_drop() were not widely used. Now that dynamic server API is starting to get more popular we cannot afford to keep the current logic: some modules or lua scripts may hold references to existing server and also do their cleanup in deinit phases In this kind of situation, it would be easy to trigger double-frees since every call to srv_drop() on a specific server will try to free it. To fix this, we take a different approach and try to fix the issue at the source: we now properly drop server references involved with checks/agent_checks in deinit_srv_check() and deinit_srv_agent_check(). While this could theorically be backported up to 2.6, it is not very relevant for now since srv_drop() usage in older versions is very limited and we're only starting to face the issue in mid 2.8 developments. (ie: lua core updates)
2023-03-09 05:56:14 -05:00
if (HA_ATOMIC_SUB_FETCH(&srv->refcount, 1))
goto end;
MINOR: server: implement a refcount for dynamic servers It is necessary to have a refcount mechanism on dynamic servers to be able to enable check support. Indeed, when deleting a dynamic server with check activated, the check will be asynchronously removed. This is mandatory to properly free the check resources in a thread-safe manner. The server instance must be kept alive for this.
2021-08-02 09:50:00 -04:00
BUG/MEDIUM: server: fix race on server_atomic_sync() The following patch fixes a race condition during server addr/port update : cd994407a9545a8d84e410dc0cc18c30966b70d8 BUG/MAJOR: server/addr: fix a race during server addr:svc_port updates The new update mechanism is implemented via an event update. It uses thread isolation to guarantee that no other thread is accessing server addr/port. Furthermore, to ensure server instance is not deleted just before the event handler, server instance is lookup via its ID in proxy tree. However, thread isolation is only entered after server lookup. This leaves a tiny race condition as the thread will be marked as harmless and a concurrent thread can delete the server in the meantime. This causes server_atomic_sync() to manipulated a deleted server instance to reinsert it in used_server_addr backend tree. This can cause a segfault during this operation or possibly on a future used_server_addr tree access. This issue was detected by criteo. Several backtraces were retrieved, each related to server addr_node insert or delete operation, either in srv_set_addr_desc(), or add/delete dynamic server handlers. To fix this, simply extend thread isolation section to start it before server lookup. This ensures that once retrieved the server cannot be deleted until its addr/port are updated. To ensure this issue won't happen anymore, a new BUG_ON() is added in srv_set_addr_desc(). Also note that ebpt_delete() is now called every time on delete handler as this is a safe idempotent operation. To reproduce these crashes, a script was executed to add then remove different servers every second. In parallel, the following CLI command was issued repeatdly without any delay to force multiple update on servers port : set server <srv> addr 0.0.0.0 port $((1024 + RANDOM % 1024)) This must be backported at least up to 3.0. If above mentionned patch has been selected for previous version, this commit must also be backported on them.
2024-07-02 12:14:57 -04:00
/* This BUG_ON() is invalid for now as server released on deinit will
* trigger it as they are not properly removed from their tree.
*/
MEDIUM: server: switch addr_node to cebis_tree This contains the text representation of the server's address, for use with stick-tables with "srvkey addr". Switching them to a compact node saves 24 more bytes from this structure. The key was moved to an external pointer "addr_key" right after the node. The server struct is now 3968 bytes (down from 4032) due to alignment, and the proxy struct shrinks by 8 bytes to 3152.
2025-07-07 09:13:15 -04:00
//BUG_ON(ceb_intree(&srv->addr_node) ||
BUG/MEDIUM: server: fix race on server_atomic_sync() The following patch fixes a race condition during server addr/port update : cd994407a9545a8d84e410dc0cc18c30966b70d8 BUG/MAJOR: server/addr: fix a race during server addr:svc_port updates The new update mechanism is implemented via an event update. It uses thread isolation to guarantee that no other thread is accessing server addr/port. Furthermore, to ensure server instance is not deleted just before the event handler, server instance is lookup via its ID in proxy tree. However, thread isolation is only entered after server lookup. This leaves a tiny race condition as the thread will be marked as harmless and a concurrent thread can delete the server in the meantime. This causes server_atomic_sync() to manipulated a deleted server instance to reinsert it in used_server_addr backend tree. This can cause a segfault during this operation or possibly on a future used_server_addr tree access. This issue was detected by criteo. Several backtraces were retrieved, each related to server addr_node insert or delete operation, either in srv_set_addr_desc(), or add/delete dynamic server handlers. To fix this, simply extend thread isolation section to start it before server lookup. This ensures that once retrieved the server cannot be deleted until its addr/port are updated. To ensure this issue won't happen anymore, a new BUG_ON() is added in srv_set_addr_desc(). Also note that ebpt_delete() is now called every time on delete handler as this is a safe idempotent operation. To reproduce these crashes, a script was executed to add then remove different servers every second. In parallel, the following CLI command was issued repeatdly without any delay to force multiple update on servers port : set server <srv> addr 0.0.0.0 port $((1024 + RANDOM % 1024)) This must be backported at least up to 3.0. If above mentionned patch has been selected for previous version, this commit must also be backported on them.
2024-07-02 12:14:57 -04:00
// srv->idle_node.node.leaf_p ||
// srv->conf.id.node.leaf_p ||
MEDIUM: server: switch conf.name to cebis_tree This is used to index the server name and it contains a copy of the pointer to the server's name in <id>. Changing that for a ceb_node placed just before <id> saves 32 bytes to the struct server, which remains 3968 bytes large due to alignment. The proxy struct shrinks by 8 bytes to 3144. It's worth noting that the current way duplicate names are handled remains based on the previous mechanism where dups were permitted. Ideally we should now reject them during insertion and use unique key trees instead.
2025-07-07 09:33:40 -04:00
// ceb_intree(&srv->name_node));
BUG/MEDIUM: server: fix race on server_atomic_sync() The following patch fixes a race condition during server addr/port update : cd994407a9545a8d84e410dc0cc18c30966b70d8 BUG/MAJOR: server/addr: fix a race during server addr:svc_port updates The new update mechanism is implemented via an event update. It uses thread isolation to guarantee that no other thread is accessing server addr/port. Furthermore, to ensure server instance is not deleted just before the event handler, server instance is lookup via its ID in proxy tree. However, thread isolation is only entered after server lookup. This leaves a tiny race condition as the thread will be marked as harmless and a concurrent thread can delete the server in the meantime. This causes server_atomic_sync() to manipulated a deleted server instance to reinsert it in used_server_addr backend tree. This can cause a segfault during this operation or possibly on a future used_server_addr tree access. This issue was detected by criteo. Several backtraces were retrieved, each related to server addr_node insert or delete operation, either in srv_set_addr_desc(), or add/delete dynamic server handlers. To fix this, simply extend thread isolation section to start it before server lookup. This ensures that once retrieved the server cannot be deleted until its addr/port are updated. To ensure this issue won't happen anymore, a new BUG_ON() is added in srv_set_addr_desc(). Also note that ebpt_delete() is now called every time on delete handler as this is a safe idempotent operation. To reproduce these crashes, a script was executed to add then remove different servers every second. In parallel, the following CLI command was issued repeatdly without any delay to force multiple update on servers port : set server <srv> addr 0.0.0.0 port $((1024 + RANDOM % 1024)) This must be backported at least up to 3.0. If above mentionned patch has been selected for previous version, this commit must also be backported on them.
2024-07-02 12:14:57 -04:00
MINOR: server: implement GUID support This commit is similar to previous one, except that it implements GUID support for server instances. A guid_node field is inserted into server structure. A new "guid" server keyword is defined.
2024-03-26 10:01:35 -04:00
guid_remove(&srv->guid);
MEDIUM: server: allocate a tasklet for asyncronous requeuing This creates a tasklet that only expects to be called when the LB algorithm is under contention when trying to reposition the server in its tree. Indeed, that's one of the operations that usually requires to take a write lock on a highly contended area, often for very little benefits under contention; indeed, under load, if a server keeps its previous position for a few extra microseconds, usually there's no harm. Thus this new tasklet can be woken up by the LB algo to ask the server to later call lbprm.server_requeue(). It does nothing else.
2025-02-11 11:18:36 -05:00
if (srv->requeue_tasklet)
tasklet_kill(srv->requeue_tasklet);
REORG: server: add a free server function Create a new server function named free_server. It can be used to deallocate a server and its member.
2021-03-16 12:20:15 -04:00
task_destroy(srv->warmup);
BUG/MEDIUM: resolvers: Add a task on servers to check SRV resolution status When a server relies on a SRV resolution, a task is created to clean it up (fqdn/port and address) when the SRV resolution is considered as outdated (based on the resolvers 'timeout' value). It is only possible if the server inherits outdated info from a state file and is no longer selected to be attached to a SRV item. Note that most of time, a server is attached to a SRV item. Thus when the item becomes obsolete, the server is cleaned up. It is important to have such task to be sure the server will be free again to have a chance to be resolved again with fresh information. Of course, this patch is a workaround to solve a design issue. But there is no other obvious way to fix it without rewritting all the resolvers part. And it must be backportable. This patch relies on following commits: * MINOR: resolvers: Clean server in a dedicated function when removing a SRV item * MINOR: resolvers: Remove server from named_servers tree when removing a SRV item All the series must be backported as far as 2.2 after some observation period. Backports to 2.0 and 1.8 must be evaluated.
2021-06-15 10:17:17 -04:00
task_destroy(srv->srvrq_check);
REORG: server: add a free server function Create a new server function named free_server. It can be used to deallocate a server and its member.
2021-03-16 12:20:15 -04:00
free(srv->id);
BUG/MINOR: quic/server: free quic_retry_token on srv drop A recent patch has implemented caching of QUIC token received from a NEW_TOKEN frame into the server cache. This value is stored per thread into a <quic_retry_token> field. This field is an ist, first set to an empty string. Via qc_try_store_new_token(), it is reallocated to fit the size of the newly stored token. Prior to this patch, the field was never freed so this causes a memory leak. Fix this by using istfree() on <quic_retry_token> field during srv_drop(). No need to backport.
2025-11-24 08:25:14 -05:00
#ifdef USE_QUIC
BUG/MINOR: server: fix srv_drop() crash on partially init srv A recent patch has introduced free operation for QUIC tokens stored in a server. These values are located in <per_thr> server array. However, a server instance may be released prior to its full initialization in case of a failure during "add server" CLI command. The mentionned patch would cause a srv_drop() crash due to an invalid usage of NULL <per_thr> member. Fix this by adding a check on <per_thr> prior to dereference it in srv_drop(). No need to backport.
2025-11-25 09:07:51 -05:00
if (srv->per_thr) {
for (i = 0; i < global.nbthread; i++)
istfree(&srv->per_thr[i].quic_retry_token);
}
BUG/MINOR: quic/server: free quic_retry_token on srv drop A recent patch has implemented caching of QUIC token received from a NEW_TOKEN frame into the server cache. This value is stored per thread into a <quic_retry_token> field. This field is an ist, first set to an empty string. Via qc_try_store_new_token(), it is reallocated to fit the size of the newly stored token. Prior to this patch, the field was never freed so this causes a memory leak. Fix this by using istfree() on <quic_retry_token> field during srv_drop(). No need to backport.
2025-11-24 08:25:14 -05:00
#endif
BUG/MINOR: call EXTRA_COUNTERS_FREE() before srv_free_params() in srv_drop() As seen with the last changes to counters allocation, the move of the counters storage to the thread group as operated in commit 04a9f86a85 ("MEDIUM: counters: add a dedicated storage for extra_counters in various structs") causes some random errors when using ASAN, because the extra counters are freed in srv_drop() after calling srv_free_params(), which is responsible for freeing the per-thread group storage. For the proxies however it's OK because free calls are made before the call to deinit_proxy() which frees the per_tgrp area. No backport is needed, this is purely 3.4-dev.
2026-02-26 11:18:41 -05:00
EXTRA_COUNTERS_FREE(srv->extra_counters);
BUG/MINOR: proxy/server: free default-server on deinit proxy default-server is a specific type of server that is not allocated using new_server(): it is directly stored within the parent proxy structure. However, since it may contain some default config options that may be inherited by regular servers, it is also subject to dynamic members (strings, structures..) that needs to be deallocated when the parent proxy is cleaned up. Unfortunately, srv_drop() may not be used directly from p->defsrv since this function is meant to be used on regular servers only (those created using new_server()). To circumvent this, we're splitting srv_drop() to make a new function called srv_free_params() that takes care of the member cleaning which originally takes place in srv_drop(). This function is exposed through server.h, so it may be called from outside server.c. Thanks to this, calling srv_free_params(&p->defsrv) from free_proxy() prevents any memory leaks due to dynamic parameters allocated when parsing a default-server line from a proxy section. This partially fixes GH #2173 and may be backported to 2.8. [While it could also be relevant for other stable versions, the patch won't apply due to architectural changes / name changes between 2.4 => 2.6 and then 2.6 => 2.8. Considering this is a minor fix that only makes memory analyzers happy during deinit paths (at least for <= 2.8), it might not be worth the trouble to backport them any further?]
2023-06-01 06:07:43 -04:00
srv_free_params(srv);
REORG: server: add a free server function Create a new server function named free_server. It can be used to deallocate a server and its member.
2021-03-16 12:20:15 -04:00
HA_SPIN_DESTROY(&srv->lock);
BUG/MEDIUM: server: fix race on servers_list during server deletion Each server is inserted in a global list named servers_list on new_server(). This list is then only used to finalize servers initialization after parsing. On dynamic server creation, there is no issue as new_server() is under thread isolation. However, when a server is deleted after its refcount reached zero, srv_drop() removes it from servers_list without lock protection. In the longterm, this can cause list corruption and crashes, especially if multiple adjacent servers are removed in parallel. To fix this, convert servers_list to a mt_list. This should not impact performance as servers_list is not used during runtime outside of server creation/deletion. This should fix github issue #2733. Thanks to Chris Staite who first found the issue here. This must be backported up to 2.6.
2024-10-23 12:18:48 -04:00
MT_LIST_DELETE(&srv->global_list);
MINOR: server/event_hdl: add support for SERVER_ADD and SERVER_DEL events Basic support for ADD and DEL server events are added through this commit: SERVER_ADD is published on dynamic server addition through cli. SERVER_DEL is published on dynamic server deletion through cli. This work depends on: "MINOR: event_hdl: add event handler base api" "MINOR: server: add srv->rid (revision id) value"
2022-11-17 04:37:58 -05:00
event_hdl_sub_list_destroy(&srv->e_subs);
REORG: server: add a free server function Create a new server function named free_server. It can be used to deallocate a server and its member.
2021-03-16 12:20:15 -04:00
MEDIUM: server: introduce srv_alloc()/srv_free() to alloc/free a server It happens that we free servers at various places in the code, both on error paths and at runtime thanks to the "server delete" feature. In order to switch to an aligned struct, we'll need to change the calloc() and free() calls. Let's first spot them and switch them to srv_alloc() and srv_free() instead of using calloc() and either free() or ha_free(). An easy trap to fall into is that some of them are default-server entries. The new srv_free() function also resets the pointer like ha_free() does. This was done by running the following coccinelle script all over the code: @@ struct server *srv; @@ ( - free(srv) + srv_free(&srv) | - ha_free(&srv) + srv_free(&srv) ) @@ struct server *srv; expression e1; expression e2; @@ ( - srv = malloc(e1) + srv = srv_alloc() | - srv = calloc(e1, e2) + srv = srv_alloc() ) This is marked medium because despite spotting all call places, we can never rule out the possibility that some out-of-tree patches would allocate their own servers and continue to use the old API... at their own risk.
2025-08-13 05:52:59 -04:00
srv_free(&srv);
MINOR: server: return the next srv instance on free_server As a convenience, return the next server instance from servers list on free_server. This is particularily useful when using this function on the servers list without having to save of the next pointer before calling it.
2021-08-25 09:03:46 -04:00
MINOR: server: take proxy refcount when deleting a server When a server is deleted via "del server", increment refcount of its parent backend. This is necessary as the server is not referenced anymore in the backend, but can still access it via its own <proxy> member. Thus, backend removal must not happen until the complete purge of the server. The proxy refcount is released in srv_drop() if the flag SRV_F_DELETED is set, which indicates that "del server" was used. This operation is performed after the complete release of the server instance to ensure no access will be performed on the proxy via itself. The refcount must not be decremented if a server is freed without "del server" invokation. Another solution could be for servers to always increment the refcount. However, for now in haproxy refcount usage is limited, so the current approach is preferred. It should also ensure that if the refcount is still incremented, it may indicate that some servers are not completely purged themselves. Note that this patch may cause issues if "del backend" are used in parallel with LUA scripts referencing servers. Currently, any servers referenced by LUA must be released by its garbage collector to ensure it can be finally freed. However, it appeas that in some case the gc does not run for several minutes. At least this has been observed with Lua version 5.4.8. In the end, this will result in indefinitely blocking of "del backend" commands.
2026-01-06 10:28:36 -05:00
proxy_drop(px);
MINOR: server: return the next srv instance on free_server As a convenience, return the next server instance from servers list on free_server. This is particularily useful when using this function on the servers list without having to save of the next pointer before calling it.
2021-08-25 09:03:46 -04:00
end:
return next;
REORG: server: add a free server function Create a new server function named free_server. It can be used to deallocate a server and its member.
2021-03-16 12:20:15 -04:00
}
MEDIUM: server: support track keyword for dynamic servers Allow the usage of the 'track' keyword for dynamic servers. On server deletion, the server is properly removed from the tracking chain to prevents NULL pointer dereferencing.
2021-07-13 04:36:03 -04:00
/* Remove a server <srv> from a tracking list if <srv> is tracking another
* server. No special care is taken if <srv> is tracked itself by another one :
* this situation should be avoided by the caller.
*
* Not thread-safe.
*/
static void release_server_track(struct server *srv)
{
struct server *strack = srv->track;
struct server **base;
if (!strack)
return;
for (base = &strack->trackers; *base; base = &((*base)->tracknext)) {
if (*base == srv) {
*base = srv->tracknext;
return;
}
}
/* srv not found on the tracking list, this should never happen */
BUG_ON(!*base);
}
MINOR: server: prepare parsing for dynamic servers Prepare the server parsing API to support dynamic servers. - define a new parsing flag to be used for dynamic servers - each keyword contains a new field dynamic_ok to indicate if it can be used for a dynamic server. For now, no keyword are supported. - do not copy settings from the default server for a new dynamic server. - a dynamic server is created in a maintenance mode and requires an explicit 'enable server' command. - a new server flag named SRV_F_DYNAMIC is created. This flag is set for all servers created at runtime. It might be useful later, for example to know if a server can be purged.
2021-03-08 11:08:01 -05:00
/*
* Parse as much as possible such a range string argument: low[-high]
* Set <nb_low> and <nb_high> values so that they may be reused by this loop
* for(int i = nb_low; i <= nb_high; i++)... with nb_low >= 1.
* Fails if 'low' < 0 or 'high' is present and not higher than 'low'.
* Returns 0 if succeeded, -1 if not.
MINOR: server: Add 'server-template' new keyword supported in backend sections. This patch makes backend sections support 'server-template' new keyword. Such 'server-template' objects are parsed similarly to a 'server' object by parse_server() function, but its first arguments are as follows: server-template <ID prefix> <nb | range> <ip | fqdn>:<port> ... The remaining arguments are the same as for 'server' lines. With such server template declarations, servers may be allocated with IDs built from <ID prefix> and <nb | range> arguments. For instance declaring: server-template foo 1-5 google.com:80 ... or server-template foo 5 google.com:80 ... would be equivalent to declare: server foo1 google.com:80 ... server foo2 google.com:80 ... server foo3 google.com:80 ... server foo4 google.com:80 ... server foo5 google.com:80 ...
2017-04-13 12:24:23 -04:00
*/
REORG: server: rename internal functions from parse_server Use a standard convention for the functions used through parse_server. Use the prefix _srv_parse and specify their private scope in a comment.
2021-03-17 09:25:39 -04:00
static int _srv_parse_tmpl_range(struct server *srv, const char *arg,
int *nb_low, int *nb_high)
MINOR: server: Add 'server-template' new keyword supported in backend sections. This patch makes backend sections support 'server-template' new keyword. Such 'server-template' objects are parsed similarly to a 'server' object by parse_server() function, but its first arguments are as follows: server-template <ID prefix> <nb | range> <ip | fqdn>:<port> ... The remaining arguments are the same as for 'server' lines. With such server template declarations, servers may be allocated with IDs built from <ID prefix> and <nb | range> arguments. For instance declaring: server-template foo 1-5 google.com:80 ... or server-template foo 5 google.com:80 ... would be equivalent to declare: server foo1 google.com:80 ... server foo2 google.com:80 ... server foo3 google.com:80 ... server foo4 google.com:80 ... server foo5 google.com:80 ...
2017-04-13 12:24:23 -04:00
{
char *nb_high_arg;
*nb_high = 0;
chunk_printf(&trash, "%s", arg);
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
*nb_low = atoi(trash.area);
MINOR: server: Add 'server-template' new keyword supported in backend sections. This patch makes backend sections support 'server-template' new keyword. Such 'server-template' objects are parsed similarly to a 'server' object by parse_server() function, but its first arguments are as follows: server-template <ID prefix> <nb | range> <ip | fqdn>:<port> ... The remaining arguments are the same as for 'server' lines. With such server template declarations, servers may be allocated with IDs built from <ID prefix> and <nb | range> arguments. For instance declaring: server-template foo 1-5 google.com:80 ... or server-template foo 5 google.com:80 ... would be equivalent to declare: server foo1 google.com:80 ... server foo2 google.com:80 ... server foo3 google.com:80 ... server foo4 google.com:80 ... server foo5 google.com:80 ...
2017-04-13 12:24:23 -04:00
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
if ((nb_high_arg = strchr(trash.area, '-'))) {
MINOR: server: Add 'server-template' new keyword supported in backend sections. This patch makes backend sections support 'server-template' new keyword. Such 'server-template' objects are parsed similarly to a 'server' object by parse_server() function, but its first arguments are as follows: server-template <ID prefix> <nb | range> <ip | fqdn>:<port> ... The remaining arguments are the same as for 'server' lines. With such server template declarations, servers may be allocated with IDs built from <ID prefix> and <nb | range> arguments. For instance declaring: server-template foo 1-5 google.com:80 ... or server-template foo 5 google.com:80 ... would be equivalent to declare: server foo1 google.com:80 ... server foo2 google.com:80 ... server foo3 google.com:80 ... server foo4 google.com:80 ... server foo5 google.com:80 ...
2017-04-13 12:24:23 -04:00
*nb_high_arg++ = '\0';
*nb_high = atoi(nb_high_arg);
}
else {
*nb_high += *nb_low;
*nb_low = 1;
}
if (*nb_low < 0 || *nb_high < *nb_low)
return -1;
return 0;
}
REORG: server: rename internal functions from parse_server Use a standard convention for the functions used through parse_server. Use the prefix _srv_parse and specify their private scope in a comment.
2021-03-17 09:25:39 -04:00
/* Parse as much as possible such a range string argument: low[-high]
* Set <nb_low> and <nb_high> values so that they may be reused by this loop
* for(int i = nb_low; i <= nb_high; i++)... with nb_low >= 1.
*
CLEANUP: assorted typo fixes in the code and comments This is 21st iteration of typo fixes
2021-03-19 13:21:44 -04:00
* This function is first intended to be used through parse_server to
REORG: server: rename internal functions from parse_server Use a standard convention for the functions used through parse_server. Use the prefix _srv_parse and specify their private scope in a comment.
2021-03-17 09:25:39 -04:00
* initialize a new server on startup.
*
* Fails if 'low' < 0 or 'high' is present and not higher than 'low'.
* Returns 0 if succeeded, -1 if not.
*/
static inline void _srv_parse_set_id_from_prefix(struct server *srv,
const char *prefix, int nb)
MINOR: server: Add server_template_init() function to initialize servers from a templates. This patch adds server_template_init() function used to initialize servers from server templates. It is called just after having parsed a 'server-template' line.
2017-04-14 07:28:00 -04:00
{
chunk_printf(&trash, "%s%d", prefix, nb);
free(srv->id);
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
srv->id = strdup(trash.area);
MINOR: server: Add server_template_init() function to initialize servers from a templates. This patch adds server_template_init() function used to initialize servers from server templates. It is called just after having parsed a 'server-template' line.
2017-04-14 07:28:00 -04:00
}
MINOR: server: Parse sni and pool-conn-name expressions in a dedicated function This change is mandatory to fix an issue. The parsing of sni and pool-conn-name expressions (from string to expression) is now handled in a dedicated function. This will avoid to duplicate the same code at different places.
2025-09-03 08:45:07 -04:00
/* Parse the sni and pool-conn-name expressions. Returns 0 on success and non-zero on
* error. */
MEDIUM: server/ssl: Base the SNI value to the HTTP host header by default For HTTPS outgoing connections, the SNI is now automatically set using the Host header value if no other value is already set (via the "sni" server keyword). It is now the default behavior. It could be disabled with the "no-sni-auto" server keyword. And eventually "sni-auto" server keyword may be used to reset any previous "no-sni-auto" setting. This option can be inherited from "default-server" settings. Finally, if no connection name is set via "pool-conn-name" setting, the selected value is used. The automatic selection of the SNI is enabled by default for all outgoing connections. But it is concretely used for HTTPS connections only. The expression used is "req.hdr(host),host_only". This patch should paritally fix the issue #3081. It only covers the server part. Another patch will add the feature for HTTP health-checks.
2025-09-04 04:12:19 -04:00
int server_parse_exprs(struct server *srv, struct proxy *px, char **errmsg)
MINOR: server: Parse sni and pool-conn-name expressions in a dedicated function This change is mandatory to fix an issue. The parsing of sni and pool-conn-name expressions (from string to expression) is now handled in a dedicated function. This will avoid to duplicate the same code at different places.
2025-09-03 08:45:07 -04:00
{
int ret = 0;
BUG/MEDIUM: server: Use sni as pool connection name for SSL server only By default, for a given server, when no pool-conn-name is specified, the configured sni is used. However, this must only be done when SSL is in-use for the server. Of course, it is uncommon to have a sni expression for now-ssl server. But this may happen. In addition, the SSL may be disabled via the CLI. In that case, the pool-conn-name must be discarded if it was copied from the sni. And, we must of course take care to set it if the ssl is enabled. Finally, when the attac-srv action is checked, we now checked the pool-conn-name expression. This patch should be backported as far as 3.0. It relies on "MINOR: server: Parse sni and pool-conn-name expressions in a dedicated function" which should be backported too.
2025-09-03 09:29:56 -04:00
if (srv->use_ssl == 1) {
/* Use sni as fallback if pool_conn_name isn't set, but only if
* the server is configured to use SSL */
if (!srv->pool_conn_name && srv->sni_expr) {
srv->pool_conn_name = strdup(srv->sni_expr);
if (!srv->pool_conn_name) {
memprintf(errmsg, "cannot duplicate sni expression (out of memory)");
ret = ERR_ALERT | ERR_FATAL;
goto out;
}
MINOR: server: Parse sni and pool-conn-name expressions in a dedicated function This change is mandatory to fix an issue. The parsing of sni and pool-conn-name expressions (from string to expression) is now handled in a dedicated function. This will avoid to duplicate the same code at different places.
2025-09-03 08:45:07 -04:00
}
}
BUG/MEDIUM: server: Use sni as pool connection name for SSL server only By default, for a given server, when no pool-conn-name is specified, the configured sni is used. However, this must only be done when SSL is in-use for the server. Of course, it is uncommon to have a sni expression for now-ssl server. But this may happen. In addition, the SSL may be disabled via the CLI. In that case, the pool-conn-name must be discarded if it was copied from the sni. And, we must of course take care to set it if the ssl is enabled. Finally, when the attac-srv action is checked, we now checked the pool-conn-name expression. This patch should be backported as far as 3.0. It relies on "MINOR: server: Parse sni and pool-conn-name expressions in a dedicated function" which should be backported too.
2025-09-03 09:29:56 -04:00
if (srv->sni_expr && !srv->ssl_ctx.sni) {
MINOR: server: Parse sni and pool-conn-name expressions in a dedicated function This change is mandatory to fix an issue. The parsing of sni and pool-conn-name expressions (from string to expression) is now handled in a dedicated function. This will avoid to duplicate the same code at different places.
2025-09-03 08:45:07 -04:00
ret = parse_srv_expr(srv->sni_expr, &srv->ssl_ctx.sni, px, errmsg);
if (ret)
goto out;
}
BUG/MEDIUM: server: Use sni as pool connection name for SSL server only By default, for a given server, when no pool-conn-name is specified, the configured sni is used. However, this must only be done when SSL is in-use for the server. Of course, it is uncommon to have a sni expression for now-ssl server. But this may happen. In addition, the SSL may be disabled via the CLI. In that case, the pool-conn-name must be discarded if it was copied from the sni. And, we must of course take care to set it if the ssl is enabled. Finally, when the attac-srv action is checked, we now checked the pool-conn-name expression. This patch should be backported as far as 3.0. It relies on "MINOR: server: Parse sni and pool-conn-name expressions in a dedicated function" which should be backported too.
2025-09-03 09:29:56 -04:00
if (srv->pool_conn_name && !srv->pool_conn_name_expr) {
MINOR: server: Parse sni and pool-conn-name expressions in a dedicated function This change is mandatory to fix an issue. The parsing of sni and pool-conn-name expressions (from string to expression) is now handled in a dedicated function. This will avoid to duplicate the same code at different places.
2025-09-03 08:45:07 -04:00
ret = parse_srv_expr(srv->pool_conn_name, &srv->pool_conn_name_expr, px, errmsg);
if (ret)
goto out;
}
out:
return ret;
}
BUG/MINOR: server: set auto SNI for dynamic servers Auto SNI configuration is configured during check config validity. However, nothing was implemented for dynamic servers. Fix this by implementing auto SNI configuration during "add server" CLI handler. Auto SNI configuration code is moved in a dedicated function srv_configure_auto_sni() called both for static and dynamic servers. Along with this, allows the keyword "no-sni-auto" on dynamic servers, so that this process can be deactivated if wanted. Note that "sni-auto" remains unavailable as it only makes sense with default-servers which are never used for dynamic server creation. This must be backported up to 3.3.
2026-02-19 10:31:25 -05:00
/* Fill <srv> SNI expression to reuse the host header on outgoing requests.
*
* Returns 0 on success else non-zero. On error, <err_code> and <err> message
* are both set.
*/
int srv_configure_auto_sni(struct server *srv, int *err_code, char **err)
{
srv->sni_expr = strdup("req.hdr(host),field(1,:)");
if (!srv->sni_expr) {
memprintf(err, "out of memory while generating server auto SNI expression");
*err_code |= ERR_ALERT | ERR_ABORT;
return 1;
}
if (server_parse_exprs(srv, srv->proxy, err)) {
memprintf(err, "failed to parse auto SNI expression: %s", *err);
*err_code |= ERR_ALERT | ERR_FATAL;
return 1;
}
return 0;
}
REORG: server: rename internal functions from parse_server Use a standard convention for the functions used through parse_server. Use the prefix _srv_parse and specify their private scope in a comment.
2021-03-17 09:25:39 -04:00
/* Initialize as much as possible servers from <srv> server template.
MINOR: server: Add server_template_init() function to initialize servers from a templates. This patch adds server_template_init() function used to initialize servers from server templates. It is called just after having parsed a 'server-template' line.
2017-04-14 07:28:00 -04:00
* Note that a server template is a special server with
* a few different parameters than a server which has
* been parsed mostly the same way as a server.
REORG: server: rename internal functions from parse_server Use a standard convention for the functions used through parse_server. Use the prefix _srv_parse and specify their private scope in a comment.
2021-03-17 09:25:39 -04:00
*
CLEANUP: assorted typo fixes in the code and comments This is 21st iteration of typo fixes
2021-03-19 13:21:44 -04:00
* This function is first intended to be used through parse_server to
REORG: server: rename internal functions from parse_server Use a standard convention for the functions used through parse_server. Use the prefix _srv_parse and specify their private scope in a comment.
2021-03-17 09:25:39 -04:00
* initialize a new server on startup.
*
CLEANUP: fix a few typos in the comments of the server subsystem A few misspells where detected in the server subsystem. This commit fixes them.
2018-11-15 11:57:51 -05:00
* Returns the number of servers successfully allocated,
MINOR: server: Add server_template_init() function to initialize servers from a templates. This patch adds server_template_init() function used to initialize servers from server templates. It is called just after having parsed a 'server-template' line.
2017-04-14 07:28:00 -04:00
* 'srv' template included.
*/
REORG: server: rename internal functions from parse_server Use a standard convention for the functions used through parse_server. Use the prefix _srv_parse and specify their private scope in a comment.
2021-03-17 09:25:39 -04:00
static int _srv_parse_tmpl_init(struct server *srv, struct proxy *px)
MINOR: server: Add server_template_init() function to initialize servers from a templates. This patch adds server_template_init() function used to initialize servers from server templates. It is called just after having parsed a 'server-template' line.
2017-04-14 07:28:00 -04:00
{
int i;
struct server *newsrv;
BUG/MINOR: server: fix first server template not being indexed 3.0-dev1 introduced a small regression with commit b4db3be86e ("BUG/MINOR: server: fix server_find_by_name() usage during parsing"). By changing the way servers are indexed and moving it into the server template loop, the first one is no longer indexed because the loop starts at low+1 since it focuses on duplication. Let's index the first one explicitly now. This should not be backported, unless the commit above is backported.
2024-03-12 03:16:16 -04:00
/* Set the first server's ID. */
_srv_parse_set_id_from_prefix(srv, srv->tmpl_info.prefix, srv->tmpl_info.nb_low);
MEDIUM: server: switch conf.name to cebis_tree This is used to index the server name and it contains a copy of the pointer to the server's name in <id>. Changing that for a ceb_node placed just before <id> saves 32 bytes to the struct server, which remains 3968 bytes large due to alignment. The proxy struct shrinks by 8 bytes to 3144. It's worth noting that the current way duplicate names are handled remains based on the previous mechanism where dups were permitted. Ideally we should now reject them during insertion and use unique key trees instead.
2025-07-07 09:33:40 -04:00
cebis_item_insert(&curproxy->conf.used_server_name, conf.name_node, id, srv);
BUG/MINOR: server: fix first server template not being indexed 3.0-dev1 introduced a small regression with commit b4db3be86e ("BUG/MINOR: server: fix server_find_by_name() usage during parsing"). By changing the way servers are indexed and moving it into the server template loop, the first one is no longer indexed because the loop starts at low+1 since it focuses on duplication. Let's index the first one explicitly now. This should not be backported, unless the commit above is backported.
2024-03-12 03:16:16 -04:00
/* then create other servers from this one */
MINOR: server: Add server_template_init() function to initialize servers from a templates. This patch adds server_template_init() function used to initialize servers from server templates. It is called just after having parsed a 'server-template' line.
2017-04-14 07:28:00 -04:00
for (i = srv->tmpl_info.nb_low + 1; i <= srv->tmpl_info.nb_high; i++) {
newsrv = new_server(px);
if (!newsrv)
goto err;
MINOR: server: Copy configuration file and line for server templates When servers based on server templates are initialized, the configuration file and line are now copied. This helps to emit understandable warning and alert messages. This patch may be backported if needed, as far as 1.8.
2020-11-02 16:04:55 -05:00
newsrv->conf.file = strdup(srv->conf.file);
newsrv->conf.line = srv->conf.line;
MINOR: server: Add server_template_init() function to initialize servers from a templates. This patch adds server_template_init() function used to initialize servers from server templates. It is called just after having parsed a 'server-template' line.
2017-04-14 07:28:00 -04:00
srv_settings_cpy(newsrv, srv, 1);
MAJOR/REORG: dns: DNS resolution task and requester queues This patch is a major upgrade of the internal run-time DNS resolver in HAProxy and it brings the following 2 main changes: 1. DNS resolution task Up to now, DNS resolution was triggered by the health check task. From now, DNS resolution task is autonomous. It is started by HAProxy right after the scheduler is available and it is woken either when a network IO occurs for one of its nameserver or when a timeout is matched. From now, this means we can enable DNS resolution for a server without enabling health checking. 2. Introduction of a dns_requester structure Up to now, DNS resolution was purposely made for resolving server hostnames. The idea, is to ensure that any HAProxy internal object should be able to trigger a DNS resolution. For this purpose, 2 things has to be done: - clean up the DNS code from the server structure (this was already quite clean actually) and clean up the server's callbacks from manipulating too much DNS resolution - create an agnostic structure which allows linking a DNS resolution and a requester of any type (using obj_type enum) 3. Manage requesters through queues Up to now, there was an uniq relationship between a resolution and it's owner (aka the requester now). It's a shame, because in some cases, multiple objects may share the same hostname and may benefit from a resolution being performed by a third party. This patch introduces the notion of queues, which are basically lists of either currently running resolution or waiting ones. The resolutions are now available as a pool, which belongs to the resolvers. The pool has has a default size of 64 resolutions per resolvers and is allocated at configuration parsing.
2017-05-22 09:17:15 -04:00
srv_prepare_for_resolution(newsrv, srv->hostname);
CLEANUP: server: always include the storage for SSL settings The SSL stuff in struct server takes less than 3% of it and requires lots of annoying ifdefs in the code just to take care of the cases where the field is absent. Let's get rid of this and stop including openssl-compat from server.c to detect NPN and ALPN capabilities. This reduces the total LoC by another 0.4%.
2021-10-06 08:48:37 -04:00
MEDIUM: server/ssl: Base the SNI value to the HTTP host header by default For HTTPS outgoing connections, the SNI is now automatically set using the Host header value if no other value is already set (via the "sni" server keyword). It is now the default behavior. It could be disabled with the "no-sni-auto" server keyword. And eventually "sni-auto" server keyword may be used to reset any previous "no-sni-auto" setting. This option can be inherited from "default-server" settings. Finally, if no connection name is set via "pool-conn-name" setting, the selected value is used. The automatic selection of the SNI is enabled by default for all outgoing connections. But it is concretely used for HTTPS connections only. The expression used is "req.hdr(host),host_only". This patch should paritally fix the issue #3081. It only covers the server part. Another patch will add the feature for HTTP health-checks.
2025-09-04 04:12:19 -04:00
if (server_parse_exprs(newsrv, px, NULL))
MINOR: server: Parse sni and pool-conn-name expressions in a dedicated function This change is mandatory to fix an issue. The parsing of sni and pool-conn-name expressions (from string to expression) is now handled in a dedicated function. This will avoid to duplicate the same code at different places.
2025-09-03 08:45:07 -04:00
goto err;
CLEANUP: server: always include the storage for SSL settings The SSL stuff in struct server takes less than 3% of it and requires lots of annoying ifdefs in the code just to take care of the cases where the field is absent. Let's get rid of this and stop including openssl-compat from server.c to detect NPN and ALPN capabilities. This reduces the total LoC by another 0.4%.
2021-10-06 08:48:37 -04:00
MEDIUM: resolvers: add a ref between servers and srv request or used SRV record This patch add a ref into servers to register them onto the record answer item used to set their hostnames. It also adds a head list into 'srvrq' to register servers free to be affected to a SRV record. A head of a tree is also added to srvrq to put servers which present a hotname in server state file. To re-link them fastly to the matching record as soon an item present the same name. This results in better performances on SRV record response parsing. This is an optimization but it could avoid to trigger the haproxy's internal wathdog in some circumstances. And for this reason it should be backported as far we can (2.0 ?)
2021-06-11 04:48:45 -04:00
/* append to list of servers available to receive an hostname */
BUG/MAJOR: resolvers: segfault using server template without SRV RECORDs This patch fix the issue adding a test in srvrq before registering the server on it during server template init. This was a regression due to commit : 3406766d57fc11478d54a6fa2d048cbfe4524a4e This should be backported with this previous commit (until 2.0)
2021-06-14 04:02:18 -04:00
if (newsrv->srvrq)
LIST_APPEND(&newsrv->srvrq->attached_servers, &newsrv->srv_rec_item);
MEDIUM: resolvers: add a ref between servers and srv request or used SRV record This patch add a ref into servers to register them onto the record answer item used to set their hostnames. It also adds a head list into 'srvrq' to register servers free to be affected to a SRV record. A head of a tree is also added to srvrq to put servers which present a hotname in server state file. To re-link them fastly to the matching record as soon an item present the same name. This results in better performances on SRV record response parsing. This is an optimization but it could avoid to trigger the haproxy's internal wathdog in some circumstances. And for this reason it should be backported as far we can (2.0 ?)
2021-06-11 04:48:45 -04:00
MINOR: server: Add server_template_init() function to initialize servers from a templates. This patch adds server_template_init() function used to initialize servers from server templates. It is called just after having parsed a 'server-template' line.
2017-04-14 07:28:00 -04:00
/* Set this new server ID. */
REORG: server: rename internal functions from parse_server Use a standard convention for the functions used through parse_server. Use the prefix _srv_parse and specify their private scope in a comment.
2021-03-17 09:25:39 -04:00
_srv_parse_set_id_from_prefix(newsrv, srv->tmpl_info.prefix, i);
MINOR: server: Add server_template_init() function to initialize servers from a templates. This patch adds server_template_init() function used to initialize servers from server templates. It is called just after having parsed a 'server-template' line.
2017-04-14 07:28:00 -04:00
MEDIUM: server: switch conf.name to cebis_tree This is used to index the server name and it contains a copy of the pointer to the server's name in <id>. Changing that for a ceb_node placed just before <id> saves 32 bytes to the struct server, which remains 3968 bytes large due to alignment. The proxy struct shrinks by 8 bytes to 3144. It's worth noting that the current way duplicate names are handled remains based on the previous mechanism where dups were permitted. Ideally we should now reject them during insertion and use unique key trees instead.
2025-07-07 09:33:40 -04:00
cebis_item_insert(&curproxy->conf.used_server_name, conf.name_node, id, newsrv);
MINOR: server: Add server_template_init() function to initialize servers from a templates. This patch adds server_template_init() function used to initialize servers from server templates. It is called just after having parsed a 'server-template' line.
2017-04-14 07:28:00 -04:00
}
return i - srv->tmpl_info.nb_low;
err:
if (newsrv) {
release_sample_expr(newsrv->ssl_ctx.sni);
free_check(&newsrv->agent);
free_check(&newsrv->check);
BUG/MEDIUM: server: fix race on servers_list during server deletion Each server is inserted in a global list named servers_list on new_server(). This list is then only used to finalize servers initialization after parsing. On dynamic server creation, there is no issue as new_server() is under thread isolation. However, when a server is deleted after its refcount reached zero, srv_drop() removes it from servers_list without lock protection. In the longterm, this can cause list corruption and crashes, especially if multiple adjacent servers are removed in parallel. To fix this, convert servers_list to a mt_list. This should not impact performance as servers_list is not used during runtime outside of server creation/deletion. This should fix github issue #2733. Thanks to Chris Staite who first found the issue here. This must be backported up to 2.6.
2024-10-23 12:18:48 -04:00
MT_LIST_DELETE(&newsrv->global_list);
BUG/MINOR: server: ensure server is detached from proxy list before being freed There remained some cases (on error paths) were a server could be freed while still attached on the parent proxy server list. In 3.3 this can be problematic because new_server() automatically adds the server to the parent proxy list. The bug is insignificant because it is on errors paths during init and often haproxy exits right after. But let's fix that to ensure no UAF or undefined behavior occurs because of that. This patch depends on ("MINOR: cli: use srv_drop() when server was created using new_server()") It must be backported in 3.3 with the above mentioned patch.
2026-01-13 13:15:07 -05:00
srv_detach(newsrv);
MINOR: server: Add server_template_init() function to initialize servers from a templates. This patch adds server_template_init() function used to initialize servers from server templates. It is called just after having parsed a 'server-template' line.
2017-04-14 07:28:00 -04:00
}
MINOR: cli: use srv_drop() when server was created using new_server() Now that new_server() is becoming more and more complex, we need to take care that servers created using new_server() must be released using the corresponding release function srv_drop() which takes care of properly de-initing the server and its members.
2026-01-13 13:37:54 -05:00
srv_drop(newsrv);
MINOR: server: Add server_template_init() function to initialize servers from a templates. This patch adds server_template_init() function used to initialize servers from server templates. It is called just after having parsed a 'server-template' line.
2017-04-14 07:28:00 -04:00
return i - srv->tmpl_info.nb_low;
}
BUG/MEDIUM: server/log: "mode log" after server keyword causes crash In 9a74a6c ("MAJOR: log: introduce log backends"), a mistake was made: it was assumed that the proxy mode was already known during server keyword parsing in parse_server() function, but this is wrong. Indeed, "mode log" can be declared late in the proxy section. Due to this, a simple config like this will cause the process to crash: |backend test | | server name 127.0.0.1:8080 | mode log In order to fix this, we relax some checks in _srv_parse_init() and store the address protocol from str2sa_range() in server struct, then we set-up a postparsing function that is to be called after config parsing to finish the server checks/initialization that depend on the proxy mode to be known. We achieve this by checking the PR_CAP_LB capability from the parent proxy to know if we're in such case where the effective proxy mode is not yet known (it is assumed that other proxies which are implicit ones don't provide this possibility and thus don't suffer from this constraint). Only then, if the capability is not found, we immediately perform the server checks that depend on the proxy mode, else the check is postponed and it will automatically be performed during postparsing thanks to the REGISTER_POST_SERVER_CHECK() hook. Note that we remove the SRV_PARSE_IN_LOG_BE flag because it was introduced in the above commit and it is no longer relevant. No backport needed unless 9a74a6c gets backported.
2023-10-19 04:59:26 -04:00
/* Ensure server config will work with effective proxy mode
*
* This function is expected to be called after _srv_parse_init() initialization
* but only when the effective server's proxy mode is known, which is not always
* the case during parsing time, in which case the function will be called during
MEDIUM: server: split srv_init() in srv_preinit() + srv_postinit() We actually need more granularity to split srv postparsing init tasks: Some of them are required to be run BEFORE the config is checked, and some of them AFTER the config is checked. Thus we push the logic from 368d0136 ("MEDIUM: server: add and use srv_init() function") a little bit further and split the function in two distinct ones, one of them executed under check_config_validity() and the other one using REGISTER_POST_SERVER_CHECK() hook. SRV_F_CHECKED flag was removed because it is no longer needed, srv_preinit() is only called once, and so is srv_postinit().
2025-08-08 06:22:13 -04:00
* postparsing thanks to the srv_postinit() below.
BUG/MEDIUM: server/log: "mode log" after server keyword causes crash In 9a74a6c ("MAJOR: log: introduce log backends"), a mistake was made: it was assumed that the proxy mode was already known during server keyword parsing in parse_server() function, but this is wrong. Indeed, "mode log" can be declared late in the proxy section. Due to this, a simple config like this will cause the process to crash: |backend test | | server name 127.0.0.1:8080 | mode log In order to fix this, we relax some checks in _srv_parse_init() and store the address protocol from str2sa_range() in server struct, then we set-up a postparsing function that is to be called after config parsing to finish the server checks/initialization that depend on the proxy mode to be known. We achieve this by checking the PR_CAP_LB capability from the parent proxy to know if we're in such case where the effective proxy mode is not yet known (it is assumed that other proxies which are implicit ones don't provide this possibility and thus don't suffer from this constraint). Only then, if the capability is not found, we immediately perform the server checks that depend on the proxy mode, else the check is postponed and it will automatically be performed during postparsing thanks to the REGISTER_POST_SERVER_CHECK() hook. Note that we remove the SRV_PARSE_IN_LOG_BE flag because it was introduced in the above commit and it is no longer relevant. No backport needed unless 9a74a6c gets backported.
2023-10-19 04:59:26 -04:00
*
* Returns ERR_NONE on success else a combination or ERR_CODE.
*/
static int _srv_check_proxy_mode(struct server *srv, char postparse)
{
int err_code = ERR_NONE;
if (postparse && !(srv->proxy->cap & PR_CAP_LB))
return ERR_NONE; /* nothing to do, the check was already performed during parsing */
if (srv->conf.file)
set_usermsgs_ctx(srv->conf.file, srv->conf.line, NULL);
BUG/MEDIUM: server: invalid address (post)parsing checks This bug was introduced with 29b76ca ("BUG/MEDIUM: server/log: "mode log" after server keyword causes crash ") Indeed, we cannot safely rely on addr_proto being set when str2sa_range() returns in parse_server() (even if SRV_PARSE_PARSE_ADDR is set), because proto lookup might be bypassed when FQDN addresses are involved. Unfortunately, the above patch wrongly assumed that proto would always be set when SRV_PARSE_PARSE_ADDR was passed to parse_server() (so when str2sa_range() was called), resulting in invalid postparsing checks being performed, which could as well lead to crashes with log backends ("mode log" set) because some postparsing init was skipped as a result of proto not being set and this wasn't expected later in the init code. To fix this, we now make use of the previous patch to perform server's address compatibility checks on hints that are always set when str2sa_range() succesfully returns. For log backend, we're also adding a complementary test to check if the address family is of expected type, else we report an error, plus we're moving the postinit logic in log api since _srv_check_proxy_mode() is only meant to check proxy mode compatibility and we were abusing it. This patch depends on: - "MINOR: tools: make str2sa_range() directly return type hints" No backport required unless 29b76ca gets backported.
2023-11-09 07:45:03 -05:00
if (!srv->proxy) {
/* proxy mode not known, cannot perform checks (ie: defaults section) */
BUG/MEDIUM: server/log: "mode log" after server keyword causes crash In 9a74a6c ("MAJOR: log: introduce log backends"), a mistake was made: it was assumed that the proxy mode was already known during server keyword parsing in parse_server() function, but this is wrong. Indeed, "mode log" can be declared late in the proxy section. Due to this, a simple config like this will cause the process to crash: |backend test | | server name 127.0.0.1:8080 | mode log In order to fix this, we relax some checks in _srv_parse_init() and store the address protocol from str2sa_range() in server struct, then we set-up a postparsing function that is to be called after config parsing to finish the server checks/initialization that depend on the proxy mode to be known. We achieve this by checking the PR_CAP_LB capability from the parent proxy to know if we're in such case where the effective proxy mode is not yet known (it is assumed that other proxies which are implicit ones don't provide this possibility and thus don't suffer from this constraint). Only then, if the capability is not found, we immediately perform the server checks that depend on the proxy mode, else the check is postponed and it will automatically be performed during postparsing thanks to the REGISTER_POST_SERVER_CHECK() hook. Note that we remove the SRV_PARSE_IN_LOG_BE flag because it was introduced in the above commit and it is no longer relevant. No backport needed unless 9a74a6c gets backported.
2023-10-19 04:59:26 -04:00
goto out;
}
BUG/MEDIUM: server: invalid address (post)parsing checks This bug was introduced with 29b76ca ("BUG/MEDIUM: server/log: "mode log" after server keyword causes crash ") Indeed, we cannot safely rely on addr_proto being set when str2sa_range() returns in parse_server() (even if SRV_PARSE_PARSE_ADDR is set), because proto lookup might be bypassed when FQDN addresses are involved. Unfortunately, the above patch wrongly assumed that proto would always be set when SRV_PARSE_PARSE_ADDR was passed to parse_server() (so when str2sa_range() was called), resulting in invalid postparsing checks being performed, which could as well lead to crashes with log backends ("mode log" set) because some postparsing init was skipped as a result of proto not being set and this wasn't expected later in the init code. To fix this, we now make use of the previous patch to perform server's address compatibility checks on hints that are always set when str2sa_range() succesfully returns. For log backend, we're also adding a complementary test to check if the address family is of expected type, else we report an error, plus we're moving the postinit logic in log api since _srv_check_proxy_mode() is only meant to check proxy mode compatibility and we were abusing it. This patch depends on: - "MINOR: tools: make str2sa_range() directly return type hints" No backport required unless 29b76ca gets backported.
2023-11-09 07:45:03 -05:00
BUG/MEDIUM: server/log: "mode log" after server keyword causes crash In 9a74a6c ("MAJOR: log: introduce log backends"), a mistake was made: it was assumed that the proxy mode was already known during server keyword parsing in parse_server() function, but this is wrong. Indeed, "mode log" can be declared late in the proxy section. Due to this, a simple config like this will cause the process to crash: |backend test | | server name 127.0.0.1:8080 | mode log In order to fix this, we relax some checks in _srv_parse_init() and store the address protocol from str2sa_range() in server struct, then we set-up a postparsing function that is to be called after config parsing to finish the server checks/initialization that depend on the proxy mode to be known. We achieve this by checking the PR_CAP_LB capability from the parent proxy to know if we're in such case where the effective proxy mode is not yet known (it is assumed that other proxies which are implicit ones don't provide this possibility and thus don't suffer from this constraint). Only then, if the capability is not found, we immediately perform the server checks that depend on the proxy mode, else the check is postponed and it will automatically be performed during postparsing thanks to the REGISTER_POST_SERVER_CHECK() hook. Note that we remove the SRV_PARSE_IN_LOG_BE flag because it was introduced in the above commit and it is no longer relevant. No backport needed unless 9a74a6c gets backported.
2023-10-19 04:59:26 -04:00
if (srv->proxy->mode == PR_MODE_SYSLOG) {
BUG/MEDIUM: server: invalid address (post)parsing checks This bug was introduced with 29b76ca ("BUG/MEDIUM: server/log: "mode log" after server keyword causes crash ") Indeed, we cannot safely rely on addr_proto being set when str2sa_range() returns in parse_server() (even if SRV_PARSE_PARSE_ADDR is set), because proto lookup might be bypassed when FQDN addresses are involved. Unfortunately, the above patch wrongly assumed that proto would always be set when SRV_PARSE_PARSE_ADDR was passed to parse_server() (so when str2sa_range() was called), resulting in invalid postparsing checks being performed, which could as well lead to crashes with log backends ("mode log" set) because some postparsing init was skipped as a result of proto not being set and this wasn't expected later in the init code. To fix this, we now make use of the previous patch to perform server's address compatibility checks on hints that are always set when str2sa_range() succesfully returns. For log backend, we're also adding a complementary test to check if the address family is of expected type, else we report an error, plus we're moving the postinit logic in log api since _srv_check_proxy_mode() is only meant to check proxy mode compatibility and we were abusing it. This patch depends on: - "MINOR: tools: make str2sa_range() directly return type hints" No backport required unless 29b76ca gets backported.
2023-11-09 07:45:03 -05:00
/* log backend server (belongs to proxy with mode log enabled):
* perform some compatibility checks
BUG/MEDIUM: server/log: "mode log" after server keyword causes crash In 9a74a6c ("MAJOR: log: introduce log backends"), a mistake was made: it was assumed that the proxy mode was already known during server keyword parsing in parse_server() function, but this is wrong. Indeed, "mode log" can be declared late in the proxy section. Due to this, a simple config like this will cause the process to crash: |backend test | | server name 127.0.0.1:8080 | mode log In order to fix this, we relax some checks in _srv_parse_init() and store the address protocol from str2sa_range() in server struct, then we set-up a postparsing function that is to be called after config parsing to finish the server checks/initialization that depend on the proxy mode to be known. We achieve this by checking the PR_CAP_LB capability from the parent proxy to know if we're in such case where the effective proxy mode is not yet known (it is assumed that other proxies which are implicit ones don't provide this possibility and thus don't suffer from this constraint). Only then, if the capability is not found, we immediately perform the server checks that depend on the proxy mode, else the check is postponed and it will automatically be performed during postparsing thanks to the REGISTER_POST_SERVER_CHECK() hook. Note that we remove the SRV_PARSE_IN_LOG_BE flag because it was introduced in the above commit and it is no longer relevant. No backport needed unless 9a74a6c gets backported.
2023-10-19 04:59:26 -04:00
*/
BUG/MEDIUM: server: invalid address (post)parsing checks This bug was introduced with 29b76ca ("BUG/MEDIUM: server/log: "mode log" after server keyword causes crash ") Indeed, we cannot safely rely on addr_proto being set when str2sa_range() returns in parse_server() (even if SRV_PARSE_PARSE_ADDR is set), because proto lookup might be bypassed when FQDN addresses are involved. Unfortunately, the above patch wrongly assumed that proto would always be set when SRV_PARSE_PARSE_ADDR was passed to parse_server() (so when str2sa_range() was called), resulting in invalid postparsing checks being performed, which could as well lead to crashes with log backends ("mode log" set) because some postparsing init was skipped as a result of proto not being set and this wasn't expected later in the init code. To fix this, we now make use of the previous patch to perform server's address compatibility checks on hints that are always set when str2sa_range() succesfully returns. For log backend, we're also adding a complementary test to check if the address family is of expected type, else we report an error, plus we're moving the postinit logic in log api since _srv_check_proxy_mode() is only meant to check proxy mode compatibility and we were abusing it. This patch depends on: - "MINOR: tools: make str2sa_range() directly return type hints" No backport required unless 29b76ca gets backported.
2023-11-09 07:45:03 -05:00
/* supported address family types are:
* - ipv4
* - ipv6
* (UNSPEC is supported because it means it will be resolved later)
*/
if (srv->addr.ss_family != AF_UNSPEC &&
srv->addr.ss_family != AF_INET && srv->addr.ss_family != AF_INET6) {
ha_alert("log server address family not supported for log backend server.\n");
BUG/MEDIUM: server/log: "mode log" after server keyword causes crash In 9a74a6c ("MAJOR: log: introduce log backends"), a mistake was made: it was assumed that the proxy mode was already known during server keyword parsing in parse_server() function, but this is wrong. Indeed, "mode log" can be declared late in the proxy section. Due to this, a simple config like this will cause the process to crash: |backend test | | server name 127.0.0.1:8080 | mode log In order to fix this, we relax some checks in _srv_parse_init() and store the address protocol from str2sa_range() in server struct, then we set-up a postparsing function that is to be called after config parsing to finish the server checks/initialization that depend on the proxy mode to be known. We achieve this by checking the PR_CAP_LB capability from the parent proxy to know if we're in such case where the effective proxy mode is not yet known (it is assumed that other proxies which are implicit ones don't provide this possibility and thus don't suffer from this constraint). Only then, if the capability is not found, we immediately perform the server checks that depend on the proxy mode, else the check is postponed and it will automatically be performed during postparsing thanks to the REGISTER_POST_SERVER_CHECK() hook. Note that we remove the SRV_PARSE_IN_LOG_BE flag because it was introduced in the above commit and it is no longer relevant. No backport needed unless 9a74a6c gets backported.
2023-10-19 04:59:26 -04:00
err_code |= ERR_ALERT | ERR_FATAL;
goto out;
}
BUG/MEDIUM: server: invalid address (post)parsing checks This bug was introduced with 29b76ca ("BUG/MEDIUM: server/log: "mode log" after server keyword causes crash ") Indeed, we cannot safely rely on addr_proto being set when str2sa_range() returns in parse_server() (even if SRV_PARSE_PARSE_ADDR is set), because proto lookup might be bypassed when FQDN addresses are involved. Unfortunately, the above patch wrongly assumed that proto would always be set when SRV_PARSE_PARSE_ADDR was passed to parse_server() (so when str2sa_range() was called), resulting in invalid postparsing checks being performed, which could as well lead to crashes with log backends ("mode log" set) because some postparsing init was skipped as a result of proto not being set and this wasn't expected later in the init code. To fix this, we now make use of the previous patch to perform server's address compatibility checks on hints that are always set when str2sa_range() succesfully returns. For log backend, we're also adding a complementary test to check if the address family is of expected type, else we report an error, plus we're moving the postinit logic in log api since _srv_check_proxy_mode() is only meant to check proxy mode compatibility and we were abusing it. This patch depends on: - "MINOR: tools: make str2sa_range() directly return type hints" No backport required unless 29b76ca gets backported.
2023-11-09 07:45:03 -05:00
/* only @tcp or @udp address forms (or equivalent) are supported */
if (!(srv->addr_type.xprt_type == PROTO_TYPE_DGRAM && srv->addr_type.proto_type == PROTO_TYPE_DGRAM) &&
!(srv->addr_type.xprt_type == PROTO_TYPE_STREAM && srv->addr_type.proto_type == PROTO_TYPE_STREAM)) {
ha_alert("log server address type not supported for log backend server.\n");
err_code |= ERR_ALERT | ERR_FATAL;
BUG/MEDIUM: server/log: "mode log" after server keyword causes crash In 9a74a6c ("MAJOR: log: introduce log backends"), a mistake was made: it was assumed that the proxy mode was already known during server keyword parsing in parse_server() function, but this is wrong. Indeed, "mode log" can be declared late in the proxy section. Due to this, a simple config like this will cause the process to crash: |backend test | | server name 127.0.0.1:8080 | mode log In order to fix this, we relax some checks in _srv_parse_init() and store the address protocol from str2sa_range() in server struct, then we set-up a postparsing function that is to be called after config parsing to finish the server checks/initialization that depend on the proxy mode to be known. We achieve this by checking the PR_CAP_LB capability from the parent proxy to know if we're in such case where the effective proxy mode is not yet known (it is assumed that other proxies which are implicit ones don't provide this possibility and thus don't suffer from this constraint). Only then, if the capability is not found, we immediately perform the server checks that depend on the proxy mode, else the check is postponed and it will automatically be performed during postparsing thanks to the REGISTER_POST_SERVER_CHECK() hook. Note that we remove the SRV_PARSE_IN_LOG_BE flag because it was introduced in the above commit and it is no longer relevant. No backport needed unless 9a74a6c gets backported.
2023-10-19 04:59:26 -04:00
}
}
else {
BUG/MEDIUM: server: invalid address (post)parsing checks This bug was introduced with 29b76ca ("BUG/MEDIUM: server/log: "mode log" after server keyword causes crash ") Indeed, we cannot safely rely on addr_proto being set when str2sa_range() returns in parse_server() (even if SRV_PARSE_PARSE_ADDR is set), because proto lookup might be bypassed when FQDN addresses are involved. Unfortunately, the above patch wrongly assumed that proto would always be set when SRV_PARSE_PARSE_ADDR was passed to parse_server() (so when str2sa_range() was called), resulting in invalid postparsing checks being performed, which could as well lead to crashes with log backends ("mode log" set) because some postparsing init was skipped as a result of proto not being set and this wasn't expected later in the init code. To fix this, we now make use of the previous patch to perform server's address compatibility checks on hints that are always set when str2sa_range() succesfully returns. For log backend, we're also adding a complementary test to check if the address family is of expected type, else we report an error, plus we're moving the postinit logic in log api since _srv_check_proxy_mode() is only meant to check proxy mode compatibility and we were abusing it. This patch depends on: - "MINOR: tools: make str2sa_range() directly return type hints" No backport required unless 29b76ca gets backported.
2023-11-09 07:45:03 -05:00
/* for all other proxy modes: only TCP expected as srv's transport type for now */
if (srv->addr_type.xprt_type != PROTO_TYPE_STREAM) {
ha_alert("unsupported transport for server address in '%s' backend.\n", proxy_mode_str(srv->proxy->mode));
BUG/MEDIUM: server/log: "mode log" after server keyword causes crash In 9a74a6c ("MAJOR: log: introduce log backends"), a mistake was made: it was assumed that the proxy mode was already known during server keyword parsing in parse_server() function, but this is wrong. Indeed, "mode log" can be declared late in the proxy section. Due to this, a simple config like this will cause the process to crash: |backend test | | server name 127.0.0.1:8080 | mode log In order to fix this, we relax some checks in _srv_parse_init() and store the address protocol from str2sa_range() in server struct, then we set-up a postparsing function that is to be called after config parsing to finish the server checks/initialization that depend on the proxy mode to be known. We achieve this by checking the PR_CAP_LB capability from the parent proxy to know if we're in such case where the effective proxy mode is not yet known (it is assumed that other proxies which are implicit ones don't provide this possibility and thus don't suffer from this constraint). Only then, if the capability is not found, we immediately perform the server checks that depend on the proxy mode, else the check is postponed and it will automatically be performed during postparsing thanks to the REGISTER_POST_SERVER_CHECK() hook. Note that we remove the SRV_PARSE_IN_LOG_BE flag because it was introduced in the above commit and it is no longer relevant. No backport needed unless 9a74a6c gets backported.
2023-10-19 04:59:26 -04:00
err_code |= ERR_ALERT | ERR_FATAL;
}
}
MINOR: server: move send-proxy* incompatibility check in _srv_check_proxy_mode() This way the check is executed no matter the section where the server is declared (ie: not only under the "ring" section)
2025-06-27 06:03:30 -04:00
if (srv->proxy->mode != PR_MODE_TCP && srv->proxy->mode != PR_MODE_HTTP &&
srv->pp_opts) {
srv->pp_opts = 0;
ha_warning("'send-proxy*' server option is unsupported there, ignoring it\n");
err_code |= ERR_WARN;
}
BUG/MEDIUM: server/log: "mode log" after server keyword causes crash In 9a74a6c ("MAJOR: log: introduce log backends"), a mistake was made: it was assumed that the proxy mode was already known during server keyword parsing in parse_server() function, but this is wrong. Indeed, "mode log" can be declared late in the proxy section. Due to this, a simple config like this will cause the process to crash: |backend test | | server name 127.0.0.1:8080 | mode log In order to fix this, we relax some checks in _srv_parse_init() and store the address protocol from str2sa_range() in server struct, then we set-up a postparsing function that is to be called after config parsing to finish the server checks/initialization that depend on the proxy mode to be known. We achieve this by checking the PR_CAP_LB capability from the parent proxy to know if we're in such case where the effective proxy mode is not yet known (it is assumed that other proxies which are implicit ones don't provide this possibility and thus don't suffer from this constraint). Only then, if the capability is not found, we immediately perform the server checks that depend on the proxy mode, else the check is postponed and it will automatically be performed during postparsing thanks to the REGISTER_POST_SERVER_CHECK() hook. Note that we remove the SRV_PARSE_IN_LOG_BE flag because it was introduced in the above commit and it is no longer relevant. No backport needed unless 9a74a6c gets backported.
2023-10-19 04:59:26 -04:00
out:
if (srv->conf.file)
reset_usermsgs_ctx();
return err_code;
}
MEDIUM: server: split srv_init() in srv_preinit() + srv_postinit() We actually need more granularity to split srv postparsing init tasks: Some of them are required to be run BEFORE the config is checked, and some of them AFTER the config is checked. Thus we push the logic from 368d0136 ("MEDIUM: server: add and use srv_init() function") a little bit further and split the function in two distinct ones, one of them executed under check_config_validity() and the other one using REGISTER_POST_SERVER_CHECK() hook. SRV_F_CHECKED flag was removed because it is no longer needed, srv_preinit() is only called once, and so is srv_postinit().
2025-08-08 06:22:13 -04:00
/* Finish initializing the server after parsing and before config checks
*
* Returns ERR_NONE on success else a combination or ERR_CODE.
*/
static int srv_init_per_thr(struct server *srv);
int srv_preinit(struct server *srv)
{
int err_code = ERR_NONE;
if (srv_init_per_thr(srv) == -1) {
ha_alert("error during per-thread init for %s/%s server\n", srv->proxy->id, srv->id);
err_code |= ERR_ALERT | ERR_FATAL;
goto out;
}
out:
return err_code;
}
/* Finish initializing the server after parsing and config checks
MEDIUM: server: add and use srv_init() function rename _srv_postparse() internal function to srv_init() function and group srv_init_per_thr() plus idle conns list init inside it. This way we can perform some simplifications as srv_init() performs multiple server init steps after parsing. SRV_F_CHECKED flag was added, it is automatically set when srv_init() runs successfully. If the flag is already set and srv_init() is called again, nothing is done. This permis to manually call srv_init() earlier than the default POST_CHECK hook when needed without risking to do things twice.
2025-05-09 14:27:29 -04:00
*
BUG/MEDIUM: server/log: "mode log" after server keyword causes crash In 9a74a6c ("MAJOR: log: introduce log backends"), a mistake was made: it was assumed that the proxy mode was already known during server keyword parsing in parse_server() function, but this is wrong. Indeed, "mode log" can be declared late in the proxy section. Due to this, a simple config like this will cause the process to crash: |backend test | | server name 127.0.0.1:8080 | mode log In order to fix this, we relax some checks in _srv_parse_init() and store the address protocol from str2sa_range() in server struct, then we set-up a postparsing function that is to be called after config parsing to finish the server checks/initialization that depend on the proxy mode to be known. We achieve this by checking the PR_CAP_LB capability from the parent proxy to know if we're in such case where the effective proxy mode is not yet known (it is assumed that other proxies which are implicit ones don't provide this possibility and thus don't suffer from this constraint). Only then, if the capability is not found, we immediately perform the server checks that depend on the proxy mode, else the check is postponed and it will automatically be performed during postparsing thanks to the REGISTER_POST_SERVER_CHECK() hook. Note that we remove the SRV_PARSE_IN_LOG_BE flag because it was introduced in the above commit and it is no longer relevant. No backport needed unless 9a74a6c gets backported.
2023-10-19 04:59:26 -04:00
* We must be careful that checks / postinits performed within this function
* don't depend or conflict with other postcheck functions that are registered
* using REGISTER_POST_SERVER_CHECK() hook.
*
* Returns ERR_NONE on success else a combination or ERR_CODE.
*/
MINOR: server: group postinit server tasks under _srv_postparse() init_srv_requeue() and init_srv_slowstart() functions are called after initial server parsing via REGISTER_POST_SERVER_CHECK() hook, and they are also manually called for dynamic server after the server is initialized. This may conflict with _srv_postparse() which is also registered via REGISTER_POST_SERVER_CHECK() and called during dynamic server creation To ensure functions don't conflict with each other, let's ensure they are executed in proper order by calling init_srv_requeue and init_srv_slowstart() from _srv_postparse() which now becomes the parent function for server related postparsing stuff. No change of behavior is expected.
2025-05-08 13:15:24 -04:00
static int init_srv_requeue(struct server *srv);
static int init_srv_slowstart(struct server *srv);
MEDIUM: server: split srv_init() in srv_preinit() + srv_postinit() We actually need more granularity to split srv postparsing init tasks: Some of them are required to be run BEFORE the config is checked, and some of them AFTER the config is checked. Thus we push the logic from 368d0136 ("MEDIUM: server: add and use srv_init() function") a little bit further and split the function in two distinct ones, one of them executed under check_config_validity() and the other one using REGISTER_POST_SERVER_CHECK() hook. SRV_F_CHECKED flag was removed because it is no longer needed, srv_preinit() is only called once, and so is srv_postinit().
2025-08-08 06:22:13 -04:00
int srv_postinit(struct server *srv)
BUG/MEDIUM: server/log: "mode log" after server keyword causes crash In 9a74a6c ("MAJOR: log: introduce log backends"), a mistake was made: it was assumed that the proxy mode was already known during server keyword parsing in parse_server() function, but this is wrong. Indeed, "mode log" can be declared late in the proxy section. Due to this, a simple config like this will cause the process to crash: |backend test | | server name 127.0.0.1:8080 | mode log In order to fix this, we relax some checks in _srv_parse_init() and store the address protocol from str2sa_range() in server struct, then we set-up a postparsing function that is to be called after config parsing to finish the server checks/initialization that depend on the proxy mode to be known. We achieve this by checking the PR_CAP_LB capability from the parent proxy to know if we're in such case where the effective proxy mode is not yet known (it is assumed that other proxies which are implicit ones don't provide this possibility and thus don't suffer from this constraint). Only then, if the capability is not found, we immediately perform the server checks that depend on the proxy mode, else the check is postponed and it will automatically be performed during postparsing thanks to the REGISTER_POST_SERVER_CHECK() hook. Note that we remove the SRV_PARSE_IN_LOG_BE flag because it was introduced in the above commit and it is no longer relevant. No backport needed unless 9a74a6c gets backported.
2023-10-19 04:59:26 -04:00
{
int err_code = ERR_NONE;
MINOR: counters: retrieve detailed errmsg upon failure with counters_{fe,be}_shared_prepare() counters_{fe,be}_shared_prepare now take an extra <errmsg> parameter that contains additional hints about the error in case of failure. It must be freed accordingly since it is allocated using memprintf
2025-08-27 08:51:48 -04:00
char *errmsg = NULL;
BUG/MEDIUM: server/log: "mode log" after server keyword causes crash In 9a74a6c ("MAJOR: log: introduce log backends"), a mistake was made: it was assumed that the proxy mode was already known during server keyword parsing in parse_server() function, but this is wrong. Indeed, "mode log" can be declared late in the proxy section. Due to this, a simple config like this will cause the process to crash: |backend test | | server name 127.0.0.1:8080 | mode log In order to fix this, we relax some checks in _srv_parse_init() and store the address protocol from str2sa_range() in server struct, then we set-up a postparsing function that is to be called after config parsing to finish the server checks/initialization that depend on the proxy mode to be known. We achieve this by checking the PR_CAP_LB capability from the parent proxy to know if we're in such case where the effective proxy mode is not yet known (it is assumed that other proxies which are implicit ones don't provide this possibility and thus don't suffer from this constraint). Only then, if the capability is not found, we immediately perform the server checks that depend on the proxy mode, else the check is postponed and it will automatically be performed during postparsing thanks to the REGISTER_POST_SERVER_CHECK() hook. Note that we remove the SRV_PARSE_IN_LOG_BE flag because it was introduced in the above commit and it is no longer relevant. No backport needed unless 9a74a6c gets backported.
2023-10-19 04:59:26 -04:00
err_code |= _srv_check_proxy_mode(srv, 1);
MINOR: server: group postinit server tasks under _srv_postparse() init_srv_requeue() and init_srv_slowstart() functions are called after initial server parsing via REGISTER_POST_SERVER_CHECK() hook, and they are also manually called for dynamic server after the server is initialized. This may conflict with _srv_postparse() which is also registered via REGISTER_POST_SERVER_CHECK() and called during dynamic server creation To ensure functions don't conflict with each other, let's ensure they are executed in proper order by calling init_srv_requeue and init_srv_slowstart() from _srv_postparse() which now becomes the parent function for server related postparsing stuff. No change of behavior is expected.
2025-05-08 13:15:24 -04:00
if (err_code & ERR_CODE)
goto out;
MINOR: counters: retrieve detailed errmsg upon failure with counters_{fe,be}_shared_prepare() counters_{fe,be}_shared_prepare now take an extra <errmsg> parameter that contains additional hints about the error in case of failure. It must be freed accordingly since it is allocated using memprintf
2025-08-27 08:51:48 -04:00
if (!counters_be_shared_prepare(&srv->counters.shared, &srv->guid, &errmsg)) {
ha_alert("memory error while setting up shared counters for %s/%s server : %s\n", srv->proxy->id, srv->id, errmsg);
ha_free(&errmsg);
MEDIUM: counters: manage shared counters using dedicated helpers proxies, listeners and server shared counters are now managed via helpers added in one of the previous commits. When guid is not set (ie: when not yet assigned), shared counters pointer is allocated using calloc() (local memory) and a flag is set on the shared counters struct to know how to manipulate (and free it). Else if guid is set, then it means that the counters may be shared so while for now we don't actually use a shared memory location the API is ready for that. The way it works, for proxies and servers (for which guid is not known during creation), we first call counters_{fe,be}_shared_get with guid not set, which results in local pointer being retrieved (as if we just manually called calloc() to retrieve a pointer). Later (during postparsing) if guid is set we try to upgrade the pointer from local to shared. Lastly, since the memory location for some objects (proxies and servers counters) may change from creation to postparsing, let's update counters->last_change member directly under counters_{fe,be}_shared_get() so we don't miss it. No change of behavior is expected, this is only preparation work.
2025-05-07 17:42:04 -04:00
err_code |= ERR_ALERT | ERR_FATAL;
goto out;
}
if (srv->flags & SRV_F_DYNAMIC) {
/* A dynamic server is disabled on startup */
srv->next_admin = SRV_ADMF_FMAINT;
srv->next_state = SRV_ST_STOPPED;
server_recalc_eweight(srv, 0); // relies on srv counters
srv_lb_commit_status(srv);
}
MINOR: server: group postinit server tasks under _srv_postparse() init_srv_requeue() and init_srv_slowstart() functions are called after initial server parsing via REGISTER_POST_SERVER_CHECK() hook, and they are also manually called for dynamic server after the server is initialized. This may conflict with _srv_postparse() which is also registered via REGISTER_POST_SERVER_CHECK() and called during dynamic server creation To ensure functions don't conflict with each other, let's ensure they are executed in proper order by calling init_srv_requeue and init_srv_slowstart() from _srv_postparse() which now becomes the parent function for server related postparsing stuff. No change of behavior is expected.
2025-05-08 13:15:24 -04:00
err_code |= init_srv_requeue(srv);
if (err_code & ERR_CODE)
goto out;
err_code |= init_srv_slowstart(srv);
if (err_code & ERR_CODE)
goto out;
MEDIUM: server: add and use srv_init() function rename _srv_postparse() internal function to srv_init() function and group srv_init_per_thr() plus idle conns list init inside it. This way we can perform some simplifications as srv_init() performs multiple server init steps after parsing. SRV_F_CHECKED flag was added, it is automatically set when srv_init() runs successfully. If the flag is already set and srv_init() is called again, nothing is done. This permis to manually call srv_init() earlier than the default POST_CHECK hook when needed without risking to do things twice.
2025-05-09 14:27:29 -04:00
/* initialize idle conns lists */
if (srv->max_idle_conns != 0) {
OPTIM: server: start to use aligned allocs in server This is currently for per-thread arrays like idle conns etc. We're now cache-aligning the per-thread arrays so as to put an end to false sharing. A comparative test between no alignment and alignment on a simple config with round robin between 4 servers showed an average rate of 1.75M/s vs 1.72M/s before for 100M requests. The gain seems to be more commonly less than 1% however. This should mostly help make measurements more reproducible across multiple runs.
2025-08-11 11:43:51 -04:00
srv->curr_idle_thr = ha_aligned_zalloc(64, global.nbthread * sizeof(*srv->curr_idle_thr));
MEDIUM: server: add and use srv_init() function rename _srv_postparse() internal function to srv_init() function and group srv_init_per_thr() plus idle conns list init inside it. This way we can perform some simplifications as srv_init() performs multiple server init steps after parsing. SRV_F_CHECKED flag was added, it is automatically set when srv_init() runs successfully. If the flag is already set and srv_init() is called again, nothing is done. This permis to manually call srv_init() earlier than the default POST_CHECK hook when needed without risking to do things twice.
2025-05-09 14:27:29 -04:00
if (!srv->curr_idle_thr) {
ha_alert("memory error during idle conn list init for %s/%s server\n",
srv->proxy->id, srv->id);
err_code |= ERR_ALERT | ERR_FATAL;
goto out;
}
}
MINOR: server: group postinit server tasks under _srv_postparse() init_srv_requeue() and init_srv_slowstart() functions are called after initial server parsing via REGISTER_POST_SERVER_CHECK() hook, and they are also manually called for dynamic server after the server is initialized. This may conflict with _srv_postparse() which is also registered via REGISTER_POST_SERVER_CHECK() and called during dynamic server creation To ensure functions don't conflict with each other, let's ensure they are executed in proper order by calling init_srv_requeue and init_srv_slowstart() from _srv_postparse() which now becomes the parent function for server related postparsing stuff. No change of behavior is expected.
2025-05-08 13:15:24 -04:00
out:
BUG/MEDIUM: server/log: "mode log" after server keyword causes crash In 9a74a6c ("MAJOR: log: introduce log backends"), a mistake was made: it was assumed that the proxy mode was already known during server keyword parsing in parse_server() function, but this is wrong. Indeed, "mode log" can be declared late in the proxy section. Due to this, a simple config like this will cause the process to crash: |backend test | | server name 127.0.0.1:8080 | mode log In order to fix this, we relax some checks in _srv_parse_init() and store the address protocol from str2sa_range() in server struct, then we set-up a postparsing function that is to be called after config parsing to finish the server checks/initialization that depend on the proxy mode to be known. We achieve this by checking the PR_CAP_LB capability from the parent proxy to know if we're in such case where the effective proxy mode is not yet known (it is assumed that other proxies which are implicit ones don't provide this possibility and thus don't suffer from this constraint). Only then, if the capability is not found, we immediately perform the server checks that depend on the proxy mode, else the check is postponed and it will automatically be performed during postparsing thanks to the REGISTER_POST_SERVER_CHECK() hook. Note that we remove the SRV_PARSE_IN_LOG_BE flag because it was introduced in the above commit and it is no longer relevant. No backport needed unless 9a74a6c gets backported.
2023-10-19 04:59:26 -04:00
return err_code;
}
MEDIUM: server: split srv_init() in srv_preinit() + srv_postinit() We actually need more granularity to split srv postparsing init tasks: Some of them are required to be run BEFORE the config is checked, and some of them AFTER the config is checked. Thus we push the logic from 368d0136 ("MEDIUM: server: add and use srv_init() function") a little bit further and split the function in two distinct ones, one of them executed under check_config_validity() and the other one using REGISTER_POST_SERVER_CHECK() hook. SRV_F_CHECKED flag was removed because it is no longer needed, srv_preinit() is only called once, and so is srv_postinit().
2025-08-08 06:22:13 -04:00
REGISTER_POST_SERVER_CHECK(srv_postinit);
BUG/MEDIUM: server/log: "mode log" after server keyword causes crash In 9a74a6c ("MAJOR: log: introduce log backends"), a mistake was made: it was assumed that the proxy mode was already known during server keyword parsing in parse_server() function, but this is wrong. Indeed, "mode log" can be declared late in the proxy section. Due to this, a simple config like this will cause the process to crash: |backend test | | server name 127.0.0.1:8080 | mode log In order to fix this, we relax some checks in _srv_parse_init() and store the address protocol from str2sa_range() in server struct, then we set-up a postparsing function that is to be called after config parsing to finish the server checks/initialization that depend on the proxy mode to be known. We achieve this by checking the PR_CAP_LB capability from the parent proxy to know if we're in such case where the effective proxy mode is not yet known (it is assumed that other proxies which are implicit ones don't provide this possibility and thus don't suffer from this constraint). Only then, if the capability is not found, we immediately perform the server checks that depend on the proxy mode, else the check is postponed and it will automatically be performed during postparsing thanks to the REGISTER_POST_SERVER_CHECK() hook. Note that we remove the SRV_PARSE_IN_LOG_BE flag because it was introduced in the above commit and it is no longer relevant. No backport needed unless 9a74a6c gets backported.
2023-10-19 04:59:26 -04:00
REORG: server: split parse_server The huge parse_server function is splitted into two smaller ones. * _srv_parse_init allocates a new server instance and parses the address parameter * _srv_parse_kw parse the current server keyword This simplify a bit the parse_server function. Besides, it will be useful for dynamic server creation.
2021-03-08 04:29:33 -05:00
/* Allocate a new server pointed by <srv> and try to parse the first arguments
* in <args> as an address for a server or an address-range for a template or
* nothing for a default-server. <cur_arg> is incremented to the next argument.
*
CLEANUP: assorted typo fixes in the code and comments This is 21st iteration of typo fixes
2021-03-19 13:21:44 -04:00
* This function is first intended to be used through parse_server to
REORG: server: split parse_server The huge parse_server function is splitted into two smaller ones. * _srv_parse_init allocates a new server instance and parses the address parameter * _srv_parse_kw parse the current server keyword This simplify a bit the parse_server function. Besides, it will be useful for dynamic server creation.
2021-03-08 04:29:33 -05:00
* initialize a new server on startup.
*
* A mask of errors is returned. On a parsing error, ERR_FATAL is set. In case
* of memory exhaustion, ERR_ABORT is set. If the server cannot be allocated,
* <srv> will be set to NULL.
*/
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
static int _srv_parse_init(struct server **srv, char **args, int *cur_arg,
struct proxy *curproxy,
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
int parse_flags)
REORG: cfgparse: move server keyword parsing to server.c The cfgparse.c file becomes huge, and a large part of it comes from the server keyword parser. Since the configuration is a bit more modular now, move this parser to server.c. This patch also moves the check of the "server" keyword earlier in the supported keywords list, resulting in a slightly faster config parsing for configs with large numbers of servers (about 10%). No functional change was made, only the code was moved.
2014-03-31 04:39:59 -04:00
{
struct server *newsrv = NULL;
MINOR: server: Add 'server-template' new keyword supported in backend sections. This patch makes backend sections support 'server-template' new keyword. Such 'server-template' objects are parsed similarly to a 'server' object by parse_server() function, but its first arguments are as follows: server-template <ID prefix> <nb | range> <ip | fqdn>:<port> ... The remaining arguments are the same as for 'server' lines. With such server template declarations, servers may be allocated with IDs built from <ID prefix> and <nb | range> arguments. For instance declaring: server-template foo 1-5 google.com:80 ... or server-template foo 5 google.com:80 ... would be equivalent to declare: server foo1 google.com:80 ... server foo2 google.com:80 ... server foo3 google.com:80 ... server foo4 google.com:80 ... server foo5 google.com:80 ...
2017-04-13 12:24:23 -04:00
const char *err = NULL;
REORG: cfgparse: move server keyword parsing to server.c The cfgparse.c file becomes huge, and a large part of it comes from the server keyword parser. Since the configuration is a bit more modular now, move this parser to server.c. This patch also moves the check of the "server" keyword earlier in the supported keywords list, resulting in a slightly faster config parsing for configs with large numbers of servers (about 10%). No functional change was made, only the code was moved.
2014-03-31 04:39:59 -04:00
int err_code = 0;
BUG/MEDIUM: dns: use the correct server hostname when resolving The server's host name picked for resolution was incorrect, it did not skip the address family specifier, did not resolve environment variables, and messed up with the optional trailing colon. Instead, let's get the fqdn returned by str2sa_range() and use that exclusively.
2015-09-08 10:16:35 -04:00
char *fqdn = NULL;
MINOR: server: add a alt_proto field for server Add a new field alt_proto to the server structures that specify if an alternate protocol should be used for this server. This field can be transparently passed to protocol_lookup to get an appropriate protocol structure. This change allows thus to create servers with different protocols, and not only TCP anymore.
2024-08-26 05:50:25 -04:00
int alt_proto = 0;
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
int tmpl_range_low = 0, tmpl_range_high = 0;
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
char *errmsg = NULL;
REORG: cfgparse: move server keyword parsing to server.c The cfgparse.c file becomes huge, and a large part of it comes from the server keyword parser. Since the configuration is a bit more modular now, move this parser to server.c. This patch also moves the check of the "server" keyword earlier in the supported keywords list, resulting in a slightly faster config parsing for configs with large numbers of servers (about 10%). No functional change was made, only the code was moved.
2014-03-31 04:39:59 -04:00
REORG: server: split parse_server The huge parse_server function is splitted into two smaller ones. * _srv_parse_init allocates a new server instance and parses the address parameter * _srv_parse_kw parse the current server keyword This simplify a bit the parse_server function. Besides, it will be useful for dynamic server creation.
2021-03-08 04:29:33 -05:00
*srv = NULL;
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
/* There is no mandatory first arguments for default server. */
if (parse_flags & SRV_PARSE_PARSE_ADDR) {
if (parse_flags & SRV_PARSE_TEMPLATE) {
if (!*args[3]) {
/* 'server-template' line number of argument check. */
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
ha_alert("'%s' expects <prefix> <nb | range> <addr>[:<port>] as arguments.\n",
args[0]);
REORG: server: split parse_server The huge parse_server function is splitted into two smaller ones. * _srv_parse_init allocates a new server instance and parses the address parameter * _srv_parse_kw parse the current server keyword This simplify a bit the parse_server function. Besides, it will be useful for dynamic server creation.
2021-03-08 04:29:33 -05:00
err_code |= ERR_ALERT | ERR_FATAL;
goto out;
MINOR: server: Add 'server-template' new keyword supported in backend sections. This patch makes backend sections support 'server-template' new keyword. Such 'server-template' objects are parsed similarly to a 'server' object by parse_server() function, but its first arguments are as follows: server-template <ID prefix> <nb | range> <ip | fqdn>:<port> ... The remaining arguments are the same as for 'server' lines. With such server template declarations, servers may be allocated with IDs built from <ID prefix> and <nb | range> arguments. For instance declaring: server-template foo 1-5 google.com:80 ... or server-template foo 5 google.com:80 ... would be equivalent to declare: server foo1 google.com:80 ... server foo2 google.com:80 ... server foo3 google.com:80 ... server foo4 google.com:80 ... server foo5 google.com:80 ...
2017-04-13 12:24:23 -04:00
}
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
err = invalid_prefix_char(args[1]);
MINOR: server: Add 'server-template' new keyword supported in backend sections. This patch makes backend sections support 'server-template' new keyword. Such 'server-template' objects are parsed similarly to a 'server' object by parse_server() function, but its first arguments are as follows: server-template <ID prefix> <nb | range> <ip | fqdn>:<port> ... The remaining arguments are the same as for 'server' lines. With such server template declarations, servers may be allocated with IDs built from <ID prefix> and <nb | range> arguments. For instance declaring: server-template foo 1-5 google.com:80 ... or server-template foo 5 google.com:80 ... would be equivalent to declare: server foo1 google.com:80 ... server foo2 google.com:80 ... server foo3 google.com:80 ... server foo4 google.com:80 ... server foo5 google.com:80 ...
2017-04-13 12:24:23 -04:00
}
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
else {
if (!*args[2]) {
/* 'server' line number of argument check. */
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
ha_alert("'%s' expects <name> and <addr>[:<port>] as arguments.\n",
args[0]);
MINOR: server: Add 'server-template' new keyword supported in backend sections. This patch makes backend sections support 'server-template' new keyword. Such 'server-template' objects are parsed similarly to a 'server' object by parse_server() function, but its first arguments are as follows: server-template <ID prefix> <nb | range> <ip | fqdn>:<port> ... The remaining arguments are the same as for 'server' lines. With such server template declarations, servers may be allocated with IDs built from <ID prefix> and <nb | range> arguments. For instance declaring: server-template foo 1-5 google.com:80 ... or server-template foo 5 google.com:80 ... would be equivalent to declare: server foo1 google.com:80 ... server foo2 google.com:80 ... server foo3 google.com:80 ... server foo4 google.com:80 ... server foo5 google.com:80 ...
2017-04-13 12:24:23 -04:00
err_code |= ERR_ALERT | ERR_FATAL;
goto out;
}
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
err = invalid_char(args[1]);
REORG: cfgparse: move server keyword parsing to server.c The cfgparse.c file becomes huge, and a large part of it comes from the server keyword parser. Since the configuration is a bit more modular now, move this parser to server.c. This patch also moves the check of the "server" keyword earlier in the supported keywords list, resulting in a slightly faster config parsing for configs with large numbers of servers (about 10%). No functional change was made, only the code was moved.
2014-03-31 04:39:59 -04:00
}
MINOR: server: Add 'server-template' new keyword supported in backend sections. This patch makes backend sections support 'server-template' new keyword. Such 'server-template' objects are parsed similarly to a 'server' object by parse_server() function, but its first arguments are as follows: server-template <ID prefix> <nb | range> <ip | fqdn>:<port> ... The remaining arguments are the same as for 'server' lines. With such server template declarations, servers may be allocated with IDs built from <ID prefix> and <nb | range> arguments. For instance declaring: server-template foo 1-5 google.com:80 ... or server-template foo 5 google.com:80 ... would be equivalent to declare: server foo1 google.com:80 ... server foo2 google.com:80 ... server foo3 google.com:80 ... server foo4 google.com:80 ... server foo5 google.com:80 ...
2017-04-13 12:24:23 -04:00
if (err) {
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
ha_alert("character '%c' is not permitted in %s %s '%s'.\n",
*err, args[0], !(parse_flags & SRV_PARSE_TEMPLATE) ? "name" : "prefix", args[1]);
REORG: cfgparse: move server keyword parsing to server.c The cfgparse.c file becomes huge, and a large part of it comes from the server keyword parser. Since the configuration is a bit more modular now, move this parser to server.c. This patch also moves the check of the "server" keyword earlier in the supported keywords list, resulting in a slightly faster config parsing for configs with large numbers of servers (about 10%). No functional change was made, only the code was moved.
2014-03-31 04:39:59 -04:00
err_code |= ERR_ALERT | ERR_FATAL;
goto out;
}
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
}
REORG: cfgparse: move server keyword parsing to server.c The cfgparse.c file becomes huge, and a large part of it comes from the server keyword parser. Since the configuration is a bit more modular now, move this parser to server.c. This patch also moves the check of the "server" keyword earlier in the supported keywords list, resulting in a slightly faster config parsing for configs with large numbers of servers (about 10%). No functional change was made, only the code was moved.
2014-03-31 04:39:59 -04:00
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
*cur_arg = 2;
if (parse_flags & SRV_PARSE_TEMPLATE) {
/* Parse server-template <nb | range> arg. */
if (_srv_parse_tmpl_range(newsrv, args[*cur_arg], &tmpl_range_low, &tmpl_range_high) < 0) {
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
ha_alert("Wrong %s number or range arg '%s'.\n",
args[0], args[*cur_arg]);
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
err_code |= ERR_ALERT | ERR_FATAL;
goto out;
MINOR: server: Add 'server-template' new keyword supported in backend sections. This patch makes backend sections support 'server-template' new keyword. Such 'server-template' objects are parsed similarly to a 'server' object by parse_server() function, but its first arguments are as follows: server-template <ID prefix> <nb | range> <ip | fqdn>:<port> ... The remaining arguments are the same as for 'server' lines. With such server template declarations, servers may be allocated with IDs built from <ID prefix> and <nb | range> arguments. For instance declaring: server-template foo 1-5 google.com:80 ... or server-template foo 5 google.com:80 ... would be equivalent to declare: server foo1 google.com:80 ... server foo2 google.com:80 ... server foo3 google.com:80 ... server foo4 google.com:80 ... server foo5 google.com:80 ...
2017-04-13 12:24:23 -04:00
}
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
(*cur_arg)++;
}
MINOR: server: Add 'server-template' new keyword supported in backend sections. This patch makes backend sections support 'server-template' new keyword. Such 'server-template' objects are parsed similarly to a 'server' object by parse_server() function, but its first arguments are as follows: server-template <ID prefix> <nb | range> <ip | fqdn>:<port> ... The remaining arguments are the same as for 'server' lines. With such server template declarations, servers may be allocated with IDs built from <ID prefix> and <nb | range> arguments. For instance declaring: server-template foo 1-5 google.com:80 ... or server-template foo 5 google.com:80 ... would be equivalent to declare: server foo1 google.com:80 ... server foo2 google.com:80 ... server foo3 google.com:80 ... server foo4 google.com:80 ... server foo5 google.com:80 ...
2017-04-13 12:24:23 -04:00
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
if (!(parse_flags & SRV_PARSE_DEFAULT_SERVER)) {
struct sockaddr_storage *sk;
int port1, port2, port;
REORG: cfgparse: move server keyword parsing to server.c The cfgparse.c file becomes huge, and a large part of it comes from the server keyword parser. Since the configuration is a bit more modular now, move this parser to server.c. This patch also moves the check of the "server" keyword earlier in the supported keywords list, resulting in a slightly faster config parsing for configs with large numbers of servers (about 10%). No functional change was made, only the code was moved.
2014-03-31 04:39:59 -04:00
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
*srv = newsrv = new_server(curproxy);
if (!newsrv) {
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
ha_alert("out of memory.\n");
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
err_code |= ERR_ALERT | ERR_ABORT;
goto out;
}
REORG: server: use parsing ctx for server parsing Use the parsing context in parse_server. Remove redundant manual format-string specifying the current file/line/server parsed.
2021-05-28 05:00:18 -04:00
register_parsing_obj(&newsrv->obj_type);
REORG: cfgparse: move server keyword parsing to server.c The cfgparse.c file becomes huge, and a large part of it comes from the server keyword parser. Since the configuration is a bit more modular now, move this parser to server.c. This patch also moves the check of the "server" keyword earlier in the supported keywords list, resulting in a slightly faster config parsing for configs with large numbers of servers (about 10%). No functional change was made, only the code was moved.
2014-03-31 04:39:59 -04:00
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
if (parse_flags & SRV_PARSE_TEMPLATE) {
newsrv->tmpl_info.nb_low = tmpl_range_low;
newsrv->tmpl_info.nb_high = tmpl_range_high;
}
MINOR: server: Add 'server-template' new keyword supported in backend sections. This patch makes backend sections support 'server-template' new keyword. Such 'server-template' objects are parsed similarly to a 'server' object by parse_server() function, but its first arguments are as follows: server-template <ID prefix> <nb | range> <ip | fqdn>:<port> ... The remaining arguments are the same as for 'server' lines. With such server template declarations, servers may be allocated with IDs built from <ID prefix> and <nb | range> arguments. For instance declaring: server-template foo 1-5 google.com:80 ... or server-template foo 5 google.com:80 ... would be equivalent to declare: server foo1 google.com:80 ... server foo2 google.com:80 ... server foo3 google.com:80 ... server foo4 google.com:80 ... server foo5 google.com:80 ...
2017-04-13 12:24:23 -04:00
MINOR: server: prepare parsing for dynamic servers Prepare the server parsing API to support dynamic servers. - define a new parsing flag to be used for dynamic servers - each keyword contains a new field dynamic_ok to indicate if it can be used for a dynamic server. For now, no keyword are supported. - do not copy settings from the default server for a new dynamic server. - a dynamic server is created in a maintenance mode and requires an explicit 'enable server' command. - a new server flag named SRV_F_DYNAMIC is created. This flag is set for all servers created at runtime. It might be useful later, for example to know if a server can be purged.
2021-03-08 11:08:01 -05:00
if (parse_flags & SRV_PARSE_DYNAMIC)
newsrv->flags |= SRV_F_DYNAMIC;
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
/* Note: for a server template, its id is its prefix.
* This is a temporary id which will be used for server allocations to come
* after parsing.
*/
if (!(parse_flags & SRV_PARSE_TEMPLATE))
newsrv->id = strdup(args[1]);
else
newsrv->tmpl_info.prefix = strdup(args[1]);
/* several ways to check the port component :
* - IP => port=+0, relative (IPv4 only)
* - IP: => port=+0, relative
* - IP:N => port=N, absolute
* - IP:+N => port=+N, relative
* - IP:-N => port=-N, relative
*/
if (!(parse_flags & SRV_PARSE_PARSE_ADDR))
goto skip_addr;
BUG/MEDIUM: server: invalid address (post)parsing checks This bug was introduced with 29b76ca ("BUG/MEDIUM: server/log: "mode log" after server keyword causes crash ") Indeed, we cannot safely rely on addr_proto being set when str2sa_range() returns in parse_server() (even if SRV_PARSE_PARSE_ADDR is set), because proto lookup might be bypassed when FQDN addresses are involved. Unfortunately, the above patch wrongly assumed that proto would always be set when SRV_PARSE_PARSE_ADDR was passed to parse_server() (so when str2sa_range() was called), resulting in invalid postparsing checks being performed, which could as well lead to crashes with log backends ("mode log" set) because some postparsing init was skipped as a result of proto not being set and this wasn't expected later in the init code. To fix this, we now make use of the previous patch to perform server's address compatibility checks on hints that are always set when str2sa_range() succesfully returns. For log backend, we're also adding a complementary test to check if the address family is of expected type, else we report an error, plus we're moving the postinit logic in log api since _srv_check_proxy_mode() is only meant to check proxy mode compatibility and we were abusing it. This patch depends on: - "MINOR: tools: make str2sa_range() directly return type hints" No backport required unless 29b76ca gets backported.
2023-11-09 07:45:03 -05:00
sk = str2sa_range(args[*cur_arg], &port, &port1, &port2, NULL, NULL, &newsrv->addr_type,
MINOR: server: add a alt_proto field for server Add a new field alt_proto to the server structures that specify if an alternate protocol should be used for this server. This field can be transparently passed to protocol_lookup to get an appropriate protocol structure. This change allows thus to create servers with different protocols, and not only TCP anymore.
2024-08-26 05:50:25 -04:00
&errmsg, NULL, &fqdn, &alt_proto,
BUG/MINOR: peers: Improve detection of config errors in peers sections There are several misuses in peers sections that are not detected during the configuration parsing and that could lead to undefined behaviors or crashes. First, only one listener is expected for a peers section. If several bind lines or local peer definitions are used, an error is triggered. However, if multiple addresses are set on the same bind line, there is no error while only the last listener is properly configured. On the 2.8, there is no crash but side effects are hardly predictable. On older version, HAProxy crashes if an unconfigured listener is used. Then, there is no check on remote peers name. It is unexpected to have same name for several remote peers. There is now a test, performed during the post-parsing, to verify all remote peer names are unique. Finally, server parsing options for the peers sections are changed to be sure a port is always defined, and not a port range or a port offset. This patch fixes the issue #2066. It could be backported to all stable versions.
2023-06-02 08:10:36 -04:00
(parse_flags & SRV_PARSE_INITIAL_RESOLVE ? PA_O_RESOLVE : 0) | PA_O_PORT_OK |
(parse_flags & SRV_PARSE_IN_PEER_SECTION ? PA_O_PORT_MAND : PA_O_PORT_OFS) |
BUG/MEDIUM: server/log: "mode log" after server keyword causes crash In 9a74a6c ("MAJOR: log: introduce log backends"), a mistake was made: it was assumed that the proxy mode was already known during server keyword parsing in parse_server() function, but this is wrong. Indeed, "mode log" can be declared late in the proxy section. Due to this, a simple config like this will cause the process to crash: |backend test | | server name 127.0.0.1:8080 | mode log In order to fix this, we relax some checks in _srv_parse_init() and store the address protocol from str2sa_range() in server struct, then we set-up a postparsing function that is to be called after config parsing to finish the server checks/initialization that depend on the proxy mode to be known. We achieve this by checking the PR_CAP_LB capability from the parent proxy to know if we're in such case where the effective proxy mode is not yet known (it is assumed that other proxies which are implicit ones don't provide this possibility and thus don't suffer from this constraint). Only then, if the capability is not found, we immediately perform the server checks that depend on the proxy mode, else the check is postponed and it will automatically be performed during postparsing thanks to the REGISTER_POST_SERVER_CHECK() hook. Note that we remove the SRV_PARSE_IN_LOG_BE flag because it was introduced in the above commit and it is no longer relevant. No backport needed unless 9a74a6c gets backported.
2023-10-19 04:59:26 -04:00
PA_O_STREAM | PA_O_DGRAM | PA_O_XPRT);
MINOR: quic-be: QUIC backend XPRT and transport parameters init during parsing Add ->quic_params new member to server struct. Also set the ->xprt member of the server being initialized and initialize asap its transport parameters from _srv_parse_init().
2023-12-18 05:18:45 -05:00
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
if (!sk) {
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
ha_alert("%s\n", errmsg);
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
err_code |= ERR_ALERT | ERR_FATAL;
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
ha_free(&errmsg);
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
goto out;
}
REORG: cfgparse: move server keyword parsing to server.c The cfgparse.c file becomes huge, and a large part of it comes from the server keyword parser. Since the configuration is a bit more modular now, move this parser to server.c. This patch also moves the check of the "server" keyword earlier in the supported keywords list, resulting in a slightly faster config parsing for configs with large numbers of servers (about 10%). No functional change was made, only the code was moved.
2014-03-31 04:39:59 -04:00
BUG/MINOR: config/server: reject QUIC addresses QUIC is not implemented on the backend side. To prevent any issue, it is better to reject any server configured which uses it. This is done via _srv_parse_init() which is used both for static and dynamic servers. This should be backported up to all stable versions.
2025-06-11 12:26:10 -04:00
#ifdef USE_QUIC
MINOR: quic: Prevent QUIC backend use with the OpenSSL QUIC compatibility module (USE_OPENSS_COMPAT) Make the server line parsing fail when a QUIC backend is configured if haproxy is built to use the OpenSSL stack compatibility module. This latter does not support the QUIC client part.
2025-07-02 11:56:03 -04:00
#ifdef HAVE_OPENSSL_QUIC_CLIENT_SUPPORT
MINOR: server: mark QUIC support as experimental Mark QUIC address support for servers as experimental on the backend side. Previously, it was allowed but wouldn't function as expected. As QUIC backend support requires several changes, it is better to declare it as experimental first.
2025-06-11 11:26:44 -04:00
if (srv_is_quic(newsrv)) {
MINOR: server: mark backend removal as forbidden if QUIC was used Currenly, quic_conn on the backend side may access their parent proxy instance during their lifetime. In particular, this is the case for counters update, with <prx_counters> field directly referencing a proxy memory zone. As such, this prevents safe backend removal. One solution would be to check if the upper connection instance is still alive, as a proxy cannot be removed if connection are still active. However, this would completely prevent proxy counters update via quic_conn_prx_cntrs_update(), as this is performed on quic_conn release. Another solution would be to use refcount, or a dedicated counter on the which account for QUIC connections on a backend instance. However, refcount is currently only used by short-term references, and it could also have a negative impact on performance. Thus, the simplest solution for now is to disable a backend removal if a QUIC server is/was used in it. This is considered acceptable for now as QUIC on the backend side is experimental.
2026-02-23 06:01:39 -05:00
/* TODO QUIC is currently incompatible with dynamic
* backends deletion. Please fix this before removing
* QUIC BE experimental status.
*/
MINOR: server: mark QUIC support as experimental Mark QUIC address support for servers as experimental on the backend side. Previously, it was allowed but wouldn't function as expected. As QUIC backend support requires several changes, it is better to declare it as experimental first.
2025-06-11 11:26:44 -04:00
if (!experimental_directives_allowed) {
ha_alert("QUIC is experimental for server '%s',"
" must be allowed via a global 'expose-experimental-directives'\n",
newsrv->id);
err_code |= ERR_ALERT | ERR_FATAL;
goto out;
}
MINOR: quic-be: QUIC backend XPRT and transport parameters init during parsing Add ->quic_params new member to server struct. Also set the ->xprt member of the server being initialized and initialize asap its transport parameters from _srv_parse_init().
2023-12-18 05:18:45 -05:00
MINOR: tree-wide: add missing TAINTED flags for some experimental directives We normally taint the process when using experimental directives, but a handful of places were missed so we don't always know that they are in use. Let's fix these places (hint for future directives, just look for places checking for "experimental_directives_allowed", and add "mark_tainted(TAINTED_CONFIG_EXP_KW_DECLARED);").
2025-10-17 11:57:40 -04:00
mark_tainted(TAINTED_CONFIG_EXP_KW_DECLARED);
MINOR: quic-be: QUIC backend XPRT and transport parameters init during parsing Add ->quic_params new member to server struct. Also set the ->xprt member of the server being initialized and initialize asap its transport parameters from _srv_parse_init().
2023-12-18 05:18:45 -05:00
newsrv->xprt = xprt_get(XPRT_QUIC);
quic_transport_params_init(&newsrv->quic_params, 0);
BUG/MINOR: config/server: reject QUIC addresses QUIC is not implemented on the backend side. To prevent any issue, it is better to reject any server configured which uses it. This is done via _srv_parse_init() which is used both for static and dynamic servers. This should be backported up to all stable versions.
2025-06-11 12:26:10 -04:00
}
MINOR: quic: Prevent QUIC backend use with the OpenSSL QUIC compatibility module (USE_OPENSS_COMPAT) Make the server line parsing fail when a QUIC backend is configured if haproxy is built to use the OpenSSL stack compatibility module. This latter does not support the QUIC client part.
2025-07-02 11:56:03 -04:00
#else
if (srv_is_quic(newsrv)) {
ha_alert("The SSL stack does not provide a support for QUIC server '%s'",
newsrv->id);
err_code |= ERR_ALERT | ERR_FATAL;
goto out;
}
#endif
BUG/MINOR: config/server: reject QUIC addresses QUIC is not implemented on the backend side. To prevent any issue, it is better to reject any server configured which uses it. This is done via _srv_parse_init() which is used both for static and dynamic servers. This should be backported up to all stable versions.
2025-06-11 12:26:10 -04:00
#endif
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
if (!port1 || !port2) {
MINOR: rhttp: large renaming to use rhttp prefix Previous commit renames 'proto_reverse_connect' module to 'proto_rhttp'. This commits follows this by replacing various custom prefix by 'rhttp_' to make the code uniform. Note that 'reverse_' prefix was kept in connection module. This is because if a new reversable protocol not based on HTTP is implemented, it may be necessary to reused the same connection function which are protocol agnostic.
2023-11-21 05:10:34 -05:00
if (sk->ss_family != AF_CUST_RHTTP_SRV) {
MINOR: server: convert @reverse to rev@ standard format Remove the recently introduced '@reverse' notation for HTTP reverse servers. Instead, reuse the 'rev@' prefix already defined for bind lines.
2023-10-19 05:07:15 -04:00
/* no port specified, +offset, -offset */
newsrv->flags |= SRV_F_MAPPORTS;
}
else {
MINOR: rhttp: large renaming to use rhttp prefix Previous commit renames 'proto_reverse_connect' module to 'proto_rhttp'. This commits follows this by replacing various custom prefix by 'rhttp_' to make the code uniform. Note that 'reverse_' prefix was kept in connection module. This is because if a new reversable protocol not based on HTTP is implemented, it may be necessary to reused the same connection function which are protocol agnostic.
2023-11-21 05:10:34 -05:00
newsrv->flags |= SRV_F_RHTTP;
MINOR: server: activate automatically check reuse for rhttp@ protocol Without check-reuse-pool, it is impossible to perform check on server using @rhttp protocol. This is due to the inherent nature of the protocol which does not implement an active connect method. Thus, ensure that check-reuse-pool is always set when a reverse HTTP server is declared. This reduces server configuration and should prevent any omission. Note that it is still require to add "check" server keyword so activate server checks.
2025-04-02 12:30:46 -04:00
/* Automatically activate check-reuse-pool for rhttp@ servers. */
newsrv->check.reuse_pool = 1;
MINOR: server: convert @reverse to rev@ standard format Remove the recently introduced '@reverse' notation for HTTP reverse servers. Instead, reuse the 'rev@' prefix already defined for bind lines.
2023-10-19 05:07:15 -04:00
}
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
}
REORG: cfgparse: move server keyword parsing to server.c The cfgparse.c file becomes huge, and a large part of it comes from the server keyword parser. Since the configuration is a bit more modular now, move this parser to server.c. This patch also moves the check of the "server" keyword earlier in the supported keywords list, resulting in a slightly faster config parsing for configs with large numbers of servers (about 10%). No functional change was made, only the code was moved.
2014-03-31 04:39:59 -04:00
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
/* save hostname and create associated name resolution */
if (fqdn) {
if (fqdn[0] == '_') { /* SRV record */
/* Check if a SRV request already exists, and if not, create it */
if ((newsrv->srvrq = find_srvrq_by_name(fqdn, curproxy)) == NULL)
newsrv->srvrq = new_resolv_srvrq(newsrv, fqdn);
if (newsrv->srvrq == NULL) {
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
err_code |= ERR_ALERT | ERR_FATAL;
goto out;
MINOR: dns: parse_server() now uses srv_alloc_dns_resolution() In order to make DNS code more consistent, the function parse_server() now uses srv_alloc_dns_resolution() to set up a server and its resolution.
2017-05-03 06:09:54 -04:00
}
BUG/MEDIUM: resolvers: Make 1st server of a template take part to SRV resolution The commit 3406766d5 ("MEDIUM: resolvers: add a ref between servers and srv request or used SRV record") introduced a regression. The first server of a template based on SRV record is no longer resolved. The same bug exists for a normal server based on a SRV record. In fact, the server used during parsing (used as reference when a server-template line is parsed) is never attached to the corresponding srvrq object. Thus with following lines, no resolution is performed because "srvrq->attached_servers" is empty: server-template test 1 _http.domain.tld resolvers dns ... server test1 _http.domain.tld resolvers dns ... This patch should fix the issue #1295 (but not confirmed yet it is the same bug). It must be backported everywhere the above commit is.
2021-06-29 14:52:35 -04:00
LIST_APPEND(&newsrv->srvrq->attached_servers, &newsrv->srv_rec_item);
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
}
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
else if (srv_prepare_for_resolution(newsrv, fqdn) == -1) {
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
ha_alert("Can't create DNS resolution for server '%s'\n",
newsrv->id);
REORG: cfgparse: move server keyword parsing to server.c The cfgparse.c file becomes huge, and a large part of it comes from the server keyword parser. Since the configuration is a bit more modular now, move this parser to server.c. This patch also moves the check of the "server" keyword earlier in the supported keywords list, resulting in a slightly faster config parsing for configs with large numbers of servers (about 10%). No functional change was made, only the code was moved.
2014-03-31 04:39:59 -04:00
err_code |= ERR_ALERT | ERR_FATAL;
goto out;
}
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
}
REORG: cfgparse: move server keyword parsing to server.c The cfgparse.c file becomes huge, and a large part of it comes from the server keyword parser. Since the configuration is a bit more modular now, move this parser to server.c. This patch also moves the check of the "server" keyword earlier in the supported keywords list, resulting in a slightly faster config parsing for configs with large numbers of servers (about 10%). No functional change was made, only the code was moved.
2014-03-31 04:39:59 -04:00
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
newsrv->addr = *sk;
newsrv->svc_port = port;
MINOR: server: add a alt_proto field for server Add a new field alt_proto to the server structures that specify if an alternate protocol should be used for this server. This field can be transparently passed to protocol_lookup to get an appropriate protocol structure. This change allows thus to create servers with different protocols, and not only TCP anymore.
2024-08-26 05:50:25 -04:00
newsrv->alt_proto = alt_proto;
BUG/MEDIUM: server: do not auto insert a dynamic server in px addr_node Until then, the servers were automatically attached on their creation into the proxy addr_node tree via _srv_parse_init. In case of an invalid dynamic server which is instantly freed, no detach operation was made leaving a NULL server in the tree. Change this mode of operation by marking the attach operation as optional in _srv_parse_init. This operation is not conduct for a dynamic server. The server is attached only at the end of the CLI handler when it is marked as valid. This must be backported up to 2.4.
2021-06-08 09:19:51 -04:00
/*
* we don't need to lock the server here, because
* we are in the process of initializing.
*
* Note that the server is not attached into the proxy tree if
* this is a dynamic server.
*/
srv_set_addr_desc(newsrv, !(parse_flags & SRV_PARSE_DYNAMIC));
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
MINOR: protocols: replace protocol_by_family() with protocol_lookup() At a few places we were still using protocol_by_family() instead of the richer protocol_lookup(). The former is limited as it enforces SOCK_STREAM and a stream protocol at the control layer. At least with protocol_lookup() we don't have this limitationn. The values were still set for now but later we can imagine making them configurable on the fly.
2021-10-27 11:41:07 -04:00
if (!newsrv->srvrq && !newsrv->hostname &&
!protocol_lookup(newsrv->addr.ss_family, PROTO_TYPE_STREAM, 0)) {
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
ha_alert("Unknown protocol family %d '%s'\n",
newsrv->addr.ss_family, args[*cur_arg]);
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
err_code |= ERR_ALERT | ERR_FATAL;
goto out;
REORG: cfgparse: move server keyword parsing to server.c The cfgparse.c file becomes huge, and a large part of it comes from the server keyword parser. Since the configuration is a bit more modular now, move this parser to server.c. This patch also moves the check of the "server" keyword earlier in the supported keywords list, resulting in a slightly faster config parsing for configs with large numbers of servers (about 10%). No functional change was made, only the code was moved.
2014-03-31 04:39:59 -04:00
}
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
(*cur_arg)++;
skip_addr:
MINOR: server: prepare parsing for dynamic servers Prepare the server parsing API to support dynamic servers. - define a new parsing flag to be used for dynamic servers - each keyword contains a new field dynamic_ok to indicate if it can be used for a dynamic server. For now, no keyword are supported. - do not copy settings from the default server for a new dynamic server. - a dynamic server is created in a maintenance mode and requires an explicit 'enable server' command. - a new server flag named SRV_F_DYNAMIC is created. This flag is set for all servers created at runtime. It might be useful later, for example to know if a server can be purged.
2021-03-08 11:08:01 -05:00
if (!(parse_flags & SRV_PARSE_DYNAMIC)) {
/* Copy default server settings to new server */
MEDIUM: proxy: take the defsrv out of the struct proxy The server struct has gone huge over time (~3.8kB), and having a copy of it in the defsrv section of the struct proxy costs a lot of RAM, that is not needed anymore at run time. This patch replaces this struct with a dynamically allocated one. The field is allocated and initialized during alloc_new_proxy() and is freed when the proxy is destroyed for now. But the goal will be to support freeing it after parsing the section.
2025-07-10 10:16:24 -04:00
srv_settings_cpy(newsrv, curproxy->defsrv, 0);
MEDIUM: counters: manage shared counters using dedicated helpers proxies, listeners and server shared counters are now managed via helpers added in one of the previous commits. When guid is not set (ie: when not yet assigned), shared counters pointer is allocated using calloc() (local memory) and a flag is set on the shared counters struct to know how to manipulate (and free it). Else if guid is set, then it means that the counters may be shared so while for now we don't actually use a shared memory location the API is ready for that. The way it works, for proxies and servers (for which guid is not known during creation), we first call counters_{fe,be}_shared_get with guid not set, which results in local pointer being retrieved (as if we just manually called calloc() to retrieve a pointer). Later (during postparsing) if guid is set we try to upgrade the pointer from local to shared. Lastly, since the memory location for some objects (proxies and servers counters) may change from creation to postparsing, let's update counters->last_change member directly under counters_{fe,be}_shared_get() so we don't miss it. No change of behavior is expected, this is only preparation work.
2025-05-07 17:42:04 -04:00
} else
BUG/MEDIUM: server: fix dynamic servers initial settings Contrary to static servers, dynamic servers does not initialize their settings from a default server instance. As such, _srv_parse_init() was responsible to set a set of minimal values to have a correct behavior. However, some settings were not properly initialized. This caused dynamic servers to not behave as static ones without explicit parameters. Currently, the main issue detected is connection reuse which was completely impossible. This is due to incorrect pool_purge_delay and max_reuse settings incompatible with srv_add_to_idle_list(). To fix the connection reuse, but also more generally to ensure dynamic servers are aligned with other server instances, define a new function srv_settings_init(). This is used to set initial values for both default servers and dynamic servers. For static servers, srv_settings_cpy() is kept instead, using their default server as reference. This patch could have unexpected effects on dynamic servers behavior as it restored proper initial settings. Previously, they were set to 0 via calloc() invocation from new_server(). This should be backported up to 2.6, after a brief period of observation.
2024-02-27 09:33:59 -05:00
srv_settings_init(newsrv);
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
HA_SPIN_INIT(&newsrv->lock);
}
else {
MINOR: proxy: add checks for defsrv's validity Now we only copy the default server's settings if such a default server exists, otherwise we only initialize it. At the moment it always exists. The change is mostly performed in srv_settings_cpy() since that's where each caller passes through, and there's no point duplicating that test everywhere.
2025-07-10 11:03:13 -04:00
/* This is a "default-server" line. Let's make certain the
* current proxy's default server exists, otherwise it's
* time to allocate it now.
*/
newsrv = curproxy->defsrv;
if (!newsrv) {
MEDIUM: server: introduce srv_alloc()/srv_free() to alloc/free a server It happens that we free servers at various places in the code, both on error paths and at runtime thanks to the "server delete" feature. In order to switch to an aligned struct, we'll need to change the calloc() and free() calls. Let's first spot them and switch them to srv_alloc() and srv_free() instead of using calloc() and either free() or ha_free(). An easy trap to fall into is that some of them are default-server entries. The new srv_free() function also resets the pointer like ha_free() does. This was done by running the following coccinelle script all over the code: @@ struct server *srv; @@ ( - free(srv) + srv_free(&srv) | - ha_free(&srv) + srv_free(&srv) ) @@ struct server *srv; expression e1; expression e2; @@ ( - srv = malloc(e1) + srv = srv_alloc() | - srv = calloc(e1, e2) + srv = srv_alloc() ) This is marked medium because despite spotting all call places, we can never rule out the possibility that some out-of-tree patches would allocate their own servers and continue to use the old API... at their own risk.
2025-08-13 05:52:59 -04:00
newsrv = srv_alloc();
MINOR: proxy: add checks for defsrv's validity Now we only copy the default server's settings if such a default server exists, otherwise we only initialize it. At the moment it always exists. The change is mostly performed in srv_settings_cpy() since that's where each caller passes through, and there's no point duplicating that test everywhere.
2025-07-10 11:03:13 -04:00
if (!newsrv) {
ha_alert("out of memory.\n");
err_code |= ERR_ALERT | ERR_ABORT;
goto out;
}
newsrv->id = "default-server";
srv_settings_init(newsrv);
curproxy->defsrv = newsrv;
}
*srv = newsrv;
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
*cur_arg = 1;
REORG: server: split parse_server The huge parse_server function is splitted into two smaller ones. * _srv_parse_init allocates a new server instance and parses the address parameter * _srv_parse_kw parse the current server keyword This simplify a bit the parse_server function. Besides, it will be useful for dynamic server creation.
2021-03-08 04:29:33 -05:00
}
REORG: cfgparse: move server keyword parsing to server.c The cfgparse.c file becomes huge, and a large part of it comes from the server keyword parser. Since the configuration is a bit more modular now, move this parser to server.c. This patch also moves the check of the "server" keyword earlier in the supported keywords list, resulting in a slightly faster config parsing for configs with large numbers of servers (about 10%). No functional change was made, only the code was moved.
2014-03-31 04:39:59 -04:00
REORG: server: split parse_server The huge parse_server function is splitted into two smaller ones. * _srv_parse_init allocates a new server instance and parses the address parameter * _srv_parse_kw parse the current server keyword This simplify a bit the parse_server function. Besides, it will be useful for dynamic server creation.
2021-03-08 04:29:33 -05:00
free(fqdn);
return 0;
REORG: cfgparse: move server keyword parsing to server.c The cfgparse.c file becomes huge, and a large part of it comes from the server keyword parser. Since the configuration is a bit more modular now, move this parser to server.c. This patch also moves the check of the "server" keyword earlier in the supported keywords list, resulting in a slightly faster config parsing for configs with large numbers of servers (about 10%). No functional change was made, only the code was moved.
2014-03-31 04:39:59 -04:00
REORG: server: split parse_server The huge parse_server function is splitted into two smaller ones. * _srv_parse_init allocates a new server instance and parses the address parameter * _srv_parse_kw parse the current server keyword This simplify a bit the parse_server function. Besides, it will be useful for dynamic server creation.
2021-03-08 04:29:33 -05:00
out:
free(fqdn);
return err_code;
}
REORG: cfgparse: move server keyword parsing to server.c The cfgparse.c file becomes huge, and a large part of it comes from the server keyword parser. Since the configuration is a bit more modular now, move this parser to server.c. This patch also moves the check of the "server" keyword earlier in the supported keywords list, resulting in a slightly faster config parsing for configs with large numbers of servers (about 10%). No functional change was made, only the code was moved.
2014-03-31 04:39:59 -04:00
REORG: server: split parse_server The huge parse_server function is splitted into two smaller ones. * _srv_parse_init allocates a new server instance and parses the address parameter * _srv_parse_kw parse the current server keyword This simplify a bit the parse_server function. Besides, it will be useful for dynamic server creation.
2021-03-08 04:29:33 -05:00
/* Parse the server keyword in <args>.
* <cur_arg> is incremented beyond the keyword optional value. Note that this
* might not be the case if an error is reported.
*
CLEANUP: assorted typo fixes in the code and comments This is 21st iteration of typo fixes
2021-03-19 13:21:44 -04:00
* This function is first intended to be used through parse_server to
REORG: server: split parse_server The huge parse_server function is splitted into two smaller ones. * _srv_parse_init allocates a new server instance and parses the address parameter * _srv_parse_kw parse the current server keyword This simplify a bit the parse_server function. Besides, it will be useful for dynamic server creation.
2021-03-08 04:29:33 -05:00
* initialize a new server on startup.
*
* A mask of errors is returned. ERR_FATAL is set if the parsing should be
* interrupted.
*/
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
static int _srv_parse_kw(struct server *srv, char **args, int *cur_arg,
struct proxy *curproxy,
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
int parse_flags)
REORG: server: split parse_server The huge parse_server function is splitted into two smaller ones. * _srv_parse_init allocates a new server instance and parses the address parameter * _srv_parse_kw parse the current server keyword This simplify a bit the parse_server function. Besides, it will be useful for dynamic server creation.
2021-03-08 04:29:33 -05:00
{
int err_code = 0;
struct srv_kw *kw;
const char *best;
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
char *errmsg = NULL;
REORG: server: split parse_server The huge parse_server function is splitted into two smaller ones. * _srv_parse_init allocates a new server instance and parses the address parameter * _srv_parse_kw parse the current server keyword This simplify a bit the parse_server function. Besides, it will be useful for dynamic server creation.
2021-03-08 04:29:33 -05:00
kw = srv_find_kw(args[*cur_arg]);
REORG: server: move alert traces in parse_server Move every ha_alert calls in parsing functions into parse_server. Parsing functions now support a pointer-to-string argument which will be allocated with an error message if needed via memprintf. parse_server has then the responsibility to display errors with ha_alert. This is groundwork for dynamic server. No traces should be printed on stderr as a response to a cli command. cli_err will replace ha_alert in this case.
2021-03-08 05:20:52 -05:00
if (!kw) {
best = srv_find_best_kw(args[*cur_arg]);
if (best)
MINOR: server: indicate when no address was expected for a server When parsing a peers section, it's particularly difficult to make the difference between the local peer which doesn't have any address, and other peers which need one, and the error messages do not help because with just: peers foo bind :8001 server foo 127.0.0.1:8001 server bar 127.0.0.2:8001 One can get such a confusing message when the local peer is "bar": [peers.cfg:15] : 'server foo/bar' : unknown keyword '127.0.0.1:8001'. It's not clear there why the other peer doesn't trigger an error. With this commit we add a hint in the error message when no address was expected. The error remains quite generic (since deep into the server code) but at least the useer gets a hint about why the keyword wasn't understood: [peers.cfg:15] : 'server foo/bar' : unknown keyword '127.0.0.1:8001'. Hint: no address was expected for this server.
2022-05-31 03:25:34 -04:00
ha_alert("unknown keyword '%s'; did you mean '%s' maybe ?%s\n",
args[*cur_arg], best,
(parse_flags & SRV_PARSE_PARSE_ADDR) ? "" :
" Hint: no address was expected for this server.");
REORG: server: move alert traces in parse_server Move every ha_alert calls in parsing functions into parse_server. Parsing functions now support a pointer-to-string argument which will be allocated with an error message if needed via memprintf. parse_server has then the responsibility to display errors with ha_alert. This is groundwork for dynamic server. No traces should be printed on stderr as a response to a cli command. cli_err will replace ha_alert in this case.
2021-03-08 05:20:52 -05:00
else
MINOR: server: indicate when no address was expected for a server When parsing a peers section, it's particularly difficult to make the difference between the local peer which doesn't have any address, and other peers which need one, and the error messages do not help because with just: peers foo bind :8001 server foo 127.0.0.1:8001 server bar 127.0.0.2:8001 One can get such a confusing message when the local peer is "bar": [peers.cfg:15] : 'server foo/bar' : unknown keyword '127.0.0.1:8001'. It's not clear there why the other peer doesn't trigger an error. With this commit we add a hint in the error message when no address was expected. The error remains quite generic (since deep into the server code) but at least the useer gets a hint about why the keyword wasn't understood: [peers.cfg:15] : 'server foo/bar' : unknown keyword '127.0.0.1:8001'. Hint: no address was expected for this server.
2022-05-31 03:25:34 -04:00
ha_alert("unknown keyword '%s'.%s\n", args[*cur_arg],
(parse_flags & SRV_PARSE_PARSE_ADDR) ? "" :
" Hint: no address was expected for this server.");
REORG: server: split parse_server The huge parse_server function is splitted into two smaller ones. * _srv_parse_init allocates a new server instance and parses the address parameter * _srv_parse_kw parse the current server keyword This simplify a bit the parse_server function. Besides, it will be useful for dynamic server creation.
2021-03-08 04:29:33 -05:00
REORG: server: move alert traces in parse_server Move every ha_alert calls in parsing functions into parse_server. Parsing functions now support a pointer-to-string argument which will be allocated with an error message if needed via memprintf. parse_server has then the responsibility to display errors with ha_alert. This is groundwork for dynamic server. No traces should be printed on stderr as a response to a cli command. cli_err will replace ha_alert in this case.
2021-03-08 05:20:52 -05:00
return ERR_ALERT | ERR_FATAL;
}
REORG: server: split parse_server The huge parse_server function is splitted into two smaller ones. * _srv_parse_init allocates a new server instance and parses the address parameter * _srv_parse_kw parse the current server keyword This simplify a bit the parse_server function. Besides, it will be useful for dynamic server creation.
2021-03-08 04:29:33 -05:00
REORG: server: move alert traces in parse_server Move every ha_alert calls in parsing functions into parse_server. Parsing functions now support a pointer-to-string argument which will be allocated with an error message if needed via memprintf. parse_server has then the responsibility to display errors with ha_alert. This is groundwork for dynamic server. No traces should be printed on stderr as a response to a cli command. cli_err will replace ha_alert in this case.
2021-03-08 05:20:52 -05:00
if (!kw->parse) {
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
ha_alert("'%s' option is not implemented in this version (check build options)\n",
args[*cur_arg]);
REORG: server: move alert traces in parse_server Move every ha_alert calls in parsing functions into parse_server. Parsing functions now support a pointer-to-string argument which will be allocated with an error message if needed via memprintf. parse_server has then the responsibility to display errors with ha_alert. This is groundwork for dynamic server. No traces should be printed on stderr as a response to a cli command. cli_err will replace ha_alert in this case.
2021-03-08 05:20:52 -05:00
err_code = ERR_ALERT | ERR_FATAL;
goto out;
REORG: server: split parse_server The huge parse_server function is splitted into two smaller ones. * _srv_parse_init allocates a new server instance and parses the address parameter * _srv_parse_kw parse the current server keyword This simplify a bit the parse_server function. Besides, it will be useful for dynamic server creation.
2021-03-08 04:29:33 -05:00
}
REORG: cfgparse: move server keyword parsing to server.c The cfgparse.c file becomes huge, and a large part of it comes from the server keyword parser. Since the configuration is a bit more modular now, move this parser to server.c. This patch also moves the check of the "server" keyword earlier in the supported keywords list, resulting in a slightly faster config parsing for configs with large numbers of servers (about 10%). No functional change was made, only the code was moved.
2014-03-31 04:39:59 -04:00
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
if ((parse_flags & SRV_PARSE_DEFAULT_SERVER) && !kw->default_ok) {
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
ha_alert("'%s' option is not accepted in default-server sections\n",
args[*cur_arg]);
REORG: server: move alert traces in parse_server Move every ha_alert calls in parsing functions into parse_server. Parsing functions now support a pointer-to-string argument which will be allocated with an error message if needed via memprintf. parse_server has then the responsibility to display errors with ha_alert. This is groundwork for dynamic server. No traces should be printed on stderr as a response to a cli command. cli_err will replace ha_alert in this case.
2021-03-08 05:20:52 -05:00
err_code = ERR_ALERT;
goto out;
}
MINOR: server: prepare parsing for dynamic servers Prepare the server parsing API to support dynamic servers. - define a new parsing flag to be used for dynamic servers - each keyword contains a new field dynamic_ok to indicate if it can be used for a dynamic server. For now, no keyword are supported. - do not copy settings from the default server for a new dynamic server. - a dynamic server is created in a maintenance mode and requires an explicit 'enable server' command. - a new server flag named SRV_F_DYNAMIC is created. This flag is set for all servers created at runtime. It might be useful later, for example to know if a server can be purged.
2021-03-08 11:08:01 -05:00
else if ((parse_flags & SRV_PARSE_DYNAMIC) && !kw->dynamic_ok) {
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
ha_alert("'%s' option is not accepted for dynamic server\n",
args[*cur_arg]);
MINOR: server: prepare parsing for dynamic servers Prepare the server parsing API to support dynamic servers. - define a new parsing flag to be used for dynamic servers - each keyword contains a new field dynamic_ok to indicate if it can be used for a dynamic server. For now, no keyword are supported. - do not copy settings from the default server for a new dynamic server. - a dynamic server is created in a maintenance mode and requires an explicit 'enable server' command. - a new server flag named SRV_F_DYNAMIC is created. This flag is set for all servers created at runtime. It might be useful later, for example to know if a server can be purged.
2021-03-08 11:08:01 -05:00
err_code |= ERR_ALERT;
goto out;
}
REORG: server: split parse_server The huge parse_server function is splitted into two smaller ones. * _srv_parse_init allocates a new server instance and parses the address parameter * _srv_parse_kw parse the current server keyword This simplify a bit the parse_server function. Besides, it will be useful for dynamic server creation.
2021-03-08 04:29:33 -05:00
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
err_code = kw->parse(args, cur_arg, curproxy, srv, &errmsg);
if (err_code) {
display_parser_err(NULL, 0, args, *cur_arg, err_code, &errmsg);
free(errmsg);
}
REORG: server: split parse_server The huge parse_server function is splitted into two smaller ones. * _srv_parse_init allocates a new server instance and parses the address parameter * _srv_parse_kw parse the current server keyword This simplify a bit the parse_server function. Besides, it will be useful for dynamic server creation.
2021-03-08 04:29:33 -05:00
out:
REORG: server: move alert traces in parse_server Move every ha_alert calls in parsing functions into parse_server. Parsing functions now support a pointer-to-string argument which will be allocated with an error message if needed via memprintf. parse_server has then the responsibility to display errors with ha_alert. This is groundwork for dynamic server. No traces should be printed on stderr as a response to a cli command. cli_err will replace ha_alert in this case.
2021-03-08 05:20:52 -05:00
if (kw->skip != -1)
*cur_arg += 1 + kw->skip;
REORG: server: split parse_server The huge parse_server function is splitted into two smaller ones. * _srv_parse_init allocates a new server instance and parses the address parameter * _srv_parse_kw parse the current server keyword This simplify a bit the parse_server function. Besides, it will be useful for dynamic server creation.
2021-03-08 04:29:33 -05:00
return err_code;
}
REORG: cfgparse: move server keyword parsing to server.c The cfgparse.c file becomes huge, and a large part of it comes from the server keyword parser. Since the configuration is a bit more modular now, move this parser to server.c. This patch also moves the check of the "server" keyword earlier in the supported keywords list, resulting in a slightly faster config parsing for configs with large numbers of servers (about 10%). No functional change was made, only the code was moved.
2014-03-31 04:39:59 -04:00
REORG: server: rename internal functions from parse_server Use a standard convention for the functions used through parse_server. Use the prefix _srv_parse and specify their private scope in a comment.
2021-03-17 09:25:39 -04:00
/* Server initializations finalization.
MINOR: server: Add parser support for set-proxy-v2-tlv-fmt This commit introduces a generic server-side parsing of type-value pair arguments and allocation of a TLV list via a new keyword called set-proxy-v2-tlv-fmt. This allows to 1) forward any TLV type with the help of fc_pp_tlv, 2) generally, send out any TLV type and value via a log format expression. To have this fully working the connection will need to be updated in a follow-up commit to actually respect the new server TLV list. default-server support has also been implemented.
2023-10-28 14:51:26 -04:00
* Initialize health check, agent check, SNI expression and outgoing TLVs if enabled.
REORG: server: rename internal functions from parse_server Use a standard convention for the functions used through parse_server. Use the prefix _srv_parse and specify their private scope in a comment.
2021-03-17 09:25:39 -04:00
* Must not be called for a default server instance.
*
CLEANUP: assorted typo fixes in the code and comments This is 21st iteration of typo fixes
2021-03-19 13:21:44 -04:00
* This function is first intended to be used through parse_server to
REORG: server: rename internal functions from parse_server Use a standard convention for the functions used through parse_server. Use the prefix _srv_parse and specify their private scope in a comment.
2021-03-17 09:25:39 -04:00
* initialize a new server on startup.
*/
static int _srv_parse_finalize(char **args, int cur_arg,
struct server *srv, struct proxy *px,
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
int parse_flags)
REORG: server: rename internal functions from parse_server Use a standard convention for the functions used through parse_server. Use the prefix _srv_parse and specify their private scope in a comment.
2021-03-17 09:25:39 -04:00
{
int ret;
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
char *errmsg = NULL;
MINOR: server: Add parser support for set-proxy-v2-tlv-fmt This commit introduces a generic server-side parsing of type-value pair arguments and allocation of a TLV list via a new keyword called set-proxy-v2-tlv-fmt. This allows to 1) forward any TLV type with the help of fc_pp_tlv, 2) generally, send out any TLV type and value via a log format expression. To have this fully working the connection will need to be updated in a follow-up commit to actually respect the new server TLV list. default-server support has also been implemented.
2023-10-28 14:51:26 -04:00
struct srv_pp_tlv_list *srv_tlv = NULL;
REORG: server: rename internal functions from parse_server Use a standard convention for the functions used through parse_server. Use the prefix _srv_parse and specify their private scope in a comment.
2021-03-17 09:25:39 -04:00
if (srv->do_check && srv->trackit) {
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
ha_alert("unable to enable checks and tracking at the same time!\n");
REORG: server: rename internal functions from parse_server Use a standard convention for the functions used through parse_server. Use the prefix _srv_parse and specify their private scope in a comment.
2021-03-17 09:25:39 -04:00
return ERR_ALERT | ERR_FATAL;
}
if (srv->do_agent && !srv->agent.port) {
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
ha_alert("server %s does not have agent port. Agent check has been disabled.\n",
srv->id);
REORG: server: rename internal functions from parse_server Use a standard convention for the functions used through parse_server. Use the prefix _srv_parse and specify their private scope in a comment.
2021-03-17 09:25:39 -04:00
return ERR_ALERT | ERR_FATAL;
}
MEDIUM: server/ssl: Base the SNI value to the HTTP host header by default For HTTPS outgoing connections, the SNI is now automatically set using the Host header value if no other value is already set (via the "sni" server keyword). It is now the default behavior. It could be disabled with the "no-sni-auto" server keyword. And eventually "sni-auto" server keyword may be used to reset any previous "no-sni-auto" setting. This option can be inherited from "default-server" settings. Finally, if no connection name is set via "pool-conn-name" setting, the selected value is used. The automatic selection of the SNI is enabled by default for all outgoing connections. But it is concretely used for HTTPS connections only. The expression used is "req.hdr(host),host_only". This patch should paritally fix the issue #3081. It only covers the server part. Another patch will add the feature for HTTP health-checks.
2025-09-04 04:12:19 -04:00
if ((ret = server_parse_exprs(srv, px, &errmsg))) {
MINOR: server: define pool-conn-name keyword Define a new server keyword pool-conn-name. The purpose of this keyword will be to identify connections inside the idle connections pool, replacing SNI in case SSL is not wanted. This keyword uses a sample expression argument. It thus can reuse existing function parse_srv_expr() for parsing. In the future, it may be necessary to define a keyword variant which uses a logformat for extensability. This patch only implement parsing. Argument is stored inside new server field <pool_conn_name> and expression is generated in _srv_parse_finalize() into <pool_conn_name_expr>. If pool-conn-name is not set but SNI is, the latter is reused automatically as pool-conn-name via _srv_parse_finalize(). This ensures current reuse behavior remains compatible and idle connection reuse will not mix connections with different SNIs by mistake. Main usage will be for rhttp when SSL is not wanted between the two haproxy instances. Previously, it was possible to use "sni" keyword even without SSL on a server line which have a similar effect. However, having a dedicated "pool-conn-name" keyword is deemed clearer. Besides, it would allow for more complex configuration where pool-conn-name and SNI are use in parallel with different values.
2024-05-23 05:14:13 -04:00
if (errmsg) {
MINOR: server: Parse sni and pool-conn-name expressions in a dedicated function This change is mandatory to fix an issue. The parsing of sni and pool-conn-name expressions (from string to expression) is now handled in a dedicated function. This will avoid to duplicate the same code at different places.
2025-09-03 08:45:07 -04:00
ha_alert("error detected while parsing sni or pool-conn-name expressions : %s.\n", errmsg);
MINOR: server: define pool-conn-name keyword Define a new server keyword pool-conn-name. The purpose of this keyword will be to identify connections inside the idle connections pool, replacing SNI in case SSL is not wanted. This keyword uses a sample expression argument. It thus can reuse existing function parse_srv_expr() for parsing. In the future, it may be necessary to define a keyword variant which uses a logformat for extensability. This patch only implement parsing. Argument is stored inside new server field <pool_conn_name> and expression is generated in _srv_parse_finalize() into <pool_conn_name_expr>. If pool-conn-name is not set but SNI is, the latter is reused automatically as pool-conn-name via _srv_parse_finalize(). This ensures current reuse behavior remains compatible and idle connection reuse will not mix connections with different SNIs by mistake. Main usage will be for rhttp when SSL is not wanted between the two haproxy instances. Previously, it was possible to use "sni" keyword even without SSL on a server line which have a similar effect. However, having a dedicated "pool-conn-name" keyword is deemed clearer. Besides, it would allow for more complex configuration where pool-conn-name and SNI are use in parallel with different values.
2024-05-23 05:14:13 -04:00
free(errmsg);
}
return ret;
}
MINOR: server: prepare parsing for dynamic servers Prepare the server parsing API to support dynamic servers. - define a new parsing flag to be used for dynamic servers - each keyword contains a new field dynamic_ok to indicate if it can be used for a dynamic server. For now, no keyword are supported. - do not copy settings from the default server for a new dynamic server. - a dynamic server is created in a maintenance mode and requires an explicit 'enable server' command. - a new server flag named SRV_F_DYNAMIC is created. This flag is set for all servers created at runtime. It might be useful later, for example to know if a server can be purged.
2021-03-08 11:08:01 -05:00
/* A dynamic server is disabled on startup. It must not be counted as
* an active backend entry.
*/
if (!(parse_flags & SRV_PARSE_DYNAMIC)) {
if (srv->flags & SRV_F_BACKUP)
px->srv_bck++;
else
px->srv_act++;
}
MINOR: server: Add parser support for set-proxy-v2-tlv-fmt This commit introduces a generic server-side parsing of type-value pair arguments and allocation of a TLV list via a new keyword called set-proxy-v2-tlv-fmt. This allows to 1) forward any TLV type with the help of fc_pp_tlv, 2) generally, send out any TLV type and value via a log format expression. To have this fully working the connection will need to be updated in a follow-up commit to actually respect the new server TLV list. default-server support has also been implemented.
2023-10-28 14:51:26 -04:00
list_for_each_entry(srv_tlv, &srv->pp_tlvs, list) {
if (srv_tlv->fmt_string && unlikely(!parse_logformat_string(srv_tlv->fmt_string,
srv->proxy, &srv_tlv->fmt, 0, SMP_VAL_BE_SRV_CON, &errmsg))) {
if (errmsg) {
ha_alert("%s\n", errmsg);
free(errmsg);
}
return ERR_ALERT | ERR_FATAL;
}
}
MINOR: server: reject QUIC servers without explicit SSL Report an error during server configuration if QUIC is used by SSL is not activiated via 'ssl' keyword. This is done in _srv_parse_finalize(), which is both used by static and dynamic servers. Note that contrary to listeners, an error is reported instead of a warning, and SSL is not automatically activated if missing. This is mainly due to the complex server configuration : _srv_parse_finalize() is ideal to affect every servers, including dynamic entries. However, it is executed after server SSL context allocation performed via <prepare_srv> XPRT operation. A proper fix would be to move SSL ctx alloc in _srv_parse_finalize(), but this may have unknown impact. Thus, for now a simpler solution has been chosen.
2025-06-12 10:16:43 -04:00
if (srv_is_quic(srv)) {
MINOR: quic: reject conf with QUIC servers if not compiled Ensure that QUIC support is compiled into haproxy when a QUIC server is configured. This check is performed during _srv_parse_finalize() so that it is detected both on configuration parsing and when adding a dynamic server via the CLI. Note that this changes the behavior of srv_is_quic() utility function. Previously, it always returned false when QUIC support wasn't compiled. With this new check introduced, it is now guaranteed that a QUIC server won't exist if compilation support is not active. Hence srv_is_quic() does not rely anymore on USE_QUIC define.
2025-10-31 04:57:54 -04:00
#ifdef USE_QUIC
MINOR: server: reject QUIC servers without explicit SSL Report an error during server configuration if QUIC is used by SSL is not activiated via 'ssl' keyword. This is done in _srv_parse_finalize(), which is both used by static and dynamic servers. Note that contrary to listeners, an error is reported instead of a warning, and SSL is not automatically activated if missing. This is mainly due to the complex server configuration : _srv_parse_finalize() is ideal to affect every servers, including dynamic entries. However, it is executed after server SSL context allocation performed via <prepare_srv> XPRT operation. A proper fix would be to move SSL ctx alloc in _srv_parse_finalize(), but this may have unknown impact. Thus, for now a simpler solution has been chosen.
2025-06-12 10:16:43 -04:00
if (!srv->use_ssl) {
MINOR: quic: enable SSL on QUIC servers automatically Previously, QUIC servers were rejected if SSL was not explicitely activated using 'ssl' configuration keyword. Change this behavior : now SSL is automatically activated for QUIC servers when the keyword is missing. A warning is displayed as it is considered better to explicitely note that SSL is in use.
2025-10-31 04:58:57 -04:00
srv->use_ssl = 1;
ha_warning("QUIC protocol detected, enabling ssl. Use 'ssl' to shut this warning.\n");
MINOR: server: reject QUIC servers without explicit SSL Report an error during server configuration if QUIC is used by SSL is not activiated via 'ssl' keyword. This is done in _srv_parse_finalize(), which is both used by static and dynamic servers. Note that contrary to listeners, an error is reported instead of a warning, and SSL is not automatically activated if missing. This is mainly due to the complex server configuration : _srv_parse_finalize() is ideal to affect every servers, including dynamic entries. However, it is executed after server SSL context allocation performed via <prepare_srv> XPRT operation. A proper fix would be to move SSL ctx alloc in _srv_parse_finalize(), but this may have unknown impact. Thus, for now a simpler solution has been chosen.
2025-06-12 10:16:43 -04:00
}
MINOR: quic-be: Set the backend alpn if not set by conf Simply set the alpn string to "h3,hq_interop" if there is no "alpn" setting for QUIC backends.
2025-07-03 14:53:00 -04:00
OPTIM: quic: adjust automatic ALPN setting for QUIC servers If a QUIC server is declared without ALPN, "h3" value is automatically set during _srv_parse_finalize(). This patch adjusts this operation. Instead of relying on ssl_sock_parse_alpn(), a plain strdup() is used. This is considered more efficient as the ALPN string is constant in this case. This method is already used for listeners on the frontend side.
2025-10-31 05:12:55 -04:00
if (!srv->ssl_ctx.alpn_str) {
srv->ssl_ctx.alpn_str = strdup("\002h3");
if (!srv->ssl_ctx.alpn_str) {
ha_alert("out of memory while trying to allocate a default alpn string.\n");
return ERR_ALERT | ERR_FATAL;
}
srv->ssl_ctx.alpn_len = strlen(srv->ssl_ctx.alpn_str);
MINOR: quic-be: Set the backend alpn if not set by conf Simply set the alpn string to "h3,hq_interop" if there is no "alpn" setting for QUIC backends.
2025-07-03 14:53:00 -04:00
}
MINOR: server: mark backend removal as forbidden if QUIC was used Currenly, quic_conn on the backend side may access their parent proxy instance during their lifetime. In particular, this is the case for counters update, with <prx_counters> field directly referencing a proxy memory zone. As such, this prevents safe backend removal. One solution would be to check if the upper connection instance is still alive, as a proxy cannot be removed if connection are still active. However, this would completely prevent proxy counters update via quic_conn_prx_cntrs_update(), as this is performed on quic_conn release. Another solution would be to use refcount, or a dedicated counter on the which account for QUIC connections on a backend instance. However, refcount is currently only used by short-term references, and it could also have a negative impact on performance. Thus, the simplest solution for now is to disable a backend removal if a QUIC server is/was used in it. This is considered acceptable for now as QUIC on the backend side is experimental.
2026-02-23 06:01:39 -05:00
/* Deletion of backend when QUIC servers were used is currently
* not implemented. This is because quic_conn instances
* directly references its parent proxy via <prx_counters>
* member.
*
* TODO lift this restriction by ensuring safe access on proxy
* counters or via refcount.
*/
srv->proxy->flags |= PR_FL_NON_PURGEABLE;
MINOR: quic: reject conf with QUIC servers if not compiled Ensure that QUIC support is compiled into haproxy when a QUIC server is configured. This check is performed during _srv_parse_finalize() so that it is detected both on configuration parsing and when adding a dynamic server via the CLI. Note that this changes the behavior of srv_is_quic() utility function. Previously, it always returned false when QUIC support wasn't compiled. With this new check introduced, it is now guaranteed that a QUIC server won't exist if compilation support is not active. Hence srv_is_quic() does not rely anymore on USE_QUIC define.
2025-10-31 04:57:54 -04:00
#else
ha_alert("QUIC protocol selected but support not compiled in (check build options).\n");
return ERR_ALERT | ERR_FATAL;
MINOR: server: reject QUIC servers without explicit SSL Report an error during server configuration if QUIC is used by SSL is not activiated via 'ssl' keyword. This is done in _srv_parse_finalize(), which is both used by static and dynamic servers. Note that contrary to listeners, an error is reported instead of a warning, and SSL is not automatically activated if missing. This is mainly due to the complex server configuration : _srv_parse_finalize() is ideal to affect every servers, including dynamic entries. However, it is executed after server SSL context allocation performed via <prepare_srv> XPRT operation. A proper fix would be to move SSL ctx alloc in _srv_parse_finalize(), but this may have unknown impact. Thus, for now a simpler solution has been chosen.
2025-06-12 10:16:43 -04:00
#endif
MINOR: quic: reject conf with QUIC servers if not compiled Ensure that QUIC support is compiled into haproxy when a QUIC server is configured. This check is performed during _srv_parse_finalize() so that it is detected both on configuration parsing and when adding a dynamic server via the CLI. Note that this changes the behavior of srv_is_quic() utility function. Previously, it always returned false when QUIC support wasn't compiled. With this new check introduced, it is now guaranteed that a QUIC server won't exist if compilation support is not active. Hence srv_is_quic() does not rely anymore on USE_QUIC define.
2025-10-31 04:57:54 -04:00
}
MINOR: server: reject QUIC servers without explicit SSL Report an error during server configuration if QUIC is used by SSL is not activiated via 'ssl' keyword. This is done in _srv_parse_finalize(), which is both used by static and dynamic servers. Note that contrary to listeners, an error is reported instead of a warning, and SSL is not automatically activated if missing. This is mainly due to the complex server configuration : _srv_parse_finalize() is ideal to affect every servers, including dynamic entries. However, it is executed after server SSL context allocation performed via <prepare_srv> XPRT operation. A proper fix would be to move SSL ctx alloc in _srv_parse_finalize(), but this may have unknown impact. Thus, for now a simpler solution has been chosen.
2025-06-12 10:16:43 -04:00
MEDIUM: server: move _srv_check_proxy_mode() checks from server init to finalize _srv_check_proxy_mode() is currently executed during server init (from _srv_parse_init()), while it used to be fine for current checks, it seems it occurs a bit too early to be usable for some checks that depend on server keywords to be evaluated for instance. As such, to make _srv_check_proxy_mode() more relevant and be extended with additional checks in the future, let's call it later during server finalization, once all server keywords were evaluated. No change of behavior is expected
2025-06-27 06:15:24 -04:00
if (!(srv->proxy->cap & PR_CAP_LB)) {
/* No need to wait for effective proxy mode, it is already known:
* Only general purpose user-declared proxies ("listen", "frontend", "backend")
* offer the possibility to configure the mode of the proxy. Hopefully for us,
* they have the PR_CAP_LB set.
*/
return _srv_check_proxy_mode(srv, 0);
}
REORG: server: rename internal functions from parse_server Use a standard convention for the functions used through parse_server. Use the prefix _srv_parse and specify their private scope in a comment.
2021-03-17 09:25:39 -04:00
srv_lb_commit_status(srv);
return 0;
}
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
int parse_server(const char *file, int linenum, char **args,
struct proxy *curproxy, const struct proxy *defproxy,
int parse_flags)
REORG: server: split parse_server The huge parse_server function is splitted into two smaller ones. * _srv_parse_init allocates a new server instance and parses the address parameter * _srv_parse_kw parse the current server keyword This simplify a bit the parse_server function. Besides, it will be useful for dynamic server creation.
2021-03-08 04:29:33 -05:00
{
struct server *newsrv = NULL;
int err_code = 0;
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
int cur_arg;
REORG: cfgparse: move server keyword parsing to server.c The cfgparse.c file becomes huge, and a large part of it comes from the server keyword parser. Since the configuration is a bit more modular now, move this parser to server.c. This patch also moves the check of the "server" keyword earlier in the supported keywords list, resulting in a slightly faster config parsing for configs with large numbers of servers (about 10%). No functional change was made, only the code was moved.
2014-03-31 04:39:59 -04:00
REORG: server: use parsing ctx for server parsing Use the parsing context in parse_server. Remove redundant manual format-string specifying the current file/line/server parsed.
2021-05-28 05:00:18 -04:00
set_usermsgs_ctx(file, linenum, NULL);
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
if (!(parse_flags & SRV_PARSE_DEFAULT_SERVER) && curproxy == defproxy) {
REORG: server: use parsing ctx for server parsing Use the parsing context in parse_server. Remove redundant manual format-string specifying the current file/line/server parsed.
2021-05-28 05:00:18 -04:00
ha_alert("'%s' not allowed in 'defaults' section.\n", args[0]);
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
err_code |= ERR_ALERT | ERR_FATAL;
goto out;
}
else if (failifnotcap(curproxy, PR_CAP_BE, file, linenum, args[0], NULL)) {
err_code |= ERR_ALERT | ERR_FATAL;
goto out;
}
REORG: server: move alert traces in parse_server Move every ha_alert calls in parsing functions into parse_server. Parsing functions now support a pointer-to-string argument which will be allocated with an error message if needed via memprintf. parse_server has then the responsibility to display errors with ha_alert. This is groundwork for dynamic server. No traces should be printed on stderr as a response to a cli command. cli_err will replace ha_alert in this case.
2021-03-08 05:20:52 -05:00
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
if ((parse_flags & (SRV_PARSE_IN_PEER_SECTION|SRV_PARSE_PARSE_ADDR)) ==
(SRV_PARSE_IN_PEER_SECTION|SRV_PARSE_PARSE_ADDR)) {
if (!*args[2])
BUG/MINOR: server: dont return immediately from parse_server() when skipping checks If parse_server() is called under peers section parser, and the address needs to be parsed but it is missing, we directly return from the function However since 0fc136ce5b ("REORG: server: use parsing ctx for server parsing"), parse_server() uses parsing ctx to emit warning/errors, and the ctx must be reset before returning from the function, yet this early return was overlooked. Because of that, any ha_{warning,alert..} message reported after early return from parse_server() could cause messages to have an extra "parsing [file:line]" info. We fix that by ensuring parse_server() doesn't return without resetting the parsing context. It should be backported up to 2.6
2025-03-07 03:11:21 -05:00
goto out;
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
}
REORG: server: attach servers in parse_server Move server linked into proxy backend list outside of _srv_parse_init to parse_server. This is groundwork for dynamic servers support. There will be two differences in case of a dynamic server : - the server will be attached to the proxy list only at the very end of the operations when everything is ok - the server will be directly attached to the end of the server proxy list
2021-03-08 10:35:54 -05:00
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
err_code = _srv_parse_init(&newsrv, args, &cur_arg, curproxy,
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
parse_flags);
REORG: server: split parse_server The huge parse_server function is splitted into two smaller ones. * _srv_parse_init allocates a new server instance and parses the address parameter * _srv_parse_kw parse the current server keyword This simplify a bit the parse_server function. Besides, it will be useful for dynamic server creation.
2021-03-08 04:29:33 -05:00
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
if (err_code & ERR_CODE)
goto out;
REORG: server: move alert traces in parse_server Move every ha_alert calls in parsing functions into parse_server. Parsing functions now support a pointer-to-string argument which will be allocated with an error message if needed via memprintf. parse_server has then the responsibility to display errors with ha_alert. This is groundwork for dynamic server. No traces should be printed on stderr as a response to a cli command. cli_err will replace ha_alert in this case.
2021-03-08 05:20:52 -05:00
BUG/MINOR: server: do not leak default-server in defaults sections When a default-server directive is used in a defaults section, it's never freed and the "defaults" proxy gets reset without freeing the fields from that default-server. Normally there are no allocation there, except for the config file location stored in srv->conf.file form an strdup() since commit 9394a9444 ("REORG: server: move alert traces in parse_server") that appeared in 2.4. In addition, if a "default-server" directive appears multiple times in a defaults section, one more entry will be leaked per call. This commit addresses this by checking that we don't overwrite the file upon multiple calls, and by clearing it when resetting the default proxy. This should be backported to 2.4.
2023-11-23 08:28:14 -05:00
if (!newsrv->conf.file) // note: do it only once for default-server
newsrv->conf.file = strdup(file);
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
newsrv->conf.line = linenum;
REORG: server: move alert traces in parse_server Move every ha_alert calls in parsing functions into parse_server. Parsing functions now support a pointer-to-string argument which will be allocated with an error message if needed via memprintf. parse_server has then the responsibility to display errors with ha_alert. This is groundwork for dynamic server. No traces should be printed on stderr as a response to a cli command. cli_err will replace ha_alert in this case.
2021-03-08 05:20:52 -05:00
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
while (*args[cur_arg]) {
err_code = _srv_parse_kw(newsrv, args, &cur_arg, curproxy,
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
parse_flags);
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
if (err_code & ERR_FATAL)
goto out;
}
REORG: server: split parse_server The huge parse_server function is splitted into two smaller ones. * _srv_parse_init allocates a new server instance and parses the address parameter * _srv_parse_kw parse the current server keyword This simplify a bit the parse_server function. Besides, it will be useful for dynamic server creation.
2021-03-08 04:29:33 -05:00
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
if (!(parse_flags & SRV_PARSE_DEFAULT_SERVER)) {
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
err_code |= _srv_parse_finalize(args, cur_arg, newsrv, curproxy, parse_flags);
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
if (err_code & ERR_FATAL)
goto out;
REORG: cfgparse: move server keyword parsing to server.c The cfgparse.c file becomes huge, and a large part of it comes from the server keyword parser. Since the configuration is a bit more modular now, move this parser to server.c. This patch also moves the check of the "server" keyword earlier in the supported keywords list, resulting in a slightly faster config parsing for configs with large numbers of servers (about 10%). No functional change was made, only the code was moved.
2014-03-31 04:39:59 -04:00
}
REORG: server: attach servers in parse_server Move server linked into proxy backend list outside of _srv_parse_init to parse_server. This is groundwork for dynamic servers support. There will be two differences in case of a dynamic server : - the server will be attached to the proxy list only at the very end of the operations when everything is ok - the server will be directly attached to the end of the server proxy list
2021-03-08 10:35:54 -05:00
BUG/MINOR: server: fix server_find_by_name() usage during parsing Since below commit, server_find_by_name() now search using 'used_server_id' proxy backend tree : 4bcfe30414005323a8d4ab986bce92bb736b59df OPTIM: server: eb lookup for server_find_by_name() This introduces a regression if server_find_by_name() is used via check_config_validity() during post-parsing. Indeed, used_server_id tree is populated at the same stage so it's possible to not found an existing server. This can cause incorrect rejection of previously valid configuration file. To fix this, servers are now inserted in used_server_id tree during parsing via parse_server(). This guarantees that server instances can be retrieved during post parsing. A known feature which uses server_find_by_name() during post parsing is attach-srv tcp-rule used for reverse HTTP. Prior to the current fix, a config was wrongly rejected if the rule was declared before the server line. This should not be backported unless the mentionned commit is.
2024-01-02 08:39:26 -05:00
if (parse_flags & SRV_PARSE_TEMPLATE) {
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
_srv_parse_tmpl_init(newsrv, curproxy);
BUG/MINOR: server: fix server_find_by_name() usage during parsing Since below commit, server_find_by_name() now search using 'used_server_id' proxy backend tree : 4bcfe30414005323a8d4ab986bce92bb736b59df OPTIM: server: eb lookup for server_find_by_name() This introduces a regression if server_find_by_name() is used via check_config_validity() during post-parsing. Indeed, used_server_id tree is populated at the same stage so it's possible to not found an existing server. This can cause incorrect rejection of previously valid configuration file. To fix this, servers are now inserted in used_server_id tree during parsing via parse_server(). This guarantees that server instances can be retrieved during post parsing. A known feature which uses server_find_by_name() during post parsing is attach-srv tcp-rule used for reverse HTTP. Prior to the current fix, a config was wrongly rejected if the rule was declared before the server line. This should not be backported unless the mentionned commit is.
2024-01-02 08:39:26 -05:00
}
else if (!(parse_flags & SRV_PARSE_DEFAULT_SERVER)) {
MEDIUM: server: switch conf.name to cebis_tree This is used to index the server name and it contains a copy of the pointer to the server's name in <id>. Changing that for a ceb_node placed just before <id> saves 32 bytes to the struct server, which remains 3968 bytes large due to alignment. The proxy struct shrinks by 8 bytes to 3144. It's worth noting that the current way duplicate names are handled remains based on the previous mechanism where dups were permitted. Ideally we should now reject them during insertion and use unique key trees instead.
2025-07-07 09:33:40 -04:00
cebis_item_insert(&curproxy->conf.used_server_name, conf.name_node, id, newsrv);
BUG/MINOR: server: fix server_find_by_name() usage during parsing Since below commit, server_find_by_name() now search using 'used_server_id' proxy backend tree : 4bcfe30414005323a8d4ab986bce92bb736b59df OPTIM: server: eb lookup for server_find_by_name() This introduces a regression if server_find_by_name() is used via check_config_validity() during post-parsing. Indeed, used_server_id tree is populated at the same stage so it's possible to not found an existing server. This can cause incorrect rejection of previously valid configuration file. To fix this, servers are now inserted in used_server_id tree during parsing via parse_server(). This guarantees that server instances can be retrieved during post parsing. A known feature which uses server_find_by_name() during post parsing is attach-srv tcp-rule used for reverse HTTP. Prior to the current fix, a config was wrongly rejected if the rule was declared before the server line. This should not be backported unless the mentionned commit is.
2024-01-02 08:39:26 -05:00
}
REORG: server: use flags for parse_server Modify the API of parse_server function. Use flags to describe the type of the parsed server instead of discrete arguments. These flags can be used to specify if a server/default-server/server-template is parsed. Additional parameters are also specified (parsing of the address required, resolve of a name must be done immediately). It is now unneeded to use strcmp on args[0] in parse_server. Also, the calls to parse_server are more explicit thanks to the flags.
2021-03-08 10:36:46 -05:00
BUG/MINOR: server: do not keep an invalid dynamic server in px ids tree A bug is present when trying to create a dynamic server with a fixed id. If the server is detected invalid due to a later parsing arguments error, the server is not removed from the proxy used ids tree before being freed. Change the mode of operation of 'id' keyword parsing handler. The insertion in the backend tree is removed from the handler and is not taken in charge by parse_server for configuration parsing. For the dynamic servers, the insertion is called at the end of the 'add server' CLI handler when the server has been validated. This must be backported up to 2.4.
2021-06-08 11:00:20 -04:00
/* If the server id is fixed, insert it in the proxy used_id tree.
* This is needed to detect a later duplicate id via srv_parse_id.
*
* If no is specified, a dynamic one is generated in
* check_config_validity.
*/
if (newsrv->flags & SRV_F_FORCED_ID)
MINOR: server: add server_index_id() to index a server by its ID This avoids needlessly exposing the tree's root and the mechanics outside of the low-level code.
2025-08-23 13:33:52 -04:00
server_index_id(curproxy, newsrv);
BUG/MINOR: server: do not keep an invalid dynamic server in px ids tree A bug is present when trying to create a dynamic server with a fixed id. If the server is detected invalid due to a later parsing arguments error, the server is not removed from the proxy used ids tree before being freed. Change the mode of operation of 'id' keyword parsing handler. The insertion in the backend tree is removed from the handler and is not taken in charge by parse_server for configuration parsing. For the dynamic servers, the insertion is called at the end of the 'add server' CLI handler when the server has been validated. This must be backported up to 2.4.
2021-06-08 11:00:20 -04:00
BUG/MINOR: server: do not report diag for peer servers with null weight Only check servers attached to a proxy with PR_CAP_LB. This does not need to be backported as the diag message was added in the current 2.4-dev branch.
2021-05-07 09:13:51 -04:00
HA_DIAG_WARNING_COND((curproxy->cap & PR_CAP_LB) && !newsrv->uweight,
REORG: server: use parsing ctx for server parsing Use the parsing context in parse_server. Remove redundant manual format-string specifying the current file/line/server parsed.
2021-05-28 05:00:18 -04:00
"configured with weight of 0 will never be selected by load balancing algorithms\n");
MINOR: server: diag for 0 weight server Output a diagnostic report if a server has been configured with a null weight.
2021-03-30 04:26:27 -04:00
REORG: server: use parsing ctx for server parsing Use the parsing context in parse_server. Remove redundant manual format-string specifying the current file/line/server parsed.
2021-05-28 05:00:18 -04:00
reset_usermsgs_ctx();
REORG: cfgparse: move server keyword parsing to server.c The cfgparse.c file becomes huge, and a large part of it comes from the server keyword parser. Since the configuration is a bit more modular now, move this parser to server.c. This patch also moves the check of the "server" keyword earlier in the supported keywords list, resulting in a slightly faster config parsing for configs with large numbers of servers (about 10%). No functional change was made, only the code was moved.
2014-03-31 04:39:59 -04:00
return 0;
out:
REORG: server: use parsing ctx for server parsing Use the parsing context in parse_server. Remove redundant manual format-string specifying the current file/line/server parsed.
2021-05-28 05:00:18 -04:00
reset_usermsgs_ctx();
REORG: cfgparse: move server keyword parsing to server.c The cfgparse.c file becomes huge, and a large part of it comes from the server keyword parser. Since the configuration is a bit more modular now, move this parser to server.c. This patch also moves the check of the "server" keyword earlier in the supported keywords list, resulting in a slightly faster config parsing for configs with large numbers of servers (about 10%). No functional change was made, only the code was moved.
2014-03-31 04:39:59 -04:00
return err_code;
}
OPTIM: server: ebtree lookups for findserver_unique_* functions 4e5e2664 ("MINOR: proxy: add findserver_unique_id() and findserver_unique_name()") added findserver_unique_id() and findserver_unique_name() functions that were inspired from the historical findserver() function, so unfortunately they don't perform well when used on large backend farms because they scan the whole server list linearly. I was about to provide a patch to optimize such functions when I stumbled on Baptiste's work: 19a106d24 ("MINOR: server: server_find functions: id, name, best_match") It turns out Baptiste already implemented helper functions to supersed the unoptimized findserver() function (at least at runtime when servers have been assigned their final IDs and inserted in the lookup trees): they offer more matching options and rely on eb lookups so they are much more suitable for fast queries. I don't know how I missed that, but they are a perfect base for the server rid matching functions. So in this patch, we essentially revert 4e5e2664 to provide the optimized equivalent functions named server_find_by_id_unique() and server_find_by_name_unique(), then we force existing findserver_unique_*() callers to switch to the new functions. This patch depends on: - "OPTIM: server: eb lookup for server_find_by_name()" This could be backported up to 2.8.
2023-12-04 11:00:18 -05:00
/*
* This function finds a server with matching "<puid> x <rid>" within
* selected backend <bk>.
* Using the combination of proxy-uid + revision id ensures that the function
* will either return the server we're expecting or NULL if it has been removed
* from the proxy (<id> is unique within the list, but it is not true over the
* process lifetime as new servers may reuse the id of a previously deleted
* server).
*/
struct server *server_find_by_id_unique(struct proxy *bk, int id, uint32_t rid)
{
struct server *curserver;
curserver = server_find_by_id(bk, id);
if (!curserver || curserver->rid != rid)
return NULL;
return curserver;
}
REORG: server: move findserver() from proxy.c to server.c The reason this function was overlooked is that it had mostly equivalent ones in server.c, let's move them together.
2025-07-10 04:56:34 -04:00
/*
* This function returns the server with a matching name within selected proxy,
* or NULL if not found.
*/
CLEANUP: server: rename findserver() to server_find_by_name() Now it's more logical and matches what is done in the rest of these functions. server_find() now relies on it.
2025-07-10 05:07:51 -04:00
struct server *server_find_by_name(struct proxy *px, const char *name)
REORG: server: move findserver() from proxy.c to server.c The reason this function was overlooked is that it had mostly equivalent ones in server.c, let's move them together.
2025-07-10 04:56:34 -04:00
{
if (!px)
return NULL;
MEDIUM: server: switch conf.name to cebis_tree This is used to index the server name and it contains a copy of the pointer to the server's name in <id>. Changing that for a ceb_node placed just before <id> saves 32 bytes to the struct server, which remains 3968 bytes large due to alignment. The proxy struct shrinks by 8 bytes to 3144. It's worth noting that the current way duplicate names are handled remains based on the previous mechanism where dups were permitted. Ideally we should now reject them during insertion and use unique key trees instead.
2025-07-07 09:33:40 -04:00
return cebis_item_lookup(&px->conf.used_server_name, conf.name_node, id, name, struct server);
REORG: server: move findserver() from proxy.c to server.c The reason this function was overlooked is that it had mostly equivalent ones in server.c, let's move them together.
2025-07-10 04:56:34 -04:00
}
CLEANUP: server: add server_find_by_addr() Server lookup by address requires locking and manipulation of the tree from user code. Let's provide server_find_by_addr() which does that for us.
2025-07-10 08:43:28 -04:00
/*
* This function returns the server with a matching address within selected
* proxy, or NULL if not found. The proxy lock is taken for reads during this
* operation since we don't want the address to change under us.
*/
struct server *server_find_by_addr(struct proxy *px, const char *addr)
{
struct server *cursrv;
HA_RWLOCK_RDLOCK(PROXY_LOCK, &px->lock);
MEDIUM: server: switch addr_node to cebis_tree This contains the text representation of the server's address, for use with stick-tables with "srvkey addr". Switching them to a compact node saves 24 more bytes from this structure. The key was moved to an external pointer "addr_key" right after the node. The server struct is now 3968 bytes (down from 4032) due to alignment, and the proxy struct shrinks by 8 bytes to 3152.
2025-07-07 09:13:15 -04:00
cursrv = cebuis_item_lookup(&px->used_server_addr, addr_node, addr_key, addr, struct server);
CLEANUP: server: add server_find_by_addr() Server lookup by address requires locking and manipulation of the tree from user code. Let's provide server_find_by_addr() which does that for us.
2025-07-10 08:43:28 -04:00
HA_RWLOCK_RDUNLOCK(PROXY_LOCK, &px->lock);
return cursrv;
}
MINOR: server: server_find functions: id, name, best_match This patch introduces three new functions which can be used to find a server in a farm using different server information: - server unique id (srv->puid) - server name - find best match using either name or unique id When performing best matching, the following applies: - use the server name first (if provided) - use the server id if provided in any case, the function can update the caller about mismatches encountered.
2015-07-08 16:03:56 -04:00
/* Returns a pointer to the first server matching either name <name>, or id
* if <name> starts with a '#'. NULL is returned if no match is found.
* the lookup is performed in the backend <bk>
*/
CLEANUP: server: rename server_find_by_name() to server_find() This function doesn't just look at the name but also the ID when the argument starts with a '#'. So the name is not correct and explains why this function is not always used when the name only is needed, and why the list-based findserver() is used instead. So let's just call the function "server_find()", and rename its generation-id based cousin "server_find_unique()".
2025-07-10 04:59:06 -04:00
struct server *server_find(struct proxy *bk, const char *name)
MINOR: server: server_find functions: id, name, best_match This patch introduces three new functions which can be used to find a server in a farm using different server information: - server unique id (srv->puid) - server name - find best match using either name or unique id When performing best matching, the following applies: - use the server name first (if provided) - use the server id if provided in any case, the function can update the caller about mismatches encountered.
2015-07-08 16:03:56 -04:00
{
struct server *curserver;
if (!bk || !name)
return NULL;
/* <bk> has no backend capabilities, so it can't have a server */
if (!(bk->cap & PR_CAP_BE))
return NULL;
curserver = NULL;
if (*name == '#') {
curserver = server_find_by_id(bk, atoi(name + 1));
}
else {
CLEANUP: server: use server_find_by_name() where relevant Instead of open-coding a tree lookup, in sticking rules and server_find(), let's just rely on server_find_by_name() which now does exactly the same.
2025-07-10 05:10:36 -04:00
curserver = server_find_by_name(bk, name);
MINOR: server: server_find functions: id, name, best_match This patch introduces three new functions which can be used to find a server in a farm using different server information: - server unique id (srv->puid) - server name - find best match using either name or unique id When performing best matching, the following applies: - use the server name first (if provided) - use the server id if provided in any case, the function can update the caller about mismatches encountered.
2015-07-08 16:03:56 -04:00
}
OPTIM: server: eb lookup for server_find_by_name() server_find_by_name() function was added in 19a106d24 ("MINOR: server: server_find functions: id, name, best_match"). At that time, only the used_server_id proxy tree was available, thus the name lookup was performed as a linear search. However, used_server_name proxy tree was added in 84d6046a ("MINOR: proxy: Add a "server by name" tree to proxy."), so we may safely rely on it to perform server name lookups now. This will hopefully make the function quite faster, especially when performing lookups in huge backend farms.
2023-12-04 12:40:36 -05:00
return curserver;
MINOR: server: server_find functions: id, name, best_match This patch introduces three new functions which can be used to find a server in a farm using different server information: - server unique id (srv->puid) - server name - find best match using either name or unique id When performing best matching, the following applies: - use the server name first (if provided) - use the server id if provided in any case, the function can update the caller about mismatches encountered.
2015-07-08 16:03:56 -04:00
}
OPTIM: server: ebtree lookups for findserver_unique_* functions 4e5e2664 ("MINOR: proxy: add findserver_unique_id() and findserver_unique_name()") added findserver_unique_id() and findserver_unique_name() functions that were inspired from the historical findserver() function, so unfortunately they don't perform well when used on large backend farms because they scan the whole server list linearly. I was about to provide a patch to optimize such functions when I stumbled on Baptiste's work: 19a106d24 ("MINOR: server: server_find functions: id, name, best_match") It turns out Baptiste already implemented helper functions to supersed the unoptimized findserver() function (at least at runtime when servers have been assigned their final IDs and inserted in the lookup trees): they offer more matching options and rely on eb lookups so they are much more suitable for fast queries. I don't know how I missed that, but they are a perfect base for the server rid matching functions. So in this patch, we essentially revert 4e5e2664 to provide the optimized equivalent functions named server_find_by_id_unique() and server_find_by_name_unique(), then we force existing findserver_unique_*() callers to switch to the new functions. This patch depends on: - "OPTIM: server: eb lookup for server_find_by_name()" This could be backported up to 2.8.
2023-12-04 11:00:18 -05:00
/*
* This function finds a server with matching "<name> x <rid>" within
* selected backend <bk>.
* Using the combination of name + revision id ensures that the function
* will either return the server we're expecting or NULL if it has been removed
* from the proxy. For this we assume that <name> is unique within the list,
* which is the case in most setups, but in rare cases the user may have
* enforced duplicate server names in the initial config (ie: if he intends to
CLEANUP: assorted typo fixes in the code and comments This is 38th iteration of typo fixes
2023-12-29 14:05:20 -05:00
* use numerical IDs for identification instead). In this particular case, the
OPTIM: server: ebtree lookups for findserver_unique_* functions 4e5e2664 ("MINOR: proxy: add findserver_unique_id() and findserver_unique_name()") added findserver_unique_id() and findserver_unique_name() functions that were inspired from the historical findserver() function, so unfortunately they don't perform well when used on large backend farms because they scan the whole server list linearly. I was about to provide a patch to optimize such functions when I stumbled on Baptiste's work: 19a106d24 ("MINOR: server: server_find functions: id, name, best_match") It turns out Baptiste already implemented helper functions to supersed the unoptimized findserver() function (at least at runtime when servers have been assigned their final IDs and inserted in the lookup trees): they offer more matching options and rely on eb lookups so they are much more suitable for fast queries. I don't know how I missed that, but they are a perfect base for the server rid matching functions. So in this patch, we essentially revert 4e5e2664 to provide the optimized equivalent functions named server_find_by_id_unique() and server_find_by_name_unique(), then we force existing findserver_unique_*() callers to switch to the new functions. This patch depends on: - "OPTIM: server: eb lookup for server_find_by_name()" This could be backported up to 2.8.
2023-12-04 11:00:18 -05:00
* function will not work as expected so server_find_by_id_unique() should be
* used to match a unique server instead.
*
* Just like server_find_by_id_unique(), if a server is deleted and a new server
* reuses the same name, the rid check will prevent the function from returning
* a different server from the one we were expecting to match against at a given
* time.
*/
CLEANUP: server: rename server_find_by_name() to server_find() This function doesn't just look at the name but also the ID when the argument starts with a '#'. So the name is not correct and explains why this function is not always used when the name only is needed, and why the list-based findserver() is used instead. So let's just call the function "server_find()", and rename its generation-id based cousin "server_find_unique()".
2025-07-10 04:59:06 -04:00
struct server *server_find_unique(struct proxy *bk, const char *name, uint32_t rid)
OPTIM: server: ebtree lookups for findserver_unique_* functions 4e5e2664 ("MINOR: proxy: add findserver_unique_id() and findserver_unique_name()") added findserver_unique_id() and findserver_unique_name() functions that were inspired from the historical findserver() function, so unfortunately they don't perform well when used on large backend farms because they scan the whole server list linearly. I was about to provide a patch to optimize such functions when I stumbled on Baptiste's work: 19a106d24 ("MINOR: server: server_find functions: id, name, best_match") It turns out Baptiste already implemented helper functions to supersed the unoptimized findserver() function (at least at runtime when servers have been assigned their final IDs and inserted in the lookup trees): they offer more matching options and rely on eb lookups so they are much more suitable for fast queries. I don't know how I missed that, but they are a perfect base for the server rid matching functions. So in this patch, we essentially revert 4e5e2664 to provide the optimized equivalent functions named server_find_by_id_unique() and server_find_by_name_unique(), then we force existing findserver_unique_*() callers to switch to the new functions. This patch depends on: - "OPTIM: server: eb lookup for server_find_by_name()" This could be backported up to 2.8.
2023-12-04 11:00:18 -05:00
{
struct server *curserver;
CLEANUP: server: rename server_find_by_name() to server_find() This function doesn't just look at the name but also the ID when the argument starts with a '#'. So the name is not correct and explains why this function is not always used when the name only is needed, and why the list-based findserver() is used instead. So let's just call the function "server_find()", and rename its generation-id based cousin "server_find_unique()".
2025-07-10 04:59:06 -04:00
curserver = server_find(bk, name);
OPTIM: server: ebtree lookups for findserver_unique_* functions 4e5e2664 ("MINOR: proxy: add findserver_unique_id() and findserver_unique_name()") added findserver_unique_id() and findserver_unique_name() functions that were inspired from the historical findserver() function, so unfortunately they don't perform well when used on large backend farms because they scan the whole server list linearly. I was about to provide a patch to optimize such functions when I stumbled on Baptiste's work: 19a106d24 ("MINOR: server: server_find functions: id, name, best_match") It turns out Baptiste already implemented helper functions to supersed the unoptimized findserver() function (at least at runtime when servers have been assigned their final IDs and inserted in the lookup trees): they offer more matching options and rely on eb lookups so they are much more suitable for fast queries. I don't know how I missed that, but they are a perfect base for the server rid matching functions. So in this patch, we essentially revert 4e5e2664 to provide the optimized equivalent functions named server_find_by_id_unique() and server_find_by_name_unique(), then we force existing findserver_unique_*() callers to switch to the new functions. This patch depends on: - "OPTIM: server: eb lookup for server_find_by_name()" This could be backported up to 2.8.
2023-12-04 11:00:18 -05:00
if (!curserver || curserver->rid != rid)
return NULL;
return curserver;
}
MINOR: server: server_find functions: id, name, best_match This patch introduces three new functions which can be used to find a server in a farm using different server information: - server unique id (srv->puid) - server name - find best match using either name or unique id When performing best matching, the following applies: - use the server name first (if provided) - use the server id if provided in any case, the function can update the caller about mismatches encountered.
2015-07-08 16:03:56 -04:00
struct server *server_find_best_match(struct proxy *bk, char *name, int id, int *diff)
{
struct server *byname;
struct server *byid;
if (!name && !id)
return NULL;
if (diff)
*diff = 0;
byname = byid = NULL;
if (name) {
CLEANUP: server: rename server_find_by_name() to server_find() This function doesn't just look at the name but also the ID when the argument starts with a '#'. So the name is not correct and explains why this function is not always used when the name only is needed, and why the list-based findserver() is used instead. So let's just call the function "server_find()", and rename its generation-id based cousin "server_find_unique()".
2025-07-10 04:59:06 -04:00
byname = server_find(bk, name);
MINOR: server: server_find functions: id, name, best_match This patch introduces three new functions which can be used to find a server in a farm using different server information: - server unique id (srv->puid) - server name - find best match using either name or unique id When performing best matching, the following applies: - use the server name first (if provided) - use the server id if provided in any case, the function can update the caller about mismatches encountered.
2015-07-08 16:03:56 -04:00
if (byname && (!id || byname->puid == id))
return byname;
}
/* remaining possibilities :
* - name not set
* - name set but not found
* - name found but ID doesn't match
*/
if (id) {
byid = server_find_by_id(bk, id);
if (byid) {
if (byname) {
/* use id only if forced by configuration */
if (byid->flags & SRV_F_FORCED_ID) {
if (diff)
*diff |= 2;
return byid;
}
else {
if (diff)
*diff |= 1;
return byname;
}
}
/* remaining possibilities:
* - name not set
* - name set but not found
*/
if (name && diff)
*diff |= 2;
return byid;
}
/* id bot found */
if (byname) {
if (diff)
*diff |= 1;
return byname;
}
}
return NULL;
}
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
/* This functions retrieves server's addr and port to fill
* <inetaddr> struct passed as argument.
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
*
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
* This may only be used under inet context.
MEDIUM: server: add support for changing a server's address Ability to change a server IP address during HAProxy run time. For now this is provided via function update_server_addr() which currently is not called. A log is emitted on each change. For now we do it inconditionally, but later we'll want to do it only on certain circumstances, which explains why the logging block is enclosed in if(1).
2015-04-13 19:13:07 -04:00
*/
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
void server_get_inetaddr(struct server *s, struct server_inetaddr *inetaddr)
MEDIUM: server: add support for changing a server's address Ability to change a server IP address during HAProxy run time. For now this is provided via function update_server_addr() which currently is not called. A log is emitted on each change. For now we do it inconditionally, but later we'll want to do it only on certain circumstances, which explains why the logging block is enclosed in if(1).
2015-04-13 19:13:07 -04:00
{
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
struct sockaddr_storage *addr = &s->addr;
unsigned int port = s->svc_port;
uint8_t mapports = !!(s->flags & SRV_F_MAPPORTS);
MINOR: server/event_hdl: add SERVER_INETADDR event In this patch we add the support for a new SERVER event in the event_hdl API. SERVER_INETADDR is implemented as an advanced server event. It is published each time the server's ip address or port is about to change. (ie: from the cli, dns, lua...) SERVER_INETADDR data is an event_hdl_cb_data_server_inetaddr struct that provides additional info related to the server inet addr change, but can be casted as a regular event_hdl_cb_data_server struct if additional info is not needed.
2023-11-10 14:12:00 -05:00
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
/* only INET families are supported */
BUG_ON((addr->ss_family != AF_UNSPEC &&
addr->ss_family != AF_INET && addr->ss_family != AF_INET6));
inetaddr->family = addr->ss_family;
memset(&inetaddr->addr, 0, sizeof(inetaddr->addr));
BUG/MEDIUM: dns: Be sure to renew IP address for already known servers When a SRV record for an already known server is processed, only the weight is updated, if not configured to be ignored. It is a problem if the IP address carried by the associated additional record changes. Because the server IP address is never renewed. To fix this bug, If there is an addition record attached to a SRV record, we always try to set the IP address. If it is the same, no change is performed. This way, IP changes are always handled. This patch should fix the issue #841. It must be backported to 2.2.
2020-09-08 04:27:24 -04:00
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
if (addr->ss_family == AF_INET)
inetaddr->addr.v4 =
((struct sockaddr_in *)addr)->sin_addr;
else if (addr->ss_family == AF_INET6)
inetaddr->addr.v6 =
((struct sockaddr_in6 *)addr)->sin6_addr;
MEDIUM: server: add support for changing a server's address Ability to change a server IP address during HAProxy run time. For now this is provided via function update_server_addr() which currently is not called. A log is emitted on each change. For now we do it inconditionally, but later we'll want to do it only on certain circumstances, which explains why the logging block is enclosed in if(1).
2015-04-13 19:13:07 -04:00
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
inetaddr->port.svc = port;
inetaddr->port.map = mapports;
}
MEDIUM: server: add support for changing a server's address Ability to change a server IP address during HAProxy run time. For now this is provided via function update_server_addr() which currently is not called. A log is emitted on each change. For now we do it inconditionally, but later we'll want to do it only on certain circumstances, which explains why the logging block is enclosed in if(1).
2015-04-13 19:13:07 -04:00
MEDIUM: server: make server_set_inetaddr() updater serializable server_set_inetaddr() updater argument is a simple char * string containing infos about the caller responsible for the update. In this patch, we try to make this argument serializable, that is, make it so that we can easily export it without having to keep the original pointer passed by the caller or having to work with strings of variable lengths. This was a prerequisite for exposing more updater information through SERVER_INETADDR event (upcoming patch). Static strings were simply mapped to a fixed ID that can be converted back to a string when needed using server_inetaddr_updater_by_to_str(). One special case one made for the SERVER_INETADDR_UPDATER_DNS_RESOLVER updater since in this case the updater hint has to be generated from the corresponding resolver id / nameserver id combination. This was achieved by saving the nameserver id within the updater struct. Knowing that the resolver id can be guessed from the server struct directly, it was not exposed through the updater struct. This patch depends on: - "MINOR: resolvers: add unique numeric id to nameservers" No functional change should be expected.
2023-12-11 09:06:43 -05:00
/* get human readable name for server_inetaddr_updater .by struct member
*/
const char *server_inetaddr_updater_by_to_str(enum server_inetaddr_updater_by by)
{
switch (by) {
case SERVER_INETADDR_UPDATER_BY_CLI:
return "stats socket command";
case SERVER_INETADDR_UPDATER_BY_LUA:
return "Lua script";
case SERVER_INETADDR_UPDATER_BY_DNS_AR:
return "DNS additional record";
case SERVER_INETADDR_UPDATER_BY_DNS_CACHE:
return "DNS cache";
case SERVER_INETADDR_UPDATER_BY_DNS_RESOLVER:
return "DNS resolver";
default:
/* unknown, don't mention updater */
break;
}
return NULL;
}
/* append inetaddr updater info to chunk <out>
*/
static void _srv_append_inetaddr_updater_info(struct buffer *out,
struct server *s,
struct server_inetaddr_updater updater)
{
switch (updater.by) {
case SERVER_INETADDR_UPDATER_BY_DNS_RESOLVER:
/* we need to report the resolver/nameserver id which is
* responsible for the update
*/
{
struct resolvers *r = s->resolvers;
struct dns_nameserver *ns;
/* we already know that the update comes from the
* resolver section linked to the server, but we
* need to find out which nameserver handled the dns
* query
*/
BUG_ON(!r);
BUILD: server: fix build regression on old compilers (<= gcc-4.4) Willy reported that since 3ac79b504 ("MEDIUM: server: make server_set_inetaddr() updater serializable"), haproxy fails to compile on some older compilers such as gcc-4.4 with this kind of error: src/server.c: In function 'snr_resolution_cb': src/server.c:4471: error: unknown field 'dns_resolver' specified in initializer compilation terminated due to -Wfatal-errors. make: *** [Makefile:1006: src/server.o] Error 1 This is due to referencing a member inside anonymous union from a compound literal assignment. Apparently such use of anonymous union wasn't properly supported back then on older compilers. To fix the issue, we give "u" name to the parent union use this name to explicitly refer to the union where relevant in the code (only a few changes fortunately). The fix itself was verified to restore build compatibility with gcc 4.4 (and even 4.2). As 3ac79b504 is used as a prerequisite for 64c9c8ef3 ("BUG/MINOR: server/dns: use server_set_inetaddr() to unset srv addr from DNS"), please consider backporting this patch too if 64c9c8ef3 happens to be backported in 2.9.
2024-03-25 08:38:36 -04:00
ns = find_nameserver_by_resolvers_and_id(r, updater.u.dns_resolver.ns_id);
MEDIUM: server: make server_set_inetaddr() updater serializable server_set_inetaddr() updater argument is a simple char * string containing infos about the caller responsible for the update. In this patch, we try to make this argument serializable, that is, make it so that we can easily export it without having to keep the original pointer passed by the caller or having to work with strings of variable lengths. This was a prerequisite for exposing more updater information through SERVER_INETADDR event (upcoming patch). Static strings were simply mapped to a fixed ID that can be converted back to a string when needed using server_inetaddr_updater_by_to_str(). One special case one made for the SERVER_INETADDR_UPDATER_DNS_RESOLVER updater since in this case the updater hint has to be generated from the corresponding resolver id / nameserver id combination. This was achieved by saving the nameserver id within the updater struct. Knowing that the resolver id can be guessed from the server struct directly, it was not exposed through the updater struct. This patch depends on: - "MINOR: resolvers: add unique numeric id to nameservers" No functional change should be expected.
2023-12-11 09:06:43 -05:00
BUG_ON(!ns);
chunk_appendf(out, " by '%s/%s'", r->id, ns->id);
}
break;
default:
{
const char *by_name;
by_name = server_inetaddr_updater_by_to_str(updater.by);
if (by_name)
chunk_appendf(out, " by '%s'", by_name);
}
break;
}
}
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
/* server_set_inetaddr() helper */
static void _addr_to_str(int family, const void *addr, char *addr_str, size_t len)
{
memset(addr_str, 0, len);
switch (family) {
MEDIUM: server: add support for changing a server's address Ability to change a server IP address during HAProxy run time. For now this is provided via function update_server_addr() which currently is not called. A log is emitted on each change. For now we do it inconditionally, but later we'll want to do it only on certain circumstances, which explains why the logging block is enclosed in if(1).
2015-04-13 19:13:07 -04:00
case AF_INET:
case AF_INET6:
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
inet_ntop(family, addr, addr_str, len);
MEDIUM: server: add support for changing a server's address Ability to change a server IP address during HAProxy run time. For now this is provided via function update_server_addr() which currently is not called. A log is emitted on each change. For now we do it inconditionally, but later we'll want to do it only on certain circumstances, which explains why the logging block is enclosed in if(1).
2015-04-13 19:13:07 -04:00
break;
MINOR: server: Improve log message sent when server address is updated When the server address is set for the first time, the log message is a bit ugly because there is no old ip address to report. Thus in the log, we can see : PX/SRV changed its IP from to A.B.C.D by DNS additional record. Now, when this happens, "(none)" is reported : PX/SRV changed its IP from (none) to A.B.C.D by DNS additional record. This patch may be backported to 2.2.
2020-09-08 04:38:40 -04:00
default:
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
strlcpy2(addr_str, "(none)", len);
MINOR: server: Improve log message sent when server address is updated When the server address is set for the first time, the log message is a bit ugly because there is no old ip address to report. Thus in the log, we can see : PX/SRV changed its IP from to A.B.C.D by DNS additional record. Now, when this happens, "(none)" is reported : PX/SRV changed its IP from (none) to A.B.C.D by DNS additional record. This patch may be backported to 2.2.
2020-09-08 04:38:40 -04:00
break;
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
}
}
/* server_set_inetaddr() helper */
static int _inetaddr_addr_cmp(const struct server_inetaddr *inetaddr, const struct sockaddr_storage *addr)
{
struct in_addr *v4;
struct in6_addr *v6;
MEDIUM: server: add support for changing a server's address Ability to change a server IP address during HAProxy run time. For now this is provided via function update_server_addr() which currently is not called. A log is emitted on each change. For now we do it inconditionally, but later we'll want to do it only on certain circumstances, which explains why the logging block is enclosed in if(1).
2015-04-13 19:13:07 -04:00
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
if (inetaddr->family != addr->ss_family)
return 1;
if (inetaddr->family == AF_INET) {
v4 = &((struct sockaddr_in *)addr)->sin_addr;
if (memcmp(&inetaddr->addr.v4, v4, sizeof(struct in_addr)))
return 1;
}
else if (inetaddr->family == AF_INET6) {
v6 = &((struct sockaddr_in6 *)addr)->sin6_addr;
if (memcmp(&inetaddr->addr.v6, v6, sizeof(struct in6_addr)))
return 1;
}
return 0; // both inetaddr storage are equivalent
}
/* This function sets a server's addr and port in inet context based on new
* inetaddr input
*
* The function first does the following, in that order:
* - checks if an update is required (new IP or port is different than current
* one)
* - check the update is allowed:
* - allow all changes if no CHECKS are configured
* - if CHECK is configured:
* - if switch to port map (SRV_F_MAPPORTS), ensure health check have their
* own ports
* - applies required changes to both ADDR and PORT if both 'required' and
* 'allowed' conditions are met.
*
* Caller can pass <msg> buffer so that it gets some information about the
* operation. It may as well provide <updater> so that messages mention that
* the update was performed on the behalf of it.
*
* <inetaddr> family may be set to UNSPEC to reset server's addr
*
* Caller must set <inetaddr>->port.map to 1 if <inetaddr>->port.svc must be
* handled as an offset
*
* The function returns 1 if an update was performed and 0 if nothing was
* changed.
*/
int server_set_inetaddr(struct server *s,
const struct server_inetaddr *inetaddr,
MEDIUM: server: make server_set_inetaddr() updater serializable server_set_inetaddr() updater argument is a simple char * string containing infos about the caller responsible for the update. In this patch, we try to make this argument serializable, that is, make it so that we can easily export it without having to keep the original pointer passed by the caller or having to work with strings of variable lengths. This was a prerequisite for exposing more updater information through SERVER_INETADDR event (upcoming patch). Static strings were simply mapped to a fixed ID that can be converted back to a string when needed using server_inetaddr_updater_by_to_str(). One special case one made for the SERVER_INETADDR_UPDATER_DNS_RESOLVER updater since in this case the updater hint has to be generated from the corresponding resolver id / nameserver id combination. This was achieved by saving the nameserver id within the updater struct. Knowing that the resolver id can be guessed from the server struct directly, it was not exposed through the updater struct. This patch depends on: - "MINOR: resolvers: add unique numeric id to nameservers" No functional change should be expected.
2023-12-11 09:06:43 -05:00
struct server_inetaddr_updater updater, struct buffer *msg)
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
{
union {
struct event_hdl_cb_data_server_inetaddr addr;
struct event_hdl_cb_data_server common;
} cb_data;
char addr_str[INET6_ADDRSTRLEN];
uint16_t current_port;
uint8_t ip_change = 0;
uint8_t port_change = 0;
int ret = 0;
/* only INET families are supported */
BUG_ON((inetaddr->family != AF_UNSPEC &&
inetaddr->family != AF_INET && inetaddr->family != AF_INET6) ||
(s->addr.ss_family != AF_UNSPEC &&
s->addr.ss_family != AF_INET && s->addr.ss_family != AF_INET6));
/* ignore if no change */
if (!_inetaddr_addr_cmp(inetaddr, &s->addr))
goto port;
ip_change = 1;
/* update report for caller */
if (msg) {
void *from_ptr = NULL;
if (s->addr.ss_family == AF_INET)
from_ptr = &((struct sockaddr_in *)&s->addr)->sin_addr;
else if (s->addr.ss_family == AF_INET6)
from_ptr = &((struct sockaddr_in6 *)&s->addr)->sin6_addr;
_addr_to_str(s->addr.ss_family, from_ptr, addr_str, sizeof(addr_str));
chunk_printf(msg, "IP changed from '%s'", addr_str);
_addr_to_str(inetaddr->family, &inetaddr->addr, addr_str, sizeof(addr_str));
chunk_appendf(msg, " to '%s'", addr_str);
}
if (inetaddr->family == AF_UNSPEC)
goto out; // ignore port information when unsetting addr
port:
/* collection data currently setup */
current_port = s->svc_port;
/* check if caller triggers a port mapped or offset */
if (inetaddr->port.map) {
/* check if server currently uses port map */
if (!(s->flags & SRV_F_MAPPORTS)) {
/* we're switching from a fixed port to a SRV_F_MAPPORTS
* (mapped) port, prevent PORT change if check is enabled
* and it doesn't have it's dedicated port while switching
* to port mapping
*/
if ((s->check.state & CHK_ST_ENABLED) && !s->check.port) {
if (msg) {
if (ip_change)
chunk_appendf(msg, ", ");
chunk_appendf(msg, "can't change <port> to port map because it is incompatible with current health check port configuration (use 'port' statement from the 'server' directive).");
}
goto out;
}
/* switch from fixed port to port map mandatorily triggers
* a port change
*/
port_change = 1;
}
/* else we're already using port maps */
else {
port_change = current_port != inetaddr->port.svc;
}
}
/* fixed port */
else {
if ((s->flags & SRV_F_MAPPORTS))
port_change = 1; // changing from mapped to fixed
else
port_change = current_port != inetaddr->port.svc;
}
/* update response message about PORT change */
if (port_change && msg) {
if (ip_change)
chunk_appendf(msg, ", ");
chunk_appendf(msg, "port changed from '");
if (s->flags & SRV_F_MAPPORTS)
chunk_appendf(msg, "+");
chunk_appendf(msg, "%d' to '", s->svc_port);
if (inetaddr->port.map)
chunk_appendf(msg, "+");
chunk_appendf(msg, "%d'", inetaddr->port.svc);
}
out:
if (ip_change || port_change) {
_srv_event_hdl_prepare(&cb_data.common, s, 0);
_srv_event_hdl_prepare_inetaddr(&cb_data.addr, s,
MINOR: server/event_hdl: expose updater info through INETADDR event Thanks to the previous commit, we can now expose updater info through INETADDR event.
2023-12-11 11:14:24 -05:00
inetaddr,
updater);
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
/* server_atomic_sync_task will apply the changes for us */
_srv_event_hdl_publish(EVENT_HDL_SUB_SERVER_INETADDR, cb_data, s);
ret = 1;
}
MEDIUM: server: add support for changing a server's address Ability to change a server IP address during HAProxy run time. For now this is provided via function update_server_addr() which currently is not called. A log is emitted on each change. For now we do it inconditionally, but later we'll want to do it only on certain circumstances, which explains why the logging block is enclosed in if(1).
2015-04-13 19:13:07 -04:00
MEDIUM: server: make server_set_inetaddr() updater serializable server_set_inetaddr() updater argument is a simple char * string containing infos about the caller responsible for the update. In this patch, we try to make this argument serializable, that is, make it so that we can easily export it without having to keep the original pointer passed by the caller or having to work with strings of variable lengths. This was a prerequisite for exposing more updater information through SERVER_INETADDR event (upcoming patch). Static strings were simply mapped to a fixed ID that can be converted back to a string when needed using server_inetaddr_updater_by_to_str(). One special case one made for the SERVER_INETADDR_UPDATER_DNS_RESOLVER updater since in this case the updater hint has to be generated from the corresponding resolver id / nameserver id combination. This was achieved by saving the nameserver id within the updater struct. Knowing that the resolver id can be guessed from the server struct directly, it was not exposed through the updater struct. This patch depends on: - "MINOR: resolvers: add unique numeric id to nameservers" No functional change should be expected.
2023-12-11 09:06:43 -05:00
if (ret && msg && updater.by != SERVER_INETADDR_UPDATER_BY_NONE)
_srv_append_inetaddr_updater_info(msg, s, updater);
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
return ret;
}
MEDIUM: server: add support for changing a server's address Ability to change a server IP address during HAProxy run time. For now this is provided via function update_server_addr() which currently is not called. A log is emitted on each change. For now we do it inconditionally, but later we'll want to do it only on certain circumstances, which explains why the logging block is enclosed in if(1).
2015-04-13 19:13:07 -04:00
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
/* Sets new server's addr and/or svc_port, then send a log and report a
* warning on stderr if something has changed.
*
* Returns 1 if something has changed, 0 otherwise.
* see server_set_inetaddr() for more information.
*/
int server_set_inetaddr_warn(struct server *s,
const struct server_inetaddr *inetaddr,
MEDIUM: server: make server_set_inetaddr() updater serializable server_set_inetaddr() updater argument is a simple char * string containing infos about the caller responsible for the update. In this patch, we try to make this argument serializable, that is, make it so that we can easily export it without having to keep the original pointer passed by the caller or having to work with strings of variable lengths. This was a prerequisite for exposing more updater information through SERVER_INETADDR event (upcoming patch). Static strings were simply mapped to a fixed ID that can be converted back to a string when needed using server_inetaddr_updater_by_to_str(). One special case one made for the SERVER_INETADDR_UPDATER_DNS_RESOLVER updater since in this case the updater hint has to be generated from the corresponding resolver id / nameserver id combination. This was achieved by saving the nameserver id within the updater struct. Knowing that the resolver id can be guessed from the server struct directly, it was not exposed through the updater struct. This patch depends on: - "MINOR: resolvers: add unique numeric id to nameservers" No functional change should be expected.
2023-12-11 09:06:43 -05:00
struct server_inetaddr_updater updater)
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
{
struct buffer *msg = get_trash_chunk();
int ret;
chunk_reset(msg);
ret = server_set_inetaddr(s, inetaddr, updater, msg);
if (msg->data) {
MEDIUM: server: add support for changing a server's address Ability to change a server IP address during HAProxy run time. For now this is provided via function update_server_addr() which currently is not called. A log is emitted on each change. For now we do it inconditionally, but later we'll want to do it only on certain circumstances, which explains why the logging block is enclosed in if(1).
2015-04-13 19:13:07 -04:00
/* write the buffer on stderr */
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
ha_warning("%s/%s: %s.\n", s->proxy->id, s->id, msg->area);
MEDIUM: server: add support for changing a server's address Ability to change a server IP address during HAProxy run time. For now this is provided via function update_server_addr() which currently is not called. A log is emitted on each change. For now we do it inconditionally, but later we'll want to do it only on certain circumstances, which explains why the logging block is enclosed in if(1).
2015-04-13 19:13:07 -04:00
/* send a log */
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
send_log(s->proxy, LOG_NOTICE, "%s/%s: %s.\n", s->proxy->id, s->id, msg->area);
MEDIUM: server: add support for changing a server's address Ability to change a server IP address during HAProxy run time. For now this is provided via function update_server_addr() which currently is not called. A log is emitted on each change. For now we do it inconditionally, but later we'll want to do it only on certain circumstances, which explains why the logging block is enclosed in if(1).
2015-04-13 19:13:07 -04:00
}
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
return ret;
}
/*
* update a server's current IP address.
* ip is a pointer to the new IP address, whose address family is ip_sin_family.
* ip is in network format.
* updater is a string which contains an information about the requester of the update.
* updater is used if not NULL.
*
* A log line and a stderr warning message is generated based on server's backend options.
*
* Must be called with the server lock held.
*/
MEDIUM: server: make server_set_inetaddr() updater serializable server_set_inetaddr() updater argument is a simple char * string containing infos about the caller responsible for the update. In this patch, we try to make this argument serializable, that is, make it so that we can easily export it without having to keep the original pointer passed by the caller or having to work with strings of variable lengths. This was a prerequisite for exposing more updater information through SERVER_INETADDR event (upcoming patch). Static strings were simply mapped to a fixed ID that can be converted back to a string when needed using server_inetaddr_updater_by_to_str(). One special case one made for the SERVER_INETADDR_UPDATER_DNS_RESOLVER updater since in this case the updater hint has to be generated from the corresponding resolver id / nameserver id combination. This was achieved by saving the nameserver id within the updater struct. Knowing that the resolver id can be guessed from the server struct directly, it was not exposed through the updater struct. This patch depends on: - "MINOR: resolvers: add unique numeric id to nameservers" No functional change should be expected.
2023-12-11 09:06:43 -05:00
int srv_update_addr(struct server *s, void *ip, int ip_sin_family, struct server_inetaddr_updater updater)
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
{
struct server_inetaddr inetaddr;
server_get_inetaddr(s, &inetaddr);
BUG_ON(ip_sin_family != AF_INET && ip_sin_family != AF_INET6);
MEDIUM: server: add support for changing a server's address Ability to change a server IP address during HAProxy run time. For now this is provided via function update_server_addr() which currently is not called. A log is emitted on each change. For now we do it inconditionally, but later we'll want to do it only on certain circumstances, which explains why the logging block is enclosed in if(1).
2015-04-13 19:13:07 -04:00
/* save the new IP family */
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
inetaddr.family = ip_sin_family;
MEDIUM: server: add support for changing a server's address Ability to change a server IP address during HAProxy run time. For now this is provided via function update_server_addr() which currently is not called. A log is emitted on each change. For now we do it inconditionally, but later we'll want to do it only on certain circumstances, which explains why the logging block is enclosed in if(1).
2015-04-13 19:13:07 -04:00
/* save the new IP address */
switch (ip_sin_family) {
case AF_INET:
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
memcpy(&inetaddr.addr.v4, ip, 4);
MEDIUM: server: add support for changing a server's address Ability to change a server IP address during HAProxy run time. For now this is provided via function update_server_addr() which currently is not called. A log is emitted on each change. For now we do it inconditionally, but later we'll want to do it only on certain circumstances, which explains why the logging block is enclosed in if(1).
2015-04-13 19:13:07 -04:00
break;
case AF_INET6:
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
memcpy(&inetaddr.addr.v6, ip, 16);
MEDIUM: server: add support for changing a server's address Ability to change a server IP address during HAProxy run time. For now this is provided via function update_server_addr() which currently is not called. A log is emitted on each change. For now we do it inconditionally, but later we'll want to do it only on certain circumstances, which explains why the logging block is enclosed in if(1).
2015-04-13 19:13:07 -04:00
break;
};
MINOR: server/event_hdl: add SERVER_INETADDR event In this patch we add the support for a new SERVER event in the event_hdl API. SERVER_INETADDR is implemented as an advanced server event. It is published each time the server's ip address or port is about to change. (ie: from the cli, dns, lua...) SERVER_INETADDR data is an event_hdl_cb_data_server_inetaddr struct that provides additional info related to the server inet addr change, but can be casted as a regular event_hdl_cb_data_server struct if additional info is not needed.
2023-11-10 14:12:00 -05:00
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
server_set_inetaddr_warn(s, &inetaddr, updater);
MINOR: server/event_hdl: add SERVER_INETADDR event In this patch we add the support for a new SERVER event in the event_hdl API. SERVER_INETADDR is implemented as an advanced server event. It is published each time the server's ip address or port is about to change. (ie: from the cli, dns, lua...) SERVER_INETADDR data is an event_hdl_cb_data_server_inetaddr struct that provides additional info related to the server inet addr change, but can be casted as a regular event_hdl_cb_data_server struct if additional info is not needed.
2023-11-10 14:12:00 -05:00
MEDIUM: server: add support for changing a server's address Ability to change a server IP address during HAProxy run time. For now this is provided via function update_server_addr() which currently is not called. A log is emitted on each change. For now we do it inconditionally, but later we'll want to do it only on certain circumstances, which explains why the logging block is enclosed in if(1).
2015-04-13 19:13:07 -04:00
return 0;
}
MEDIUM: cli: add agent-port command this patch allows to set agent port at runtime. In order to align with both `addr` and `check-addr` commands, also add the possibility to optionnaly set port on `agent-addr` command. This led to a small refactor in order to use the same function for both `agent-addr` and `agent-port` commands. Signed-off-by: William Dauchy <wdauchy@gmail.com>
2021-02-11 16:51:24 -05:00
/* update agent health check address and port
* addr can be ip4/ip6 or a hostname
* if one error occurs, don't apply anything
* must be called with the server lock held.
*/
REORG: server: Export and rename some functions updating server info Some static functions are now exported and renamed to follow the same pattern of other exported functions. Here is the list : * update_server_fqdn: Renamed to srv_update_fqdn and exported * update_server_check_addr_port: renamed to srv_update_check_addr_port and exported * update_server_agent_addr_port: renamed to srv_update_agent_addr_port and exported * update_server_addr: renamed to srv_update_addr * update_server_addr_potr: renamed to srv_update_addr_port * srv_prepare_for_resolution: exported This change is mandatory to move all functions dealing with the server-state files in a separate file.
2021-02-16 06:07:47 -05:00
const char *srv_update_agent_addr_port(struct server *s, const char *addr, const char *port)
MEDIUM: cli: add agent-port command this patch allows to set agent port at runtime. In order to align with both `addr` and `check-addr` commands, also add the possibility to optionnaly set port on `agent-addr` command. This led to a small refactor in order to use the same function for both `agent-addr` and `agent-port` commands. Signed-off-by: William Dauchy <wdauchy@gmail.com>
2021-02-11 16:51:24 -05:00
{
struct sockaddr_storage sk;
struct buffer *msg;
int new_port;
msg = get_trash_chunk();
chunk_reset(msg);
if (!(s->agent.state & CHK_ST_ENABLED)) {
chunk_strcat(msg, "agent checks are not enabled on this server");
goto out;
}
if (addr) {
memset(&sk, 0, sizeof(struct sockaddr_storage));
if (str2ip(addr, &sk) == NULL) {
chunk_appendf(msg, "invalid addr '%s'", addr);
goto out;
}
}
if (port) {
if (strl2irc(port, strlen(port), &new_port) != 0) {
chunk_appendf(msg, "provided port is not an integer");
goto out;
}
if (new_port < 0 || new_port > 65535) {
chunk_appendf(msg, "provided port is invalid");
goto out;
}
}
out:
if (msg->data)
return msg->area;
else {
if (addr)
set_srv_agent_addr(s, &sk);
if (port)
set_srv_agent_port(s, new_port);
}
return NULL;
}
MEDIUM: cli: add check-addr command this patch allows to set server health check address at runtime. In order to align with `addr` command, also allow to set port optionnaly. This led to a small refactor in order to use the same function for both `check-addr` and `check-port` commands. for `check-port`, we however don't permit the change anymore if checks are not enabled on the server. This command becomes more and more useful for people having a consul like architecture: - the backend server is located on a container with its own IP - the health checks are done the consul instance located on the host with the host IP Signed-off-by: William Dauchy <wdauchy@gmail.com>
2021-02-11 16:51:23 -05:00
/* update server health check address and port
* addr must be ip4 or ip6, it won't be resolved
* if one error occurs, don't apply anything
* must be called with the server lock held.
*/
REORG: server: Export and rename some functions updating server info Some static functions are now exported and renamed to follow the same pattern of other exported functions. Here is the list : * update_server_fqdn: Renamed to srv_update_fqdn and exported * update_server_check_addr_port: renamed to srv_update_check_addr_port and exported * update_server_agent_addr_port: renamed to srv_update_agent_addr_port and exported * update_server_addr: renamed to srv_update_addr * update_server_addr_potr: renamed to srv_update_addr_port * srv_prepare_for_resolution: exported This change is mandatory to move all functions dealing with the server-state files in a separate file.
2021-02-16 06:07:47 -05:00
const char *srv_update_check_addr_port(struct server *s, const char *addr, const char *port)
MEDIUM: cli: add check-addr command this patch allows to set server health check address at runtime. In order to align with `addr` command, also allow to set port optionnaly. This led to a small refactor in order to use the same function for both `check-addr` and `check-port` commands. for `check-port`, we however don't permit the change anymore if checks are not enabled on the server. This command becomes more and more useful for people having a consul like architecture: - the backend server is located on a container with its own IP - the health checks are done the consul instance located on the host with the host IP Signed-off-by: William Dauchy <wdauchy@gmail.com>
2021-02-11 16:51:23 -05:00
{
struct sockaddr_storage sk;
struct buffer *msg;
int new_port;
msg = get_trash_chunk();
chunk_reset(msg);
if (!(s->check.state & CHK_ST_ENABLED)) {
chunk_strcat(msg, "health checks are not enabled on this server");
goto out;
}
if (addr) {
memset(&sk, 0, sizeof(struct sockaddr_storage));
if (str2ip2(addr, &sk, 0) == NULL) {
chunk_appendf(msg, "invalid addr '%s'", addr);
goto out;
}
}
if (port) {
if (strl2irc(port, strlen(port), &new_port) != 0) {
chunk_appendf(msg, "provided port is not an integer");
goto out;
}
if (new_port < 0 || new_port > 65535) {
chunk_appendf(msg, "provided port is invalid");
goto out;
}
/* prevent the update of port to 0 if MAPPORTS are in use */
if ((s->flags & SRV_F_MAPPORTS) && new_port == 0) {
chunk_appendf(msg, "can't unset 'port' since MAPPORTS is in use");
goto out;
}
}
out:
if (msg->data)
return msg->area;
else {
if (addr)
s->check.addr = sk;
if (port)
s->check.port = new_port;
BUG/MINOR: server: Update healthcheck when server settings are changed via CLI not all changes are concerned. But when the SSL is enabled or disabled for a server, the healthcheck xprt must be eventually be updated too. This happens when the healthcheck relies on the server settings. In the same spirit, when the healthcheck address and port are updated, we must fallback on the raw xprt if the SSL is not explicitly enabled for the healthcheck with a "check-ssl" parameter. This patch should be backported to all stable versions.
2025-09-03 10:36:25 -04:00
/* Fallback to raw XPRT for the health-check */
if (!s->check.use_ssl)
s->check.xprt = xprt_get(XPRT_RAW);
MEDIUM: cli: add check-addr command this patch allows to set server health check address at runtime. In order to align with `addr` command, also allow to set port optionnaly. This led to a small refactor in order to use the same function for both `check-addr` and `check-port` commands. for `check-port`, we however don't permit the change anymore if checks are not enabled on the server. This command becomes more and more useful for people having a consul like architecture: - the backend server is located on a container with its own IP - the health checks are done the consul instance located on the host with the host IP Signed-off-by: William Dauchy <wdauchy@gmail.com>
2021-02-11 16:51:23 -05:00
}
return NULL;
}
MINOR: new update_server_addr_port() function to change both server's ADDR and service PORT This function can replace update_server_addr() where the need to change the server's port as well as the IP address is required. It performs some validation before performing each type of change.
2016-08-02 02:18:55 -04:00
/*
* This function update a server's addr and port only for AF_INET and AF_INET6 families.
*
MEDIUM: server: make server_set_inetaddr() updater serializable server_set_inetaddr() updater argument is a simple char * string containing infos about the caller responsible for the update. In this patch, we try to make this argument serializable, that is, make it so that we can easily export it without having to keep the original pointer passed by the caller or having to work with strings of variable lengths. This was a prerequisite for exposing more updater information through SERVER_INETADDR event (upcoming patch). Static strings were simply mapped to a fixed ID that can be converted back to a string when needed using server_inetaddr_updater_by_to_str(). One special case one made for the SERVER_INETADDR_UPDATER_DNS_RESOLVER updater since in this case the updater hint has to be generated from the corresponding resolver id / nameserver id combination. This was achieved by saving the nameserver id within the updater struct. Knowing that the resolver id can be guessed from the server struct directly, it was not exposed through the updater struct. This patch depends on: - "MINOR: resolvers: add unique numeric id to nameservers" No functional change should be expected.
2023-12-11 09:06:43 -05:00
* Caller can pass its info through <updater> to get it integrated in the response
* message returned by the function.
MINOR: new update_server_addr_port() function to change both server's ADDR and service PORT This function can replace update_server_addr() where the need to change the server's port as well as the IP address is required. It performs some validation before performing each type of change.
2016-08-02 02:18:55 -04:00
*
* The function first does the following, in that order:
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
* - checks that don't switch from/to a family other than AF_INET and AF_INET6
MINOR: new update_server_addr_port() function to change both server's ADDR and service PORT This function can replace update_server_addr() where the need to change the server's port as well as the IP address is required. It performs some validation before performing each type of change.
2016-08-02 02:18:55 -04:00
* - validates the new addr and/or port
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
* - calls server_set_inetaddr() to check and apply the change
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
*
* Must be called with the server lock held.
MINOR: new update_server_addr_port() function to change both server's ADDR and service PORT This function can replace update_server_addr() where the need to change the server's port as well as the IP address is required. It performs some validation before performing each type of change.
2016-08-02 02:18:55 -04:00
*/
MEDIUM: server: make server_set_inetaddr() updater serializable server_set_inetaddr() updater argument is a simple char * string containing infos about the caller responsible for the update. In this patch, we try to make this argument serializable, that is, make it so that we can easily export it without having to keep the original pointer passed by the caller or having to work with strings of variable lengths. This was a prerequisite for exposing more updater information through SERVER_INETADDR event (upcoming patch). Static strings were simply mapped to a fixed ID that can be converted back to a string when needed using server_inetaddr_updater_by_to_str(). One special case one made for the SERVER_INETADDR_UPDATER_DNS_RESOLVER updater since in this case the updater hint has to be generated from the corresponding resolver id / nameserver id combination. This was achieved by saving the nameserver id within the updater struct. Knowing that the resolver id can be guessed from the server struct directly, it was not exposed through the updater struct. This patch depends on: - "MINOR: resolvers: add unique numeric id to nameservers" No functional change should be expected.
2023-12-11 09:06:43 -05:00
const char *srv_update_addr_port(struct server *s, const char *addr, const char *port,
struct server_inetaddr_updater updater)
MINOR: new update_server_addr_port() function to change both server's ADDR and service PORT This function can replace update_server_addr() where the need to change the server's port as well as the IP address is required. It performs some validation before performing each type of change.
2016-08-02 02:18:55 -04:00
{
struct sockaddr_storage sa;
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
struct server_inetaddr inetaddr;
MAJOR: chunks: replace struct chunk with struct buffer Now all the code used to manipulate chunks uses a struct buffer instead. The functions are still called "chunk*", and some of them will progressively move to the generic buffer handling code as they are cleaned up.
2018-07-13 05:56:34 -04:00
struct buffer *msg;
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
int ret;
MINOR: new update_server_addr_port() function to change both server's ADDR and service PORT This function can replace update_server_addr() where the need to change the server's port as well as the IP address is required. It performs some validation before performing each type of change.
2016-08-02 02:18:55 -04:00
msg = get_trash_chunk();
chunk_reset(msg);
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
/* even a simple port change is not supported outside of inet context, because
* s->svc_port is only relevant under inet context
*/
if ((s->addr.ss_family != AF_INET) && (s->addr.ss_family != AF_INET6)) {
CLEANUP: server: remove ambiguous check in srv_update_addr_port() A leftover check was left by recent patch series about server addr:svc_port propagation: a check on (msg) being set was performed in srv_update_addr_port(), but msg is always set, so the check is not needed and confuses coverity (See GH #2399)
2023-12-22 08:42:22 -05:00
chunk_printf(msg, "Update for the current server address family is only supported through configuration file.");
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
goto out;
}
server_get_inetaddr(s, &inetaddr);
MINOR: new update_server_addr_port() function to change both server's ADDR and service PORT This function can replace update_server_addr() where the need to change the server's port as well as the IP address is required. It performs some validation before performing each type of change.
2016-08-02 02:18:55 -04:00
if (addr) {
memset(&sa, 0, sizeof(struct sockaddr_storage));
if (str2ip2(addr, &sa, 0) == NULL) {
chunk_printf(msg, "Invalid addr '%s'", addr);
goto out;
}
/* changes are allowed on AF_INET* families only */
if ((sa.ss_family != AF_INET) && (sa.ss_family != AF_INET6)) {
chunk_printf(msg, "Update to families other than AF_INET and AF_INET6 supported only through configuration file");
goto out;
}
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
inetaddr.family = sa.ss_family;
switch (inetaddr.family) {
case AF_INET:
inetaddr.addr.v4 = ((struct sockaddr_in *)&sa)->sin_addr;
break;
case AF_INET6:
inetaddr.addr.v6 = ((struct sockaddr_in6 *)&sa)->sin6_addr;
break;
MINOR: new update_server_addr_port() function to change both server's ADDR and service PORT This function can replace update_server_addr() where the need to change the server's port as well as the IP address is required. It performs some validation before performing each type of change.
2016-08-02 02:18:55 -04:00
}
}
if (port) {
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
uint16_t new_port;
MINOR: new update_server_addr_port() function to change both server's ADDR and service PORT This function can replace update_server_addr() where the need to change the server's port as well as the IP address is required. It performs some validation before performing each type of change.
2016-08-02 02:18:55 -04:00
char sign = '\0';
char *endptr;
sign = *port;
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
BUG/MINOR: Reset errno variable before calling strtol(3) Sometimes errno != 0 before calling strtol(3) [wt: this needs to be backported to 1.7]
2017-01-11 10:39:55 -05:00
errno = 0;
MINOR: new update_server_addr_port() function to change both server's ADDR and service PORT This function can replace update_server_addr() where the need to change the server's port as well as the IP address is required. It performs some validation before performing each type of change.
2016-08-02 02:18:55 -04:00
new_port = strtol(port, &endptr, 10);
if ((errno != 0) || (port == endptr)) {
chunk_appendf(msg, "problem converting port '%s' to an int", port);
goto out;
}
/* check if caller triggers a port mapped or offset */
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
if (sign == '-' || sign == '+')
inetaddr.port.map = 1;
else
inetaddr.port.map = 0;
inetaddr.port.svc = new_port;
/* note: negative offset was converted to positive offset
* (new_port is unsigned) to prevent later conversions errors
* since svc_port is handled as an unsigned int all along the
* chain. Unfortunately this is a one-way operation so the user
* could be surprised to see a negative offset reported using
* its equivalent positive offset in the generated message
* (-X = +(65535 - (X-1))), but thanks to proper wraparound it
* will be interpreted as a negative offset during port
* remapping so it will work as expected.
*/
MINOR: new update_server_addr_port() function to change both server's ADDR and service PORT This function can replace update_server_addr() where the need to change the server's port as well as the IP address is required. It performs some validation before performing each type of change.
2016-08-02 02:18:55 -04:00
}
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
ret = server_set_inetaddr(s, &inetaddr, updater, msg);
if (!ret)
chunk_printf(msg, "nothing changed");
MINOR: server/event_hdl: add SERVER_INETADDR event In this patch we add the support for a new SERVER event in the event_hdl API. SERVER_INETADDR is implemented as an advanced server event. It is published each time the server's ip address or port is about to change. (ie: from the cli, dns, lua...) SERVER_INETADDR data is an event_hdl_cb_data_server_inetaddr struct that provides additional info related to the server inet addr change, but can be casted as a regular event_hdl_cb_data_server struct if additional info is not needed.
2023-11-10 14:12:00 -05:00
MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic Both functions are performing the similar tasks, except that the _port() version is doing a bit more work. In this patch, we add the server_set_inetaddr() function that works like the srv_update_addr_port() but it takes parsed inputs instead of raw strings as arguments. Then, server_set_inetaddr() is used as underlying helper function for both srv_update_addr() and srv_update_addr_port() to make them easier to maintain. Also, helper functions were added: - server_set_inetaddr_warn() -> same as server_set_inetaddr() but report a warning on updates. - server_get_inetaddr() -> fills a struct server_inetaddr from srv Since the feedback message generation part was slightly reworked, some minor changes in the way addr:svc_port updates are reported in the logs or cli messages should be expected (no loss of information though).
2023-12-11 04:23:17 -05:00
out:
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
return msg->area;
MINOR: new update_server_addr_port() function to change both server's ADDR and service PORT This function can replace update_server_addr() where the need to change the server's port as well as the IP address is required. It performs some validation before performing each type of change.
2016-08-02 02:18:55 -04:00
}
MINOR: resolvers: Add function to change the srv status based on SRV resolution srvrq_update_srv_status() update the server status based on result of SRV resolution. For now, it is only used from snr_update_srv_status() when appropriate.
2021-03-11 12:03:21 -05:00
/*
MEDIUM: server/dns: clear RMAINT when addr resolves again snr_update_srv_status() and srvrq_update_srv_status() will both set or clear the server RMAINT state depending of the result of the current dns resolution. This used to work pretty well in the past, but now that addr:svc_port changes are changed atomically through a dedicated task, the change is performed asynchronously, so this can cause some flapping issues if the server is put out of maintenance while the server's address is still unassigned. To prevent errors, the resolver's code is now only allowed to put the server under maintenance but not to remove it from maintenance: the decision to remove a server from maintenance is performed by the task responsible for updating the server's addr: if the addr resolves again thanks to a valid DNS resolution and the server was previously under RMAINT, then it cleared from RMAINT state. srvrq_update_srv_status() was renamed srvrq_set_srv_down(), since it is only called to put the server in maintenance as a result of a failing SRV entry. snr_update_srv_status() was renamed srv_set_srv_down() and slightly modified so that it only takes care of putting the server under maintenance when needed. The cli command "set server x/y addr" does not need to remove the RMAINT flag anymore.
2023-12-12 08:42:34 -05:00
* put the server in maintenance because of failing SRV resolution
MINOR: resolvers: Add function to change the srv status based on SRV resolution srvrq_update_srv_status() update the server status based on result of SRV resolution. For now, it is only used from snr_update_srv_status() when appropriate.
2021-03-11 12:03:21 -05:00
* returns:
MEDIUM: server/dns: clear RMAINT when addr resolves again snr_update_srv_status() and srvrq_update_srv_status() will both set or clear the server RMAINT state depending of the result of the current dns resolution. This used to work pretty well in the past, but now that addr:svc_port changes are changed atomically through a dedicated task, the change is performed asynchronously, so this can cause some flapping issues if the server is put out of maintenance while the server's address is still unassigned. To prevent errors, the resolver's code is now only allowed to put the server under maintenance but not to remove it from maintenance: the decision to remove a server from maintenance is performed by the task responsible for updating the server's addr: if the addr resolves again thanks to a valid DNS resolution and the server was previously under RMAINT, then it cleared from RMAINT state. srvrq_update_srv_status() was renamed srvrq_set_srv_down(), since it is only called to put the server in maintenance as a result of a failing SRV entry. snr_update_srv_status() was renamed srv_set_srv_down() and slightly modified so that it only takes care of putting the server under maintenance when needed. The cli command "set server x/y addr" does not need to remove the RMAINT flag anymore.
2023-12-12 08:42:34 -05:00
* 0 if server was put under maintenance
MINOR: resolvers: Add function to change the srv status based on SRV resolution srvrq_update_srv_status() update the server status based on result of SRV resolution. For now, it is only used from snr_update_srv_status() when appropriate.
2021-03-11 12:03:21 -05:00
* 1 if server status has not changed
*
* Must be called with the server lock held.
*/
MEDIUM: server/dns: clear RMAINT when addr resolves again snr_update_srv_status() and srvrq_update_srv_status() will both set or clear the server RMAINT state depending of the result of the current dns resolution. This used to work pretty well in the past, but now that addr:svc_port changes are changed atomically through a dedicated task, the change is performed asynchronously, so this can cause some flapping issues if the server is put out of maintenance while the server's address is still unassigned. To prevent errors, the resolver's code is now only allowed to put the server under maintenance but not to remove it from maintenance: the decision to remove a server from maintenance is performed by the task responsible for updating the server's addr: if the addr resolves again thanks to a valid DNS resolution and the server was previously under RMAINT, then it cleared from RMAINT state. srvrq_update_srv_status() was renamed srvrq_set_srv_down(), since it is only called to put the server in maintenance as a result of a failing SRV entry. snr_update_srv_status() was renamed srv_set_srv_down() and slightly modified so that it only takes care of putting the server under maintenance when needed. The cli command "set server x/y addr" does not need to remove the RMAINT flag anymore.
2023-12-12 08:42:34 -05:00
int srvrq_set_srv_down(struct server *s)
MINOR: resolvers: Add function to change the srv status based on SRV resolution srvrq_update_srv_status() update the server status based on result of SRV resolution. For now, it is only used from snr_update_srv_status() when appropriate.
2021-03-11 12:03:21 -05:00
{
if (!s->srvrq)
return 1;
if (s->next_admin & SRV_ADMF_RMAINT)
return 1;
MINOR: server: change adm_st_chg_cause storage type Even though it doesn't look like it at first glance, this is more like a cleanup than an actual code improvement: Given that srv->adm_st_chg_cause has been used to exclusively store static strings ever since it was implemented, we make the choice to store it as an enum instead of a fixed-size string within server struct. This will allow to save some space in server struct, and will make it more easily exportable (ie: event handlers) because of the reduced memory footprint during handling and the ability to later get the corresponding human-readable message when it's explicitly needed.
2023-04-03 11:40:28 -04:00
srv_set_admin_flag(s, SRV_ADMF_RMAINT, SRV_ADM_STCHGC_DNS_NOENT);
MINOR: resolvers: Add function to change the srv status based on SRV resolution srvrq_update_srv_status() update the server status based on result of SRV resolution. For now, it is only used from snr_update_srv_status() when appropriate.
2021-03-11 12:03:21 -05:00
return 0;
}
MINOR: new update_server_addr_port() function to change both server's ADDR and service PORT This function can replace update_server_addr() where the need to change the server's port as well as the IP address is required. It performs some validation before performing each type of change.
2016-08-02 02:18:55 -04:00
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
/*
MEDIUM: server/dns: clear RMAINT when addr resolves again snr_update_srv_status() and srvrq_update_srv_status() will both set or clear the server RMAINT state depending of the result of the current dns resolution. This used to work pretty well in the past, but now that addr:svc_port changes are changed atomically through a dedicated task, the change is performed asynchronously, so this can cause some flapping issues if the server is put out of maintenance while the server's address is still unassigned. To prevent errors, the resolver's code is now only allowed to put the server under maintenance but not to remove it from maintenance: the decision to remove a server from maintenance is performed by the task responsible for updating the server's addr: if the addr resolves again thanks to a valid DNS resolution and the server was previously under RMAINT, then it cleared from RMAINT state. srvrq_update_srv_status() was renamed srvrq_set_srv_down(), since it is only called to put the server in maintenance as a result of a failing SRV entry. snr_update_srv_status() was renamed srv_set_srv_down() and slightly modified so that it only takes care of putting the server under maintenance when needed. The cli command "set server x/y addr" does not need to remove the RMAINT flag anymore.
2023-12-12 08:42:34 -05:00
* put server under maintenance as a result of name resolution
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
* returns:
MEDIUM: server/dns: clear RMAINT when addr resolves again snr_update_srv_status() and srvrq_update_srv_status() will both set or clear the server RMAINT state depending of the result of the current dns resolution. This used to work pretty well in the past, but now that addr:svc_port changes are changed atomically through a dedicated task, the change is performed asynchronously, so this can cause some flapping issues if the server is put out of maintenance while the server's address is still unassigned. To prevent errors, the resolver's code is now only allowed to put the server under maintenance but not to remove it from maintenance: the decision to remove a server from maintenance is performed by the task responsible for updating the server's addr: if the addr resolves again thanks to a valid DNS resolution and the server was previously under RMAINT, then it cleared from RMAINT state. srvrq_update_srv_status() was renamed srvrq_set_srv_down(), since it is only called to put the server in maintenance as a result of a failing SRV entry. snr_update_srv_status() was renamed srv_set_srv_down() and slightly modified so that it only takes care of putting the server under maintenance when needed. The cli command "set server x/y addr" does not need to remove the RMAINT flag anymore.
2023-12-12 08:42:34 -05:00
* 0 if server was put under maintenance
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
* 1 if server status has not changed
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
*
* Must be called with the server lock held.
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
*/
MEDIUM: server: simplify snr_set_srv_down() to prevent confusions snr_set_srv_down() (was formely known as snr_update_srv_status()), is still too ambiguous because it's not clear whether we will be putting the server under maintenance or not. This is mainly due to the fact that the function behaves differently if has_no_ip is set or not. By reviewing the function callers, it has now become clear that snr_resolution_cb() is always calling the function with a valid resolution so we only want to put the server under maintenance if we don't have a valid IP address. On the other hand snr_resolution_error_cb() always calls the function on error, with either no resolution (for SRV requests) or with failing resolution (all cases except RSLV_STATUS_VALID), so in this case we decide whether to put the server under maintenance case by case (ie: expired? timeout?) As a result, let's simplify snr_set_srv_down() so that it is only called when the caller really thinks that the server should be put under maintenance, which means always for snr_resolution_error_cb(), and only if the resolution didn't yield usable ip for snr_resolution_cb().
2023-12-22 08:17:41 -05:00
int snr_set_srv_down(struct server *s)
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
{
MINOR: resolvers: renames type dns_resolvers to resolvers. It also renames 'dns_resolvers' head list to sec_resolvers to avoid conflicts with local variables 'resolvers'.
2020-12-23 10:51:12 -05:00
struct resolvers *resolvers = s->resolvers;
BUG/MEDIUM: resolvers: Skip DNS resolution at startup if SRV resolution is set At startup, if a SRV resolution is set for a server, no DNS resolution is created. We must wait the first SRV resolution to know if it must be triggered. It is important to do so for two reasons. First, during a "classical" startup, a server based on a SRV resolution has no hostname. Thus the created DNS resolution is useless. Best waiting the first SRV resolution. It is not really a bug at this stage, it is just useless. Second, in the same situation, if the server state is loaded from a file, its hosname will be set a bit later. Thus, if there is no additionnal record for this server, because there is already a DNS resolution, it inhibits any new DNS resolution. But there is no hostname attached to the existing DNS resolution. So no resolution is performed at all for this server. To avoid any problem, it is fairly easier to handle this special case during startup. But this means we must be prepared to have no "resolv_requester" field for a server at runtime. This patch must be backported as far as 2.2.
2021-03-12 04:23:05 -05:00
struct resolv_resolution *resolution = (s->resolv_requester ? s->resolv_requester->resolution : NULL);
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
int exp;
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
MEDIUM: server: simplify snr_set_srv_down() to prevent confusions snr_set_srv_down() (was formely known as snr_update_srv_status()), is still too ambiguous because it's not clear whether we will be putting the server under maintenance or not. This is mainly due to the fact that the function behaves differently if has_no_ip is set or not. By reviewing the function callers, it has now become clear that snr_resolution_cb() is always calling the function with a valid resolution so we only want to put the server under maintenance if we don't have a valid IP address. On the other hand snr_resolution_error_cb() always calls the function on error, with either no resolution (for SRV requests) or with failing resolution (all cases except RSLV_STATUS_VALID), so in this case we decide whether to put the server under maintenance case by case (ie: expired? timeout?) As a result, let's simplify snr_set_srv_down() so that it is only called when the caller really thinks that the server should be put under maintenance, which means always for snr_resolution_error_cb(), and only if the resolution didn't yield usable ip for snr_resolution_cb().
2023-12-22 08:17:41 -05:00
/* server already under maintenance */
if (s->next_admin & SRV_ADMF_RMAINT)
goto out;
BUG/MAJOR: dns: fix null pointer dereference in snr_update_srv_status Since commit 13a9232eb ("MEDIUM: dns: use Additional records from SRV responses"), a struct server can have a NULL dns_requester->resolution, when SRV records are used and DNS answers contain an Additional section. This is a problem when we call snr_update_srv_status() because it does not check that resolution is NULL, and dereferences it. This patch simply adds a test for resolution being NULL. When that happens, it means we are using SRV records with Additional records, and an entry was removed. This should fix issue #775. This should be backported to 2.2.
2020-07-28 07:38:22 -04:00
/* If resolution is NULL we're dealing with SRV records Additional records */
MEDIUM: server: simplify snr_set_srv_down() to prevent confusions snr_set_srv_down() (was formely known as snr_update_srv_status()), is still too ambiguous because it's not clear whether we will be putting the server under maintenance or not. This is mainly due to the fact that the function behaves differently if has_no_ip is set or not. By reviewing the function callers, it has now become clear that snr_resolution_cb() is always calling the function with a valid resolution so we only want to put the server under maintenance if we don't have a valid IP address. On the other hand snr_resolution_error_cb() always calls the function on error, with either no resolution (for SRV requests) or with failing resolution (all cases except RSLV_STATUS_VALID), so in this case we decide whether to put the server under maintenance case by case (ie: expired? timeout?) As a result, let's simplify snr_set_srv_down() so that it is only called when the caller really thinks that the server should be put under maintenance, which means always for snr_resolution_error_cb(), and only if the resolution didn't yield usable ip for snr_resolution_cb().
2023-12-22 08:17:41 -05:00
if (resolution == NULL)
MEDIUM: server/dns: clear RMAINT when addr resolves again snr_update_srv_status() and srvrq_update_srv_status() will both set or clear the server RMAINT state depending of the result of the current dns resolution. This used to work pretty well in the past, but now that addr:svc_port changes are changed atomically through a dedicated task, the change is performed asynchronously, so this can cause some flapping issues if the server is put out of maintenance while the server's address is still unassigned. To prevent errors, the resolver's code is now only allowed to put the server under maintenance but not to remove it from maintenance: the decision to remove a server from maintenance is performed by the task responsible for updating the server's addr: if the addr resolves again thanks to a valid DNS resolution and the server was previously under RMAINT, then it cleared from RMAINT state. srvrq_update_srv_status() was renamed srvrq_set_srv_down(), since it is only called to put the server in maintenance as a result of a failing SRV entry. snr_update_srv_status() was renamed srv_set_srv_down() and slightly modified so that it only takes care of putting the server under maintenance when needed. The cli command "set server x/y addr" does not need to remove the RMAINT flag anymore.
2023-12-12 08:42:34 -05:00
return srvrq_set_srv_down(s);
BUG/MAJOR: dns: fix null pointer dereference in snr_update_srv_status Since commit 13a9232eb ("MEDIUM: dns: use Additional records from SRV responses"), a struct server can have a NULL dns_requester->resolution, when SRV records are used and DNS answers contain an Additional section. This is a problem when we call snr_update_srv_status() because it does not check that resolution is NULL, and dereferences it. This patch simply adds a test for resolution being NULL. When that happens, it means we are using SRV records with Additional records, and an entry was removed. This should fix issue #775. This should be backported to 2.2.
2020-07-28 07:38:22 -04:00
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
switch (resolution->status) {
case RSLV_STATUS_NONE:
MAJOR/REORG: dns: DNS resolution task and requester queues This patch is a major upgrade of the internal run-time DNS resolver in HAProxy and it brings the following 2 main changes: 1. DNS resolution task Up to now, DNS resolution was triggered by the health check task. From now, DNS resolution task is autonomous. It is started by HAProxy right after the scheduler is available and it is woken either when a network IO occurs for one of its nameserver or when a timeout is matched. From now, this means we can enable DNS resolution for a server without enabling health checking. 2. Introduction of a dns_requester structure Up to now, DNS resolution was purposely made for resolving server hostnames. The idea, is to ensure that any HAProxy internal object should be able to trigger a DNS resolution. For this purpose, 2 things has to be done: - clean up the DNS code from the server structure (this was already quite clean actually) and clean up the server's callbacks from manipulating too much DNS resolution - create an agnostic structure which allows linking a DNS resolution and a requester of any type (using obj_type enum) 3. Manage requesters through queues Up to now, there was an uniq relationship between a resolution and it's owner (aka the requester now). It's a shame, because in some cases, multiple objects may share the same hostname and may benefit from a resolution being performed by a third party. This patch introduces the notion of queues, which are basically lists of either currently running resolution or waiting ones. The resolutions are now available as a pool, which belongs to the resolvers. The pool has has a default size of 64 resolutions per resolvers and is allocated at configuration parsing.
2017-05-22 09:17:15 -04:00
/* status when HAProxy has just (re)started.
* Nothing to do, since the task is already automatically started */
MEDIUM: server: simplify snr_set_srv_down() to prevent confusions snr_set_srv_down() (was formely known as snr_update_srv_status()), is still too ambiguous because it's not clear whether we will be putting the server under maintenance or not. This is mainly due to the fact that the function behaves differently if has_no_ip is set or not. By reviewing the function callers, it has now become clear that snr_resolution_cb() is always calling the function with a valid resolution so we only want to put the server under maintenance if we don't have a valid IP address. On the other hand snr_resolution_error_cb() always calls the function on error, with either no resolution (for SRV requests) or with failing resolution (all cases except RSLV_STATUS_VALID), so in this case we decide whether to put the server under maintenance case by case (ie: expired? timeout?) As a result, let's simplify snr_set_srv_down() so that it is only called when the caller really thinks that the server should be put under maintenance, which means always for snr_resolution_error_cb(), and only if the resolution didn't yield usable ip for snr_resolution_cb().
2023-12-22 08:17:41 -05:00
goto out;
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
MAJOR: dns: runtime resolution can change server admin state WARNING: this is a MAJOR (and disruptive) change with previous HAProxy's behavior: before, HAProxy never ever used to change a server administrative status when the DNS resolution failed at run time. This patch gives HAProxy the ability to change the administrative status of a server to MAINT (RMAINT actually) when an error is encountered for a period longer than its own allowed by the corresponding 'hold' parameter. IE if the configuration sets "hold nx 10s" and a server's hostname points to a NX for more than 10s, then the server will be set to RMAINT, hence in MAINTENANCE mode.
2016-11-02 17:58:18 -04:00
case RSLV_STATUS_VALID:
MEDIUM: server: simplify snr_set_srv_down() to prevent confusions snr_set_srv_down() (was formely known as snr_update_srv_status()), is still too ambiguous because it's not clear whether we will be putting the server under maintenance or not. This is mainly due to the fact that the function behaves differently if has_no_ip is set or not. By reviewing the function callers, it has now become clear that snr_resolution_cb() is always calling the function with a valid resolution so we only want to put the server under maintenance if we don't have a valid IP address. On the other hand snr_resolution_error_cb() always calls the function on error, with either no resolution (for SRV requests) or with failing resolution (all cases except RSLV_STATUS_VALID), so in this case we decide whether to put the server under maintenance case by case (ie: expired? timeout?) As a result, let's simplify snr_set_srv_down() so that it is only called when the caller really thinks that the server should be put under maintenance, which means always for snr_resolution_error_cb(), and only if the resolution didn't yield usable ip for snr_resolution_cb().
2023-12-22 08:17:41 -05:00
/*
* valid resolution but no usable server address
*/
srv_set_admin_flag(s, SRV_ADMF_RMAINT, SRV_ADM_STCHGC_DNS_NOIP);
MAJOR: dns: runtime resolution can change server admin state WARNING: this is a MAJOR (and disruptive) change with previous HAProxy's behavior: before, HAProxy never ever used to change a server administrative status when the DNS resolution failed at run time. This patch gives HAProxy the ability to change the administrative status of a server to MAINT (RMAINT actually) when an error is encountered for a period longer than its own allowed by the corresponding 'hold' parameter. IE if the configuration sets "hold nx 10s" and a server's hostname points to a NX for more than 10s, then the server will be set to RMAINT, hence in MAINTENANCE mode.
2016-11-02 17:58:18 -04:00
return 0;
case RSLV_STATUS_NX:
/* stop server if resolution is NX for a long enough period */
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
exp = tick_add(resolution->last_valid, resolvers->hold.nx);
if (!tick_is_expired(exp, now_ms))
MEDIUM: server: simplify snr_set_srv_down() to prevent confusions snr_set_srv_down() (was formely known as snr_update_srv_status()), is still too ambiguous because it's not clear whether we will be putting the server under maintenance or not. This is mainly due to the fact that the function behaves differently if has_no_ip is set or not. By reviewing the function callers, it has now become clear that snr_resolution_cb() is always calling the function with a valid resolution so we only want to put the server under maintenance if we don't have a valid IP address. On the other hand snr_resolution_error_cb() always calls the function on error, with either no resolution (for SRV requests) or with failing resolution (all cases except RSLV_STATUS_VALID), so in this case we decide whether to put the server under maintenance case by case (ie: expired? timeout?) As a result, let's simplify snr_set_srv_down() so that it is only called when the caller really thinks that the server should be put under maintenance, which means always for snr_resolution_error_cb(), and only if the resolution didn't yield usable ip for snr_resolution_cb().
2023-12-22 08:17:41 -05:00
goto out; // not yet expired
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
MINOR: server: change adm_st_chg_cause storage type Even though it doesn't look like it at first glance, this is more like a cleanup than an actual code improvement: Given that srv->adm_st_chg_cause has been used to exclusively store static strings ever since it was implemented, we make the choice to store it as an enum instead of a fixed-size string within server struct. This will allow to save some space in server struct, and will make it more easily exportable (ie: event handlers) because of the reduced memory footprint during handling and the ability to later get the corresponding human-readable message when it's explicitly needed.
2023-04-03 11:40:28 -04:00
srv_set_admin_flag(s, SRV_ADMF_RMAINT, SRV_ADM_STCHGC_DNS_NX);
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
return 0;
MAJOR: dns: runtime resolution can change server admin state WARNING: this is a MAJOR (and disruptive) change with previous HAProxy's behavior: before, HAProxy never ever used to change a server administrative status when the DNS resolution failed at run time. This patch gives HAProxy the ability to change the administrative status of a server to MAINT (RMAINT actually) when an error is encountered for a period longer than its own allowed by the corresponding 'hold' parameter. IE if the configuration sets "hold nx 10s" and a server's hostname points to a NX for more than 10s, then the server will be set to RMAINT, hence in MAINTENANCE mode.
2016-11-02 17:58:18 -04:00
case RSLV_STATUS_TIMEOUT:
/* stop server if resolution is TIMEOUT for a long enough period */
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
exp = tick_add(resolution->last_valid, resolvers->hold.timeout);
if (!tick_is_expired(exp, now_ms))
MEDIUM: server: simplify snr_set_srv_down() to prevent confusions snr_set_srv_down() (was formely known as snr_update_srv_status()), is still too ambiguous because it's not clear whether we will be putting the server under maintenance or not. This is mainly due to the fact that the function behaves differently if has_no_ip is set or not. By reviewing the function callers, it has now become clear that snr_resolution_cb() is always calling the function with a valid resolution so we only want to put the server under maintenance if we don't have a valid IP address. On the other hand snr_resolution_error_cb() always calls the function on error, with either no resolution (for SRV requests) or with failing resolution (all cases except RSLV_STATUS_VALID), so in this case we decide whether to put the server under maintenance case by case (ie: expired? timeout?) As a result, let's simplify snr_set_srv_down() so that it is only called when the caller really thinks that the server should be put under maintenance, which means always for snr_resolution_error_cb(), and only if the resolution didn't yield usable ip for snr_resolution_cb().
2023-12-22 08:17:41 -05:00
goto out; // not yet expired
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
MINOR: server: change adm_st_chg_cause storage type Even though it doesn't look like it at first glance, this is more like a cleanup than an actual code improvement: Given that srv->adm_st_chg_cause has been used to exclusively store static strings ever since it was implemented, we make the choice to store it as an enum instead of a fixed-size string within server struct. This will allow to save some space in server struct, and will make it more easily exportable (ie: event handlers) because of the reduced memory footprint during handling and the ability to later get the corresponding human-readable message when it's explicitly needed.
2023-04-03 11:40:28 -04:00
srv_set_admin_flag(s, SRV_ADMF_RMAINT, SRV_ADM_STCHGC_DNS_TIMEOUT);
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
return 0;
MAJOR: dns: runtime resolution can change server admin state WARNING: this is a MAJOR (and disruptive) change with previous HAProxy's behavior: before, HAProxy never ever used to change a server administrative status when the DNS resolution failed at run time. This patch gives HAProxy the ability to change the administrative status of a server to MAINT (RMAINT actually) when an error is encountered for a period longer than its own allowed by the corresponding 'hold' parameter. IE if the configuration sets "hold nx 10s" and a server's hostname points to a NX for more than 10s, then the server will be set to RMAINT, hence in MAINTENANCE mode.
2016-11-02 17:58:18 -04:00
case RSLV_STATUS_REFUSED:
/* stop server if resolution is REFUSED for a long enough period */
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
exp = tick_add(resolution->last_valid, resolvers->hold.refused);
if (!tick_is_expired(exp, now_ms))
MEDIUM: server: simplify snr_set_srv_down() to prevent confusions snr_set_srv_down() (was formely known as snr_update_srv_status()), is still too ambiguous because it's not clear whether we will be putting the server under maintenance or not. This is mainly due to the fact that the function behaves differently if has_no_ip is set or not. By reviewing the function callers, it has now become clear that snr_resolution_cb() is always calling the function with a valid resolution so we only want to put the server under maintenance if we don't have a valid IP address. On the other hand snr_resolution_error_cb() always calls the function on error, with either no resolution (for SRV requests) or with failing resolution (all cases except RSLV_STATUS_VALID), so in this case we decide whether to put the server under maintenance case by case (ie: expired? timeout?) As a result, let's simplify snr_set_srv_down() so that it is only called when the caller really thinks that the server should be put under maintenance, which means always for snr_resolution_error_cb(), and only if the resolution didn't yield usable ip for snr_resolution_cb().
2023-12-22 08:17:41 -05:00
goto out; // not yet expired
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
MINOR: server: change adm_st_chg_cause storage type Even though it doesn't look like it at first glance, this is more like a cleanup than an actual code improvement: Given that srv->adm_st_chg_cause has been used to exclusively store static strings ever since it was implemented, we make the choice to store it as an enum instead of a fixed-size string within server struct. This will allow to save some space in server struct, and will make it more easily exportable (ie: event handlers) because of the reduced memory footprint during handling and the ability to later get the corresponding human-readable message when it's explicitly needed.
2023-04-03 11:40:28 -04:00
srv_set_admin_flag(s, SRV_ADMF_RMAINT, SRV_ADM_STCHGC_DNS_REFUSED);
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
return 0;
MAJOR: dns: runtime resolution can change server admin state WARNING: this is a MAJOR (and disruptive) change with previous HAProxy's behavior: before, HAProxy never ever used to change a server administrative status when the DNS resolution failed at run time. This patch gives HAProxy the ability to change the administrative status of a server to MAINT (RMAINT actually) when an error is encountered for a period longer than its own allowed by the corresponding 'hold' parameter. IE if the configuration sets "hold nx 10s" and a server's hostname points to a NX for more than 10s, then the server will be set to RMAINT, hence in MAINTENANCE mode.
2016-11-02 17:58:18 -04:00
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
default:
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
/* stop server if resolution failed for a long enough period */
exp = tick_add(resolution->last_valid, resolvers->hold.other);
if (!tick_is_expired(exp, now_ms))
MEDIUM: server: simplify snr_set_srv_down() to prevent confusions snr_set_srv_down() (was formely known as snr_update_srv_status()), is still too ambiguous because it's not clear whether we will be putting the server under maintenance or not. This is mainly due to the fact that the function behaves differently if has_no_ip is set or not. By reviewing the function callers, it has now become clear that snr_resolution_cb() is always calling the function with a valid resolution so we only want to put the server under maintenance if we don't have a valid IP address. On the other hand snr_resolution_error_cb() always calls the function on error, with either no resolution (for SRV requests) or with failing resolution (all cases except RSLV_STATUS_VALID), so in this case we decide whether to put the server under maintenance case by case (ie: expired? timeout?) As a result, let's simplify snr_set_srv_down() so that it is only called when the caller really thinks that the server should be put under maintenance, which means always for snr_resolution_error_cb(), and only if the resolution didn't yield usable ip for snr_resolution_cb().
2023-12-22 08:17:41 -05:00
goto out; // not yet expired
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
MINOR: server: change adm_st_chg_cause storage type Even though it doesn't look like it at first glance, this is more like a cleanup than an actual code improvement: Given that srv->adm_st_chg_cause has been used to exclusively store static strings ever since it was implemented, we make the choice to store it as an enum instead of a fixed-size string within server struct. This will allow to save some space in server struct, and will make it more easily exportable (ie: event handlers) because of the reduced memory footprint during handling and the ability to later get the corresponding human-readable message when it's explicitly needed.
2023-04-03 11:40:28 -04:00
srv_set_admin_flag(s, SRV_ADMF_RMAINT, SRV_ADM_STCHGC_DNS_UNSPEC);
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
return 0;
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
}
MEDIUM: server: simplify snr_set_srv_down() to prevent confusions snr_set_srv_down() (was formely known as snr_update_srv_status()), is still too ambiguous because it's not clear whether we will be putting the server under maintenance or not. This is mainly due to the fact that the function behaves differently if has_no_ip is set or not. By reviewing the function callers, it has now become clear that snr_resolution_cb() is always calling the function with a valid resolution so we only want to put the server under maintenance if we don't have a valid IP address. On the other hand snr_resolution_error_cb() always calls the function on error, with either no resolution (for SRV requests) or with failing resolution (all cases except RSLV_STATUS_VALID), so in this case we decide whether to put the server under maintenance case by case (ie: expired? timeout?) As a result, let's simplify snr_set_srv_down() so that it is only called when the caller really thinks that the server should be put under maintenance, which means always for snr_resolution_error_cb(), and only if the resolution didn't yield usable ip for snr_resolution_cb().
2023-12-22 08:17:41 -05:00
out:
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
return 1;
}
/*
* Server Name Resolution valid response callback
* It expects:
* - <nameserver>: the name server which answered the valid response
* - <response>: buffer containing a valid DNS response
* - <response_len>: size of <response>
* It performs the following actions:
* - ignore response if current ip found and server family not met
* - update with first new ip found if family is met and current IP is not found
* returns:
* 0 on error
* 1 when no error or safe ignore
BUG/MINOR: dns: Don't lock the server lock in snr_check_ip_callback(). snr_check_ip_callback() may be called with the server lock, so don't attempt to lock it again, instead, make sure the callers always have the lock before calling it.
2017-11-06 11:30:28 -05:00
*
* Must be called with server lock held
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
*/
MINOR: resolvers: renames some resolvers specific types to not use dns prefix This patch applies those changes on names: -struct dns_resolution { +struct resolv_resolution { -struct dns_requester { +struct resolv_requester { -struct dns_srvrq { +struct resolv_srvrq { @@ -185,12 +185,12 @@ struct stream { struct { - struct dns_requester *dns_requester; + struct resolv_requester *requester; ... - } dns_ctx; + } resolv_ctx;
2020-12-23 11:41:43 -05:00
int snr_resolution_cb(struct resolv_requester *requester, struct dns_counters *counters)
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
{
MAJOR/REORG: dns: DNS resolution task and requester queues This patch is a major upgrade of the internal run-time DNS resolver in HAProxy and it brings the following 2 main changes: 1. DNS resolution task Up to now, DNS resolution was triggered by the health check task. From now, DNS resolution task is autonomous. It is started by HAProxy right after the scheduler is available and it is woken either when a network IO occurs for one of its nameserver or when a timeout is matched. From now, this means we can enable DNS resolution for a server without enabling health checking. 2. Introduction of a dns_requester structure Up to now, DNS resolution was purposely made for resolving server hostnames. The idea, is to ensure that any HAProxy internal object should be able to trigger a DNS resolution. For this purpose, 2 things has to be done: - clean up the DNS code from the server structure (this was already quite clean actually) and clean up the server's callbacks from manipulating too much DNS resolution - create an agnostic structure which allows linking a DNS resolution and a requester of any type (using obj_type enum) 3. Manage requesters through queues Up to now, there was an uniq relationship between a resolution and it's owner (aka the requester now). It's a shame, because in some cases, multiple objects may share the same hostname and may benefit from a resolution being performed by a third party. This patch introduces the notion of queues, which are basically lists of either currently running resolution or waiting ones. The resolutions are now available as a pool, which belongs to the resolvers. The pool has has a default size of 64 resolutions per resolvers and is allocated at configuration parsing.
2017-05-22 09:17:15 -04:00
struct server *s = NULL;
MINOR: resolvers: renames some resolvers specific types to not use dns prefix This patch applies those changes on names: -struct dns_resolution { +struct resolv_resolution { -struct dns_requester { +struct resolv_requester { -struct dns_srvrq { +struct resolv_srvrq { @@ -185,12 +185,12 @@ struct stream { struct { - struct dns_requester *dns_requester; + struct resolv_requester *requester; ... - } dns_ctx; + } resolv_ctx;
2020-12-23 11:41:43 -05:00
struct resolv_resolution *resolution = NULL;
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
void *serverip, *firstip;
short server_sin_family, firstip_sin_family;
int ret;
MINOR: dns: Cache previous DNS answers. As DNS servers may not return all IPs in one answer, we want to cache the previous entries. Those entries are removed when considered obsolete, which happens when the IP hasn't been returned by the DNS server for a time defined in the "hold obsolete" parameter of the resolver section. The default is 30s.
2017-07-06 12:46:47 -04:00
int has_no_ip = 0;
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
s = objt_server(requester->owner);
MAJOR/REORG: dns: DNS resolution task and requester queues This patch is a major upgrade of the internal run-time DNS resolver in HAProxy and it brings the following 2 main changes: 1. DNS resolution task Up to now, DNS resolution was triggered by the health check task. From now, DNS resolution task is autonomous. It is started by HAProxy right after the scheduler is available and it is woken either when a network IO occurs for one of its nameserver or when a timeout is matched. From now, this means we can enable DNS resolution for a server without enabling health checking. 2. Introduction of a dns_requester structure Up to now, DNS resolution was purposely made for resolving server hostnames. The idea, is to ensure that any HAProxy internal object should be able to trigger a DNS resolution. For this purpose, 2 things has to be done: - clean up the DNS code from the server structure (this was already quite clean actually) and clean up the server's callbacks from manipulating too much DNS resolution - create an agnostic structure which allows linking a DNS resolution and a requester of any type (using obj_type enum) 3. Manage requesters through queues Up to now, there was an uniq relationship between a resolution and it's owner (aka the requester now). It's a shame, because in some cases, multiple objects may share the same hostname and may benefit from a resolution being performed by a third party. This patch introduces the notion of queues, which are basically lists of either currently running resolution or waiting ones. The resolutions are now available as a pool, which belongs to the resolvers. The pool has has a default size of 64 resolutions per resolvers and is allocated at configuration parsing.
2017-05-22 09:17:15 -04:00
if (!s)
return 1;
BUG/MINOR; resolvers: Ignore DNS resolution for expired SRV item If no ADD item is found for a SRV item in a SRV response, a DNS resolution is triggered. When it succeeds, we must be sure the SRV item is still alive. Otherwise the DNS resolution must be ignored. This patch depends on the commit "MINOR: resolvers: Move last_seen time of an ADD into its corresponding SRV item". Both must be backported as far as 2.2.
2021-03-10 09:07:27 -05:00
if (s->srvrq) {
MEDIUM: resolvers: add a ref between servers and srv request or used SRV record This patch add a ref into servers to register them onto the record answer item used to set their hostnames. It also adds a head list into 'srvrq' to register servers free to be affected to a SRV record. A head of a tree is also added to srvrq to put servers which present a hotname in server state file. To re-link them fastly to the matching record as soon an item present the same name. This results in better performances on SRV record response parsing. This is an optimization but it could avoid to trigger the haproxy's internal wathdog in some circumstances. And for this reason it should be backported as far we can (2.0 ?)
2021-06-11 04:48:45 -04:00
/* If DNS resolution is disabled ignore it.
* This is the case if the server was associated to
* a SRV record and this record is now expired.
BUG/MINOR; resolvers: Ignore DNS resolution for expired SRV item If no ADD item is found for a SRV item in a SRV response, a DNS resolution is triggered. When it succeeds, we must be sure the SRV item is still alive. Otherwise the DNS resolution must be ignored. This patch depends on the commit "MINOR: resolvers: Move last_seen time of an ADD into its corresponding SRV item". Both must be backported as far as 2.2.
2021-03-10 09:07:27 -05:00
*/
MEDIUM: resolvers: add a ref between servers and srv request or used SRV record This patch add a ref into servers to register them onto the record answer item used to set their hostnames. It also adds a head list into 'srvrq' to register servers free to be affected to a SRV record. A head of a tree is also added to srvrq to put servers which present a hotname in server state file. To re-link them fastly to the matching record as soon an item present the same name. This results in better performances on SRV record response parsing. This is an optimization but it could avoid to trigger the haproxy's internal wathdog in some circumstances. And for this reason it should be backported as far we can (2.0 ?)
2021-06-11 04:48:45 -04:00
if (s->flags & SRV_F_NO_RESOLUTION)
BUG/MINOR; resolvers: Ignore DNS resolution for expired SRV item If no ADD item is found for a SRV item in a SRV response, a DNS resolution is triggered. When it succeeds, we must be sure the SRV item is still alive. Otherwise the DNS resolution must be ignored. This patch depends on the commit "MINOR: resolvers: Move last_seen time of an ADD into its corresponding SRV item". Both must be backported as far as 2.2.
2021-03-10 09:07:27 -05:00
return 1;
}
BUG/MEDIUM: resolvers: Skip DNS resolution at startup if SRV resolution is set At startup, if a SRV resolution is set for a server, no DNS resolution is created. We must wait the first SRV resolution to know if it must be triggered. It is important to do so for two reasons. First, during a "classical" startup, a server based on a SRV resolution has no hostname. Thus the created DNS resolution is useless. Best waiting the first SRV resolution. It is not really a bug at this stage, it is just useless. Second, in the same situation, if the server state is loaded from a file, its hosname will be set a bit later. Thus, if there is no additionnal record for this server, because there is already a DNS resolution, it inhibits any new DNS resolution. But there is no hostname attached to the existing DNS resolution. So no resolution is performed at all for this server. To avoid any problem, it is fairly easier to handle this special case during startup. But this means we must be prepared to have no "resolv_requester" field for a server at runtime. This patch must be backported as far as 2.2.
2021-03-12 04:23:05 -05:00
resolution = (s->resolv_requester ? s->resolv_requester->resolution : NULL);
BUG/MINOR; resolvers: Ignore DNS resolution for expired SRV item If no ADD item is found for a SRV item in a SRV response, a DNS resolution is triggered. When it succeeds, we must be sure the SRV item is still alive. Otherwise the DNS resolution must be ignored. This patch depends on the commit "MINOR: resolvers: Move last_seen time of an ADD into its corresponding SRV item". Both must be backported as far as 2.2.
2021-03-10 09:07:27 -05:00
if (!resolution)
return 1;
MAJOR/REORG: dns: DNS resolution task and requester queues This patch is a major upgrade of the internal run-time DNS resolver in HAProxy and it brings the following 2 main changes: 1. DNS resolution task Up to now, DNS resolution was triggered by the health check task. From now, DNS resolution task is autonomous. It is started by HAProxy right after the scheduler is available and it is woken either when a network IO occurs for one of its nameserver or when a timeout is matched. From now, this means we can enable DNS resolution for a server without enabling health checking. 2. Introduction of a dns_requester structure Up to now, DNS resolution was purposely made for resolving server hostnames. The idea, is to ensure that any HAProxy internal object should be able to trigger a DNS resolution. For this purpose, 2 things has to be done: - clean up the DNS code from the server structure (this was already quite clean actually) and clean up the server's callbacks from manipulating too much DNS resolution - create an agnostic structure which allows linking a DNS resolution and a requester of any type (using obj_type enum) 3. Manage requesters through queues Up to now, there was an uniq relationship between a resolution and it's owner (aka the requester now). It's a shame, because in some cases, multiple objects may share the same hostname and may benefit from a resolution being performed by a third party. This patch introduces the notion of queues, which are basically lists of either currently running resolution or waiting ones. The resolutions are now available as a pool, which belongs to the resolvers. The pool has has a default size of 64 resolutions per resolvers and is allocated at configuration parsing.
2017-05-22 09:17:15 -04:00
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
/* initializing variables */
firstip = NULL; /* pointer to the first valid response found */
/* it will be used as the new IP if a change is required */
firstip_sin_family = AF_UNSPEC;
serverip = NULL; /* current server IP address */
/* initializing server IP pointer */
server_sin_family = s->addr.ss_family;
switch (server_sin_family) {
case AF_INET:
serverip = &((struct sockaddr_in *)&s->addr)->sin_addr.s_addr;
break;
case AF_INET6:
serverip = &((struct sockaddr_in6 *)&s->addr)->sin6_addr.s6_addr;
break;
BUG/MEDIUM: server: consider AF_UNSPEC as a valid address family The DNS code is written so as to support AF_UNSPEC to decide on the server family based on responses, but unfortunately snr_resolution_cb() considers it as invalid causing a DNS storm to happen when a server arrives with this family. This situation is not supposed to happen as long as unresolved addresses are forced to AF_INET, but this will change with the upcoming fixes and it's possible that it's not granted already when changing an address on the CLI. This fix must be backported to 1.7 and 1.6.
2017-01-06 13:18:32 -05:00
case AF_UNSPEC:
break;
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
default:
goto invalid;
}
MINOR: resolvers: rework prototype suffixes to split resolving and dns. A lot of prototypes in dns.h are specific to resolvers and must be renamed to split resolving and DNS layers.
2020-12-23 12:49:16 -05:00
ret = resolv_get_ip_from_response(&resolution->response, &s->resolv_opts,
serverip, server_sin_family, &firstip,
&firstip_sin_family, s);
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
switch (ret) {
MINOR: resolvers: renames resolvers DNS_UPD_* returncodes to RSLV_UPD_* This patch renames some #defines prefixes from DNS to RSLV.
2020-12-23 12:17:31 -05:00
case RSLV_UPD_NO:
MAJOR/REORG: dns: DNS resolution task and requester queues This patch is a major upgrade of the internal run-time DNS resolver in HAProxy and it brings the following 2 main changes: 1. DNS resolution task Up to now, DNS resolution was triggered by the health check task. From now, DNS resolution task is autonomous. It is started by HAProxy right after the scheduler is available and it is woken either when a network IO occurs for one of its nameserver or when a timeout is matched. From now, this means we can enable DNS resolution for a server without enabling health checking. 2. Introduction of a dns_requester structure Up to now, DNS resolution was purposely made for resolving server hostnames. The idea, is to ensure that any HAProxy internal object should be able to trigger a DNS resolution. For this purpose, 2 things has to be done: - clean up the DNS code from the server structure (this was already quite clean actually) and clean up the server's callbacks from manipulating too much DNS resolution - create an agnostic structure which allows linking a DNS resolution and a requester of any type (using obj_type enum) 3. Manage requesters through queues Up to now, there was an uniq relationship between a resolution and it's owner (aka the requester now). It's a shame, because in some cases, multiple objects may share the same hostname and may benefit from a resolution being performed by a third party. This patch introduces the notion of queues, which are basically lists of either currently running resolution or waiting ones. The resolutions are now available as a pool, which belongs to the resolvers. The pool has has a default size of 64 resolutions per resolvers and is allocated at configuration parsing.
2017-05-22 09:17:15 -04:00
goto update_status;
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
MINOR: resolvers: renames resolvers DNS_UPD_* returncodes to RSLV_UPD_* This patch renames some #defines prefixes from DNS to RSLV.
2020-12-23 12:17:31 -05:00
case RSLV_UPD_SRVIP_NOT_FOUND:
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
goto save_ip;
MINOR: resolvers: renames resolvers DNS_UPD_* returncodes to RSLV_UPD_* This patch renames some #defines prefixes from DNS to RSLV.
2020-12-23 12:17:31 -05:00
case RSLV_UPD_NO_IP_FOUND:
MINOR: dns: Cache previous DNS answers. As DNS servers may not return all IPs in one answer, we want to cache the previous entries. Those entries are removed when considered obsolete, which happens when the IP hasn't been returned by the DNS server for a time defined in the "hold obsolete" parameter of the resolver section. The default is 30s.
2017-07-06 12:46:47 -04:00
has_no_ip = 1;
MAJOR/REORG: dns: DNS resolution task and requester queues This patch is a major upgrade of the internal run-time DNS resolver in HAProxy and it brings the following 2 main changes: 1. DNS resolution task Up to now, DNS resolution was triggered by the health check task. From now, DNS resolution task is autonomous. It is started by HAProxy right after the scheduler is available and it is woken either when a network IO occurs for one of its nameserver or when a timeout is matched. From now, this means we can enable DNS resolution for a server without enabling health checking. 2. Introduction of a dns_requester structure Up to now, DNS resolution was purposely made for resolving server hostnames. The idea, is to ensure that any HAProxy internal object should be able to trigger a DNS resolution. For this purpose, 2 things has to be done: - clean up the DNS code from the server structure (this was already quite clean actually) and clean up the server's callbacks from manipulating too much DNS resolution - create an agnostic structure which allows linking a DNS resolution and a requester of any type (using obj_type enum) 3. Manage requesters through queues Up to now, there was an uniq relationship between a resolution and it's owner (aka the requester now). It's a shame, because in some cases, multiple objects may share the same hostname and may benefit from a resolution being performed by a third party. This patch introduces the notion of queues, which are basically lists of either currently running resolution or waiting ones. The resolutions are now available as a pool, which belongs to the resolvers. The pool has has a default size of 64 resolutions per resolvers and is allocated at configuration parsing.
2017-05-22 09:17:15 -04:00
goto update_status;
MINOR: dns: new flag to report that no IP can be found in a DNS response packet Some DNS response may be valid from a protocol point of view but may not contain any IP addresses. This patch gives a new flag to the function dns_get_ip_from_response to report such case. It's up to the upper layer to decide what to do with this information.
2015-09-08 18:51:08 -04:00
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
default:
MINOR: resolvers: Reset server IP on error in resolv_get_ip_from_response() If resolv_get_ip_from_response() returns an error (or an unexpected return value), the server is set to RMAINT status. However, its address must also be reset. Otherwise, it is still reported by the cli on "show servers state" commands. This may be confusing. Note that it is a theorical patch because this code path does not exist. Thus it is not tagged as a BUG. This patch may be backported as far as 2.0.
2021-06-24 09:33:52 -04:00
has_no_ip = 1;
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
goto invalid;
}
save_ip:
BUG/MINOR: dns: add missing sent counter and parent id to dns counters. Resolv callbacks are also updated to rely on counters and not on nameservers. "show stat domain dns" will now show the parent id (i.e. resolvers section name).
2021-01-04 04:40:46 -05:00
if (counters) {
MINOR: resolvers/dns: split dns and resolver counters in dns_counter struct This patch add a union and struct into dns_counter struct to split application specific counters. The only current existing application is the resolver.c layer but in futur we could handle different application such as dns load balancing with others specific counters. This patch should not be backported.
2021-10-29 11:30:41 -04:00
counters->app.resolver.update++;
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
/* save the first ip we found */
MEDIUM: server: make server_set_inetaddr() updater serializable server_set_inetaddr() updater argument is a simple char * string containing infos about the caller responsible for the update. In this patch, we try to make this argument serializable, that is, make it so that we can easily export it without having to keep the original pointer passed by the caller or having to work with strings of variable lengths. This was a prerequisite for exposing more updater information through SERVER_INETADDR event (upcoming patch). Static strings were simply mapped to a fixed ID that can be converted back to a string when needed using server_inetaddr_updater_by_to_str(). One special case one made for the SERVER_INETADDR_UPDATER_DNS_RESOLVER updater since in this case the updater hint has to be generated from the corresponding resolver id / nameserver id combination. This was achieved by saving the nameserver id within the updater struct. Knowing that the resolver id can be guessed from the server struct directly, it was not exposed through the updater struct. This patch depends on: - "MINOR: resolvers: add unique numeric id to nameservers" No functional change should be expected.
2023-12-11 09:06:43 -05:00
srv_update_addr(s, firstip, firstip_sin_family,
SERVER_INETADDR_UPDATER_DNS_RESOLVER(counters->ns_puid));
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
}
MAJOR/REORG: dns: DNS resolution task and requester queues This patch is a major upgrade of the internal run-time DNS resolver in HAProxy and it brings the following 2 main changes: 1. DNS resolution task Up to now, DNS resolution was triggered by the health check task. From now, DNS resolution task is autonomous. It is started by HAProxy right after the scheduler is available and it is woken either when a network IO occurs for one of its nameserver or when a timeout is matched. From now, this means we can enable DNS resolution for a server without enabling health checking. 2. Introduction of a dns_requester structure Up to now, DNS resolution was purposely made for resolving server hostnames. The idea, is to ensure that any HAProxy internal object should be able to trigger a DNS resolution. For this purpose, 2 things has to be done: - clean up the DNS code from the server structure (this was already quite clean actually) and clean up the server's callbacks from manipulating too much DNS resolution - create an agnostic structure which allows linking a DNS resolution and a requester of any type (using obj_type enum) 3. Manage requesters through queues Up to now, there was an uniq relationship between a resolution and it's owner (aka the requester now). It's a shame, because in some cases, multiple objects may share the same hostname and may benefit from a resolution being performed by a third party. This patch introduces the notion of queues, which are basically lists of either currently running resolution or waiting ones. The resolutions are now available as a pool, which belongs to the resolvers. The pool has has a default size of 64 resolutions per resolvers and is allocated at configuration parsing.
2017-05-22 09:17:15 -04:00
else
MEDIUM: server: make server_set_inetaddr() updater serializable server_set_inetaddr() updater argument is a simple char * string containing infos about the caller responsible for the update. In this patch, we try to make this argument serializable, that is, make it so that we can easily export it without having to keep the original pointer passed by the caller or having to work with strings of variable lengths. This was a prerequisite for exposing more updater information through SERVER_INETADDR event (upcoming patch). Static strings were simply mapped to a fixed ID that can be converted back to a string when needed using server_inetaddr_updater_by_to_str(). One special case one made for the SERVER_INETADDR_UPDATER_DNS_RESOLVER updater since in this case the updater hint has to be generated from the corresponding resolver id / nameserver id combination. This was achieved by saving the nameserver id within the updater struct. Knowing that the resolver id can be guessed from the server struct directly, it was not exposed through the updater struct. This patch depends on: - "MINOR: resolvers: add unique numeric id to nameservers" No functional change should be expected.
2023-12-11 09:06:43 -05:00
srv_update_addr(s, firstip, firstip_sin_family, SERVER_INETADDR_UPDATER_DNS_CACHE);
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
MAJOR/REORG: dns: DNS resolution task and requester queues This patch is a major upgrade of the internal run-time DNS resolver in HAProxy and it brings the following 2 main changes: 1. DNS resolution task Up to now, DNS resolution was triggered by the health check task. From now, DNS resolution task is autonomous. It is started by HAProxy right after the scheduler is available and it is woken either when a network IO occurs for one of its nameserver or when a timeout is matched. From now, this means we can enable DNS resolution for a server without enabling health checking. 2. Introduction of a dns_requester structure Up to now, DNS resolution was purposely made for resolving server hostnames. The idea, is to ensure that any HAProxy internal object should be able to trigger a DNS resolution. For this purpose, 2 things has to be done: - clean up the DNS code from the server structure (this was already quite clean actually) and clean up the server's callbacks from manipulating too much DNS resolution - create an agnostic structure which allows linking a DNS resolution and a requester of any type (using obj_type enum) 3. Manage requesters through queues Up to now, there was an uniq relationship between a resolution and it's owner (aka the requester now). It's a shame, because in some cases, multiple objects may share the same hostname and may benefit from a resolution being performed by a third party. This patch introduces the notion of queues, which are basically lists of either currently running resolution or waiting ones. The resolutions are now available as a pool, which belongs to the resolvers. The pool has has a default size of 64 resolutions per resolvers and is allocated at configuration parsing.
2017-05-22 09:17:15 -04:00
update_status:
MEDIUM: server: simplify snr_set_srv_down() to prevent confusions snr_set_srv_down() (was formely known as snr_update_srv_status()), is still too ambiguous because it's not clear whether we will be putting the server under maintenance or not. This is mainly due to the fact that the function behaves differently if has_no_ip is set or not. By reviewing the function callers, it has now become clear that snr_resolution_cb() is always calling the function with a valid resolution so we only want to put the server under maintenance if we don't have a valid IP address. On the other hand snr_resolution_error_cb() always calls the function on error, with either no resolution (for SRV requests) or with failing resolution (all cases except RSLV_STATUS_VALID), so in this case we decide whether to put the server under maintenance case by case (ie: expired? timeout?) As a result, let's simplify snr_set_srv_down() so that it is only called when the caller really thinks that the server should be put under maintenance, which means always for snr_resolution_error_cb(), and only if the resolution didn't yield usable ip for snr_resolution_cb().
2023-12-22 08:17:41 -05:00
if (has_no_ip && !snr_set_srv_down(s)) {
BUILD: solaris: fix compilation errors Compilation on solaris fails because of usage of names reserved on that platform, i.e. 'queue' and 's_addr'. This patch redefines 'queue' as '_queue' and renames 's_addr' to 'srv_addr' which fixes compilation for now. Future plan: rename 'queue' in code base so define can be removed again. Backporting: 2.9, 2.8
2024-02-23 11:05:01 -05:00
struct server_inetaddr srv_addr;
BUG/MINOR: server/dns: use server_set_inetaddr() to unset srv addr from DNS As seen before, server's addr and svc_port should not be updated directly during runtime, because even if the update is performed under the lock, some competing threads might be reading ->addr and ->svc_port without the lock because they simply cannot afford it. To prevent races with such competing threads, server's addr and port should only be updated using server_set_inetaddr() function or similar. This patch depends on: - "MINOR: server: ensure connection cleanup on server addr changes" - "CLEANUP: server/event_hdl: remove purge_conn hint in INETADDR event" - "MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic" - "MEDIUM: server: make server_set_inetaddr() updater serializable" - "MINOR: server/event_hdl: expose updater info through INETADDR event" - "MINOR: server: add dns hint in server_inetaddr_updater struct" - "MEDIUM: server/dns: clear RMAINT when addr resolves again" While it could be backported in 2.9 with cd994407a ("BUG/MAJOR: server/addr: fix a race during server addr:svc_port updates") to ensure addr and svc_port reset performed by resolver's code comply with the API taking care of pushing the update (and thus avoid any race), some patch dependencies are quite sensitive so it's probably best to avoid backporting for no good reason, or at least wait for it to be considered stable to prevent any breakeages.
2023-12-11 11:31:31 -05:00
BUG/MEDIUM: server/dns: preserve server's port upon resolution timeout or error @boi4 reported in GH #2578 that since 3.0-dev1 for servers with address learned from A/AAAA records after a DNS flap server would be put out of maintenance with proper address but with invalid port (== 0), making it unusable and causing tcp checks to fail: [NOTICE] (1) : Loading success. [WARNING] (8) : Server mybackend/myserver1 is going DOWN for maintenance (DNS refused status). 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. [ALERT] (8) : backend 'mybackend' has no server available! [WARNING] (8) : mybackend/myserver1: IP changed from '(none)' to '127.0.0.1' by 'myresolver/ns1'. [WARNING] (8) : Server mybackend/myserver1 ('myhost') is UP/READY (resolves again). [WARNING] (8) : Server mybackend/myserver1 administratively READY thanks to valid DNS answer. [WARNING] (8) : Server mybackend/myserver1 is DOWN, reason: Layer4 connection problem, info: "Connection refused", check duration: 0ms. 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. @boi4 also mentioned that this used to work fine before. Willy suggested that this regression may have been introduced by 64c9c8e ("BUG/MINOR: server/dns: use server_set_inetaddr() to unset srv addr from DNS") Turns out he was right! Indeed, in 64c9c8e we systematically memset the whole server_inetaddr struct (which contains both the requested server's addr and port planned for atomic update) instead of only memsetting the addr part of the structure: except when SRV records are involved (SRV records provide both the address and the port unlike A or AAAA records), we must not reset the server's port upon DNS errors because the port may have been provided at config time and we don't want to lose its value. Big thanks to @boi4 for his well-documented issue that really helped us to pinpoint the bug right on time for the dev-13 release. No backport needed (unless 64c9c8e gets backported).
2024-05-24 07:55:41 -04:00
/* unset server's addr, keep port */
server_get_inetaddr(s, &srv_addr);
BUG/MEDIUM: server/dns: prevent DOWN/UP flap upon resolution timeout or error This is a complementary patch to c16eba818 ("BUG/MEDIUM: server/dns: preserve server's port upon resolution timeout or error"). Indeed, since c16eba818, the port is properly preserved, but unsetting server's address this way results in server_atomic_sync() function thinking that we're actually setting a new address and not unsetting the previous one because addr family is != AF_UNSPEC. Upon DNS timeout, this could be observed: [WARNING] (2588257) : Server http/s1 is going DOWN for maintenance (DNS timeout status). 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. [WARNING] (2588257) : Server http/s1 ('test1.localhost') is UP/READY (resolves again). Notice that server timeouts and then immediately resolves again. Of course in this case case the server's address was properly set to 0, meaning that the server will not receive any traffic, but it is confusing and could result in haproxy temporarily thinking that the server is actually available while it's not. To properly fix the issue and restore historical behavior, let's explicitly set inetaddr's family to AF_UNSPEC after fetching original server's address. It should be backported in 3.0 with c16eba818.
2024-06-28 03:41:56 -04:00
srv_addr.family = AF_UNSPEC;
BUG/MEDIUM: server/dns: preserve server's port upon resolution timeout or error @boi4 reported in GH #2578 that since 3.0-dev1 for servers with address learned from A/AAAA records after a DNS flap server would be put out of maintenance with proper address but with invalid port (== 0), making it unusable and causing tcp checks to fail: [NOTICE] (1) : Loading success. [WARNING] (8) : Server mybackend/myserver1 is going DOWN for maintenance (DNS refused status). 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. [ALERT] (8) : backend 'mybackend' has no server available! [WARNING] (8) : mybackend/myserver1: IP changed from '(none)' to '127.0.0.1' by 'myresolver/ns1'. [WARNING] (8) : Server mybackend/myserver1 ('myhost') is UP/READY (resolves again). [WARNING] (8) : Server mybackend/myserver1 administratively READY thanks to valid DNS answer. [WARNING] (8) : Server mybackend/myserver1 is DOWN, reason: Layer4 connection problem, info: "Connection refused", check duration: 0ms. 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. @boi4 also mentioned that this used to work fine before. Willy suggested that this regression may have been introduced by 64c9c8e ("BUG/MINOR: server/dns: use server_set_inetaddr() to unset srv addr from DNS") Turns out he was right! Indeed, in 64c9c8e we systematically memset the whole server_inetaddr struct (which contains both the requested server's addr and port planned for atomic update) instead of only memsetting the addr part of the structure: except when SRV records are involved (SRV records provide both the address and the port unlike A or AAAA records), we must not reset the server's port upon DNS errors because the port may have been provided at config time and we don't want to lose its value. Big thanks to @boi4 for his well-documented issue that really helped us to pinpoint the bug right on time for the dev-13 release. No backport needed (unless 64c9c8e gets backported).
2024-05-24 07:55:41 -04:00
memset(&srv_addr.addr, 0, sizeof(srv_addr.addr));
BUILD: solaris: fix compilation errors Compilation on solaris fails because of usage of names reserved on that platform, i.e. 'queue' and 's_addr'. This patch redefines 'queue' as '_queue' and renames 's_addr' to 'srv_addr' which fixes compilation for now. Future plan: rename 'queue' in code base so define can be removed again. Backporting: 2.9, 2.8
2024-02-23 11:05:01 -05:00
server_set_inetaddr(s, &srv_addr, SERVER_INETADDR_UPDATER_NONE, NULL);
BUG/MINOR: server/dns: use server_set_inetaddr() to unset srv addr from DNS As seen before, server's addr and svc_port should not be updated directly during runtime, because even if the update is performed under the lock, some competing threads might be reading ->addr and ->svc_port without the lock because they simply cannot afford it. To prevent races with such competing threads, server's addr and port should only be updated using server_set_inetaddr() function or similar. This patch depends on: - "MINOR: server: ensure connection cleanup on server addr changes" - "CLEANUP: server/event_hdl: remove purge_conn hint in INETADDR event" - "MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic" - "MEDIUM: server: make server_set_inetaddr() updater serializable" - "MINOR: server/event_hdl: expose updater info through INETADDR event" - "MINOR: server: add dns hint in server_inetaddr_updater struct" - "MEDIUM: server/dns: clear RMAINT when addr resolves again" While it could be backported in 2.9 with cd994407a ("BUG/MAJOR: server/addr: fix a race during server addr:svc_port updates") to ensure addr and svc_port reset performed by resolver's code comply with the API taking care of pushing the update (and thus avoid any race), some patch dependencies are quite sensitive so it's probably best to avoid backporting for no good reason, or at least wait for it to be considered stable to prevent any breakeages.
2023-12-11 11:31:31 -05:00
}
MAJOR/REORG: dns: DNS resolution task and requester queues This patch is a major upgrade of the internal run-time DNS resolver in HAProxy and it brings the following 2 main changes: 1. DNS resolution task Up to now, DNS resolution was triggered by the health check task. From now, DNS resolution task is autonomous. It is started by HAProxy right after the scheduler is available and it is woken either when a network IO occurs for one of its nameserver or when a timeout is matched. From now, this means we can enable DNS resolution for a server without enabling health checking. 2. Introduction of a dns_requester structure Up to now, DNS resolution was purposely made for resolving server hostnames. The idea, is to ensure that any HAProxy internal object should be able to trigger a DNS resolution. For this purpose, 2 things has to be done: - clean up the DNS code from the server structure (this was already quite clean actually) and clean up the server's callbacks from manipulating too much DNS resolution - create an agnostic structure which allows linking a DNS resolution and a requester of any type (using obj_type enum) 3. Manage requesters through queues Up to now, there was an uniq relationship between a resolution and it's owner (aka the requester now). It's a shame, because in some cases, multiple objects may share the same hostname and may benefit from a resolution being performed by a third party. This patch introduces the notion of queues, which are basically lists of either currently running resolution or waiting ones. The resolutions are now available as a pool, which belongs to the resolvers. The pool has has a default size of 64 resolutions per resolvers and is allocated at configuration parsing.
2017-05-22 09:17:15 -04:00
return 1;
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
invalid:
BUG/MINOR: dns: add missing sent counter and parent id to dns counters. Resolv callbacks are also updated to rely on counters and not on nameservers. "show stat domain dns" will now show the parent id (i.e. resolvers section name).
2021-01-04 04:40:46 -05:00
if (counters) {
MINOR: resolvers/dns: split dns and resolver counters in dns_counter struct This patch add a union and struct into dns_counter struct to split application specific counters. The only current existing application is the resolver.c layer but in futur we could handle different application such as dns load balancing with others specific counters. This patch should not be backported.
2021-10-29 11:30:41 -04:00
counters->app.resolver.invalid++;
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
goto update_status;
BUG/MINOR: dns: Fix check on nameserver in snr_resolution_cb snr_resolution_cb can be called with <nameserver> parameter set to NULL. So we must check it before using it. This is done most of time, except when we deal with invalid DNS response.
2017-09-15 05:55:45 -04:00
}
MEDIUM: server: simplify snr_set_srv_down() to prevent confusions snr_set_srv_down() (was formely known as snr_update_srv_status()), is still too ambiguous because it's not clear whether we will be putting the server under maintenance or not. This is mainly due to the fact that the function behaves differently if has_no_ip is set or not. By reviewing the function callers, it has now become clear that snr_resolution_cb() is always calling the function with a valid resolution so we only want to put the server under maintenance if we don't have a valid IP address. On the other hand snr_resolution_error_cb() always calls the function on error, with either no resolution (for SRV requests) or with failing resolution (all cases except RSLV_STATUS_VALID), so in this case we decide whether to put the server under maintenance case by case (ie: expired? timeout?) As a result, let's simplify snr_set_srv_down() so that it is only called when the caller really thinks that the server should be put under maintenance, which means always for snr_resolution_error_cb(), and only if the resolution didn't yield usable ip for snr_resolution_cb().
2023-12-22 08:17:41 -05:00
if (has_no_ip && !snr_set_srv_down(s)) {
BUILD: solaris: fix compilation errors Compilation on solaris fails because of usage of names reserved on that platform, i.e. 'queue' and 's_addr'. This patch redefines 'queue' as '_queue' and renames 's_addr' to 'srv_addr' which fixes compilation for now. Future plan: rename 'queue' in code base so define can be removed again. Backporting: 2.9, 2.8
2024-02-23 11:05:01 -05:00
struct server_inetaddr srv_addr;
BUG/MINOR: server/dns: use server_set_inetaddr() to unset srv addr from DNS As seen before, server's addr and svc_port should not be updated directly during runtime, because even if the update is performed under the lock, some competing threads might be reading ->addr and ->svc_port without the lock because they simply cannot afford it. To prevent races with such competing threads, server's addr and port should only be updated using server_set_inetaddr() function or similar. This patch depends on: - "MINOR: server: ensure connection cleanup on server addr changes" - "CLEANUP: server/event_hdl: remove purge_conn hint in INETADDR event" - "MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic" - "MEDIUM: server: make server_set_inetaddr() updater serializable" - "MINOR: server/event_hdl: expose updater info through INETADDR event" - "MINOR: server: add dns hint in server_inetaddr_updater struct" - "MEDIUM: server/dns: clear RMAINT when addr resolves again" While it could be backported in 2.9 with cd994407a ("BUG/MAJOR: server/addr: fix a race during server addr:svc_port updates") to ensure addr and svc_port reset performed by resolver's code comply with the API taking care of pushing the update (and thus avoid any race), some patch dependencies are quite sensitive so it's probably best to avoid backporting for no good reason, or at least wait for it to be considered stable to prevent any breakeages.
2023-12-11 11:31:31 -05:00
BUG/MEDIUM: server/dns: preserve server's port upon resolution timeout or error @boi4 reported in GH #2578 that since 3.0-dev1 for servers with address learned from A/AAAA records after a DNS flap server would be put out of maintenance with proper address but with invalid port (== 0), making it unusable and causing tcp checks to fail: [NOTICE] (1) : Loading success. [WARNING] (8) : Server mybackend/myserver1 is going DOWN for maintenance (DNS refused status). 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. [ALERT] (8) : backend 'mybackend' has no server available! [WARNING] (8) : mybackend/myserver1: IP changed from '(none)' to '127.0.0.1' by 'myresolver/ns1'. [WARNING] (8) : Server mybackend/myserver1 ('myhost') is UP/READY (resolves again). [WARNING] (8) : Server mybackend/myserver1 administratively READY thanks to valid DNS answer. [WARNING] (8) : Server mybackend/myserver1 is DOWN, reason: Layer4 connection problem, info: "Connection refused", check duration: 0ms. 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. @boi4 also mentioned that this used to work fine before. Willy suggested that this regression may have been introduced by 64c9c8e ("BUG/MINOR: server/dns: use server_set_inetaddr() to unset srv addr from DNS") Turns out he was right! Indeed, in 64c9c8e we systematically memset the whole server_inetaddr struct (which contains both the requested server's addr and port planned for atomic update) instead of only memsetting the addr part of the structure: except when SRV records are involved (SRV records provide both the address and the port unlike A or AAAA records), we must not reset the server's port upon DNS errors because the port may have been provided at config time and we don't want to lose its value. Big thanks to @boi4 for his well-documented issue that really helped us to pinpoint the bug right on time for the dev-13 release. No backport needed (unless 64c9c8e gets backported).
2024-05-24 07:55:41 -04:00
/* unset server's addr, keep port */
server_get_inetaddr(s, &srv_addr);
BUG/MEDIUM: server/dns: prevent DOWN/UP flap upon resolution timeout or error This is a complementary patch to c16eba818 ("BUG/MEDIUM: server/dns: preserve server's port upon resolution timeout or error"). Indeed, since c16eba818, the port is properly preserved, but unsetting server's address this way results in server_atomic_sync() function thinking that we're actually setting a new address and not unsetting the previous one because addr family is != AF_UNSPEC. Upon DNS timeout, this could be observed: [WARNING] (2588257) : Server http/s1 is going DOWN for maintenance (DNS timeout status). 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. [WARNING] (2588257) : Server http/s1 ('test1.localhost') is UP/READY (resolves again). Notice that server timeouts and then immediately resolves again. Of course in this case case the server's address was properly set to 0, meaning that the server will not receive any traffic, but it is confusing and could result in haproxy temporarily thinking that the server is actually available while it's not. To properly fix the issue and restore historical behavior, let's explicitly set inetaddr's family to AF_UNSPEC after fetching original server's address. It should be backported in 3.0 with c16eba818.
2024-06-28 03:41:56 -04:00
srv_addr.family = AF_UNSPEC;
BUG/MEDIUM: server/dns: preserve server's port upon resolution timeout or error @boi4 reported in GH #2578 that since 3.0-dev1 for servers with address learned from A/AAAA records after a DNS flap server would be put out of maintenance with proper address but with invalid port (== 0), making it unusable and causing tcp checks to fail: [NOTICE] (1) : Loading success. [WARNING] (8) : Server mybackend/myserver1 is going DOWN for maintenance (DNS refused status). 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. [ALERT] (8) : backend 'mybackend' has no server available! [WARNING] (8) : mybackend/myserver1: IP changed from '(none)' to '127.0.0.1' by 'myresolver/ns1'. [WARNING] (8) : Server mybackend/myserver1 ('myhost') is UP/READY (resolves again). [WARNING] (8) : Server mybackend/myserver1 administratively READY thanks to valid DNS answer. [WARNING] (8) : Server mybackend/myserver1 is DOWN, reason: Layer4 connection problem, info: "Connection refused", check duration: 0ms. 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. @boi4 also mentioned that this used to work fine before. Willy suggested that this regression may have been introduced by 64c9c8e ("BUG/MINOR: server/dns: use server_set_inetaddr() to unset srv addr from DNS") Turns out he was right! Indeed, in 64c9c8e we systematically memset the whole server_inetaddr struct (which contains both the requested server's addr and port planned for atomic update) instead of only memsetting the addr part of the structure: except when SRV records are involved (SRV records provide both the address and the port unlike A or AAAA records), we must not reset the server's port upon DNS errors because the port may have been provided at config time and we don't want to lose its value. Big thanks to @boi4 for his well-documented issue that really helped us to pinpoint the bug right on time for the dev-13 release. No backport needed (unless 64c9c8e gets backported).
2024-05-24 07:55:41 -04:00
memset(&srv_addr.addr, 0, sizeof(srv_addr.addr));
BUILD: solaris: fix compilation errors Compilation on solaris fails because of usage of names reserved on that platform, i.e. 'queue' and 's_addr'. This patch redefines 'queue' as '_queue' and renames 's_addr' to 'srv_addr' which fixes compilation for now. Future plan: rename 'queue' in code base so define can be removed again. Backporting: 2.9, 2.8
2024-02-23 11:05:01 -05:00
server_set_inetaddr(s, &srv_addr, SERVER_INETADDR_UPDATER_NONE, NULL);
BUG/MINOR: server/dns: use server_set_inetaddr() to unset srv addr from DNS As seen before, server's addr and svc_port should not be updated directly during runtime, because even if the update is performed under the lock, some competing threads might be reading ->addr and ->svc_port without the lock because they simply cannot afford it. To prevent races with such competing threads, server's addr and port should only be updated using server_set_inetaddr() function or similar. This patch depends on: - "MINOR: server: ensure connection cleanup on server addr changes" - "CLEANUP: server/event_hdl: remove purge_conn hint in INETADDR event" - "MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic" - "MEDIUM: server: make server_set_inetaddr() updater serializable" - "MINOR: server/event_hdl: expose updater info through INETADDR event" - "MINOR: server: add dns hint in server_inetaddr_updater struct" - "MEDIUM: server/dns: clear RMAINT when addr resolves again" While it could be backported in 2.9 with cd994407a ("BUG/MAJOR: server/addr: fix a race during server addr:svc_port updates") to ensure addr and svc_port reset performed by resolver's code comply with the API taking care of pushing the update (and thus avoid any race), some patch dependencies are quite sensitive so it's probably best to avoid backporting for no good reason, or at least wait for it to be considered stable to prevent any breakeages.
2023-12-11 11:31:31 -05:00
}
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
return 0;
}
BUG/MINOR: resolvers: new callback to properly handle SRV record errors When a SRV record was created, it used to register the regular server name resolution callbacks. That said, SRV records and regular server name resolution don't work the same way, furthermore on error management. This patch introduces a new call back to manage DNS errors related to the SRV queries. this fixes github issue #50. Backport status: 2.3, 2.2, 2.1, 2.0
2020-11-19 16:38:33 -05:00
/*
* SRV record error management callback
* returns:
BUG/MINOR: resolvers: answser item list was randomly purged or errors In case of SRV records, The answer item list was purged by the error callback of the first requester which considers the error could not be safely ignored. It makes this item list unavailable for subsequent requesters even if they consider the error could be ignored. On A resolution or do_resolve action error, the answer items were never trashed. This patch re-work the error callbacks and the code to check the return code If a callback return 1, we consider the error was ignored and the answer item list must be kept. At the opposite, If all error callbacks of all requesters of the same resolution returns 0 the list will be purged This patch should be backported as far as 2.0.
2021-06-10 09:25:25 -04:00
* 0 if we can trash answser items.
* 1 when safely ignored and we must kept answer items
BUG/MINOR: resolvers: new callback to properly handle SRV record errors When a SRV record was created, it used to register the regular server name resolution callbacks. That said, SRV records and regular server name resolution don't work the same way, furthermore on error management. This patch introduces a new call back to manage DNS errors related to the SRV queries. this fixes github issue #50. Backport status: 2.3, 2.2, 2.1, 2.0
2020-11-19 16:38:33 -05:00
*
* Grabs the server's lock.
*/
int srvrq_resolution_error_cb(struct resolv_requester *requester, int error_code)
{
struct resolv_srvrq *srvrq;
struct resolv_resolution *res;
struct resolvers *resolvers;
int exp;
/* SRV records */
srvrq = objt_resolv_srvrq(requester->owner);
if (!srvrq)
BUG/MINOR: resolvers: answser item list was randomly purged or errors In case of SRV records, The answer item list was purged by the error callback of the first requester which considers the error could not be safely ignored. It makes this item list unavailable for subsequent requesters even if they consider the error could be ignored. On A resolution or do_resolve action error, the answer items were never trashed. This patch re-work the error callbacks and the code to check the return code If a callback return 1, we consider the error was ignored and the answer item list must be kept. At the opposite, If all error callbacks of all requesters of the same resolution returns 0 the list will be purged This patch should be backported as far as 2.0.
2021-06-10 09:25:25 -04:00
return 0;
BUG/MINOR: resolvers: new callback to properly handle SRV record errors When a SRV record was created, it used to register the regular server name resolution callbacks. That said, SRV records and regular server name resolution don't work the same way, furthermore on error management. This patch introduces a new call back to manage DNS errors related to the SRV queries. this fixes github issue #50. Backport status: 2.3, 2.2, 2.1, 2.0
2020-11-19 16:38:33 -05:00
resolvers = srvrq->resolvers;
res = requester->resolution;
switch (res->status) {
case RSLV_STATUS_NX:
/* stop server if resolution is NX for a long enough period */
exp = tick_add(res->last_valid, resolvers->hold.nx);
if (!tick_is_expired(exp, now_ms))
return 1;
break;
case RSLV_STATUS_TIMEOUT:
/* stop server if resolution is TIMEOUT for a long enough period */
exp = tick_add(res->last_valid, resolvers->hold.timeout);
if (!tick_is_expired(exp, now_ms))
return 1;
break;
case RSLV_STATUS_REFUSED:
/* stop server if resolution is REFUSED for a long enough period */
exp = tick_add(res->last_valid, resolvers->hold.refused);
if (!tick_is_expired(exp, now_ms))
return 1;
break;
default:
/* stop server if resolution failed for a long enough period */
exp = tick_add(res->last_valid, resolvers->hold.other);
if (!tick_is_expired(exp, now_ms))
return 1;
}
MEDIUM: resolvers: add a ref between servers and srv request or used SRV record This patch add a ref into servers to register them onto the record answer item used to set their hostnames. It also adds a head list into 'srvrq' to register servers free to be affected to a SRV record. A head of a tree is also added to srvrq to put servers which present a hotname in server state file. To re-link them fastly to the matching record as soon an item present the same name. This results in better performances on SRV record response parsing. This is an optimization but it could avoid to trigger the haproxy's internal wathdog in some circumstances. And for this reason it should be backported as far we can (2.0 ?)
2021-06-11 04:48:45 -04:00
/* Remove any associated server ref */
MEDIUM: resolvers: remove the last occurrences of the "safe" argument This one was used to indicate whether the callee had to follow particularly safe code path when removing resolutions. Since the code now uses a kill list, this is not needed anymore.
2021-10-20 08:07:31 -04:00
resolv_detach_from_resolution_answer_items(res, requester);
BUG/MINOR: resolvers: new callback to properly handle SRV record errors When a SRV record was created, it used to register the regular server name resolution callbacks. That said, SRV records and regular server name resolution don't work the same way, furthermore on error management. This patch introduces a new call back to manage DNS errors related to the SRV queries. this fixes github issue #50. Backport status: 2.3, 2.2, 2.1, 2.0
2020-11-19 16:38:33 -05:00
BUG/MINOR: resolvers: answser item list was randomly purged or errors In case of SRV records, The answer item list was purged by the error callback of the first requester which considers the error could not be safely ignored. It makes this item list unavailable for subsequent requesters even if they consider the error could be ignored. On A resolution or do_resolve action error, the answer items were never trashed. This patch re-work the error callbacks and the code to check the return code If a callback return 1, we consider the error was ignored and the answer item list must be kept. At the opposite, If all error callbacks of all requesters of the same resolution returns 0 the list will be purged This patch should be backported as far as 2.0.
2021-06-10 09:25:25 -04:00
return 0;
BUG/MINOR: resolvers: new callback to properly handle SRV record errors When a SRV record was created, it used to register the regular server name resolution callbacks. That said, SRV records and regular server name resolution don't work the same way, furthermore on error management. This patch introduces a new call back to manage DNS errors related to the SRV queries. this fixes github issue #50. Backport status: 2.3, 2.2, 2.1, 2.0
2020-11-19 16:38:33 -05:00
}
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
/*
* Server Name Resolution error management callback
* returns:
BUG/MINOR: resolvers: answser item list was randomly purged or errors In case of SRV records, The answer item list was purged by the error callback of the first requester which considers the error could not be safely ignored. It makes this item list unavailable for subsequent requesters even if they consider the error could be ignored. On A resolution or do_resolve action error, the answer items were never trashed. This patch re-work the error callbacks and the code to check the return code If a callback return 1, we consider the error was ignored and the answer item list must be kept. At the opposite, If all error callbacks of all requesters of the same resolution returns 0 the list will be purged This patch should be backported as far as 2.0.
2021-06-10 09:25:25 -04:00
* 0 if we can trash answser items.
* 1 when safely ignored and we must kept answer items
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
*
* Grabs the server's lock.
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
*/
MINOR: resolvers: renames some resolvers specific types to not use dns prefix This patch applies those changes on names: -struct dns_resolution { +struct resolv_resolution { -struct dns_requester { +struct resolv_requester { -struct dns_srvrq { +struct resolv_srvrq { @@ -185,12 +185,12 @@ struct stream { struct { - struct dns_requester *dns_requester; + struct resolv_requester *requester; ... - } dns_ctx; + } resolv_ctx;
2020-12-23 11:41:43 -05:00
int snr_resolution_error_cb(struct resolv_requester *requester, int error_code)
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
{
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
struct server *s;
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
s = objt_server(requester->owner);
MAJOR/REORG: dns: DNS resolution task and requester queues This patch is a major upgrade of the internal run-time DNS resolver in HAProxy and it brings the following 2 main changes: 1. DNS resolution task Up to now, DNS resolution was triggered by the health check task. From now, DNS resolution task is autonomous. It is started by HAProxy right after the scheduler is available and it is woken either when a network IO occurs for one of its nameserver or when a timeout is matched. From now, this means we can enable DNS resolution for a server without enabling health checking. 2. Introduction of a dns_requester structure Up to now, DNS resolution was purposely made for resolving server hostnames. The idea, is to ensure that any HAProxy internal object should be able to trigger a DNS resolution. For this purpose, 2 things has to be done: - clean up the DNS code from the server structure (this was already quite clean actually) and clean up the server's callbacks from manipulating too much DNS resolution - create an agnostic structure which allows linking a DNS resolution and a requester of any type (using obj_type enum) 3. Manage requesters through queues Up to now, there was an uniq relationship between a resolution and it's owner (aka the requester now). It's a shame, because in some cases, multiple objects may share the same hostname and may benefit from a resolution being performed by a third party. This patch introduces the notion of queues, which are basically lists of either currently running resolution or waiting ones. The resolutions are now available as a pool, which belongs to the resolvers. The pool has has a default size of 64 resolutions per resolvers and is allocated at configuration parsing.
2017-05-22 09:17:15 -04:00
if (!s)
BUG/MINOR: resolvers: answser item list was randomly purged or errors In case of SRV records, The answer item list was purged by the error callback of the first requester which considers the error could not be safely ignored. It makes this item list unavailable for subsequent requesters even if they consider the error could be ignored. On A resolution or do_resolve action error, the answer items were never trashed. This patch re-work the error callbacks and the code to check the return code If a callback return 1, we consider the error was ignored and the answer item list must be kept. At the opposite, If all error callbacks of all requesters of the same resolution returns 0 the list will be purged This patch should be backported as far as 2.0.
2021-06-10 09:25:25 -04:00
return 0;
BUILD: threads: Rename SPIN/RWLOCK macros using HA_ prefix This remove any name conflicts, especially on Solaris.
2017-11-07 04:42:54 -05:00
HA_SPIN_LOCK(SERVER_LOCK, &s->lock);
MEDIUM: server: simplify snr_set_srv_down() to prevent confusions snr_set_srv_down() (was formely known as snr_update_srv_status()), is still too ambiguous because it's not clear whether we will be putting the server under maintenance or not. This is mainly due to the fact that the function behaves differently if has_no_ip is set or not. By reviewing the function callers, it has now become clear that snr_resolution_cb() is always calling the function with a valid resolution so we only want to put the server under maintenance if we don't have a valid IP address. On the other hand snr_resolution_error_cb() always calls the function on error, with either no resolution (for SRV requests) or with failing resolution (all cases except RSLV_STATUS_VALID), so in this case we decide whether to put the server under maintenance case by case (ie: expired? timeout?) As a result, let's simplify snr_set_srv_down() so that it is only called when the caller really thinks that the server should be put under maintenance, which means always for snr_resolution_error_cb(), and only if the resolution didn't yield usable ip for snr_resolution_cb().
2023-12-22 08:17:41 -05:00
if (!snr_set_srv_down(s)) {
BUILD: solaris: fix compilation errors Compilation on solaris fails because of usage of names reserved on that platform, i.e. 'queue' and 's_addr'. This patch redefines 'queue' as '_queue' and renames 's_addr' to 'srv_addr' which fixes compilation for now. Future plan: rename 'queue' in code base so define can be removed again. Backporting: 2.9, 2.8
2024-02-23 11:05:01 -05:00
struct server_inetaddr srv_addr;
BUG/MINOR: server/dns: use server_set_inetaddr() to unset srv addr from DNS As seen before, server's addr and svc_port should not be updated directly during runtime, because even if the update is performed under the lock, some competing threads might be reading ->addr and ->svc_port without the lock because they simply cannot afford it. To prevent races with such competing threads, server's addr and port should only be updated using server_set_inetaddr() function or similar. This patch depends on: - "MINOR: server: ensure connection cleanup on server addr changes" - "CLEANUP: server/event_hdl: remove purge_conn hint in INETADDR event" - "MEDIUM: server: merge srv_update_addr() and srv_update_addr_port() logic" - "MEDIUM: server: make server_set_inetaddr() updater serializable" - "MINOR: server/event_hdl: expose updater info through INETADDR event" - "MINOR: server: add dns hint in server_inetaddr_updater struct" - "MEDIUM: server/dns: clear RMAINT when addr resolves again" While it could be backported in 2.9 with cd994407a ("BUG/MAJOR: server/addr: fix a race during server addr:svc_port updates") to ensure addr and svc_port reset performed by resolver's code comply with the API taking care of pushing the update (and thus avoid any race), some patch dependencies are quite sensitive so it's probably best to avoid backporting for no good reason, or at least wait for it to be considered stable to prevent any breakeages.
2023-12-11 11:31:31 -05:00
BUG/MEDIUM: server/dns: preserve server's port upon resolution timeout or error @boi4 reported in GH #2578 that since 3.0-dev1 for servers with address learned from A/AAAA records after a DNS flap server would be put out of maintenance with proper address but with invalid port (== 0), making it unusable and causing tcp checks to fail: [NOTICE] (1) : Loading success. [WARNING] (8) : Server mybackend/myserver1 is going DOWN for maintenance (DNS refused status). 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. [ALERT] (8) : backend 'mybackend' has no server available! [WARNING] (8) : mybackend/myserver1: IP changed from '(none)' to '127.0.0.1' by 'myresolver/ns1'. [WARNING] (8) : Server mybackend/myserver1 ('myhost') is UP/READY (resolves again). [WARNING] (8) : Server mybackend/myserver1 administratively READY thanks to valid DNS answer. [WARNING] (8) : Server mybackend/myserver1 is DOWN, reason: Layer4 connection problem, info: "Connection refused", check duration: 0ms. 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. @boi4 also mentioned that this used to work fine before. Willy suggested that this regression may have been introduced by 64c9c8e ("BUG/MINOR: server/dns: use server_set_inetaddr() to unset srv addr from DNS") Turns out he was right! Indeed, in 64c9c8e we systematically memset the whole server_inetaddr struct (which contains both the requested server's addr and port planned for atomic update) instead of only memsetting the addr part of the structure: except when SRV records are involved (SRV records provide both the address and the port unlike A or AAAA records), we must not reset the server's port upon DNS errors because the port may have been provided at config time and we don't want to lose its value. Big thanks to @boi4 for his well-documented issue that really helped us to pinpoint the bug right on time for the dev-13 release. No backport needed (unless 64c9c8e gets backported).
2024-05-24 07:55:41 -04:00
/* unset server's addr, keep port */
server_get_inetaddr(s, &srv_addr);
BUG/MEDIUM: server/dns: prevent DOWN/UP flap upon resolution timeout or error This is a complementary patch to c16eba818 ("BUG/MEDIUM: server/dns: preserve server's port upon resolution timeout or error"). Indeed, since c16eba818, the port is properly preserved, but unsetting server's address this way results in server_atomic_sync() function thinking that we're actually setting a new address and not unsetting the previous one because addr family is != AF_UNSPEC. Upon DNS timeout, this could be observed: [WARNING] (2588257) : Server http/s1 is going DOWN for maintenance (DNS timeout status). 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. [WARNING] (2588257) : Server http/s1 ('test1.localhost') is UP/READY (resolves again). Notice that server timeouts and then immediately resolves again. Of course in this case case the server's address was properly set to 0, meaning that the server will not receive any traffic, but it is confusing and could result in haproxy temporarily thinking that the server is actually available while it's not. To properly fix the issue and restore historical behavior, let's explicitly set inetaddr's family to AF_UNSPEC after fetching original server's address. It should be backported in 3.0 with c16eba818.
2024-06-28 03:41:56 -04:00
srv_addr.family = AF_UNSPEC;
BUG/MEDIUM: server/dns: preserve server's port upon resolution timeout or error @boi4 reported in GH #2578 that since 3.0-dev1 for servers with address learned from A/AAAA records after a DNS flap server would be put out of maintenance with proper address but with invalid port (== 0), making it unusable and causing tcp checks to fail: [NOTICE] (1) : Loading success. [WARNING] (8) : Server mybackend/myserver1 is going DOWN for maintenance (DNS refused status). 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. [ALERT] (8) : backend 'mybackend' has no server available! [WARNING] (8) : mybackend/myserver1: IP changed from '(none)' to '127.0.0.1' by 'myresolver/ns1'. [WARNING] (8) : Server mybackend/myserver1 ('myhost') is UP/READY (resolves again). [WARNING] (8) : Server mybackend/myserver1 administratively READY thanks to valid DNS answer. [WARNING] (8) : Server mybackend/myserver1 is DOWN, reason: Layer4 connection problem, info: "Connection refused", check duration: 0ms. 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. @boi4 also mentioned that this used to work fine before. Willy suggested that this regression may have been introduced by 64c9c8e ("BUG/MINOR: server/dns: use server_set_inetaddr() to unset srv addr from DNS") Turns out he was right! Indeed, in 64c9c8e we systematically memset the whole server_inetaddr struct (which contains both the requested server's addr and port planned for atomic update) instead of only memsetting the addr part of the structure: except when SRV records are involved (SRV records provide both the address and the port unlike A or AAAA records), we must not reset the server's port upon DNS errors because the port may have been provided at config time and we don't want to lose its value. Big thanks to @boi4 for his well-documented issue that really helped us to pinpoint the bug right on time for the dev-13 release. No backport needed (unless 64c9c8e gets backported).
2024-05-24 07:55:41 -04:00
memset(&srv_addr.addr, 0, sizeof(srv_addr.addr));
BUILD: solaris: fix compilation errors Compilation on solaris fails because of usage of names reserved on that platform, i.e. 'queue' and 's_addr'. This patch redefines 'queue' as '_queue' and renames 's_addr' to 'srv_addr' which fixes compilation for now. Future plan: rename 'queue' in code base so define can be removed again. Backporting: 2.9, 2.8
2024-02-23 11:05:01 -05:00
server_set_inetaddr(s, &srv_addr, SERVER_INETADDR_UPDATER_NONE, NULL);
BUG/MINOR: resolvers: answser item list was randomly purged or errors In case of SRV records, The answer item list was purged by the error callback of the first requester which considers the error could not be safely ignored. It makes this item list unavailable for subsequent requesters even if they consider the error could be ignored. On A resolution or do_resolve action error, the answer items were never trashed. This patch re-work the error callbacks and the code to check the return code If a callback return 1, we consider the error was ignored and the answer item list must be kept. At the opposite, If all error callbacks of all requesters of the same resolution returns 0 the list will be purged This patch should be backported as far as 2.0.
2021-06-10 09:25:25 -04:00
HA_SPIN_UNLOCK(SERVER_LOCK, &s->lock);
MEDIUM: resolvers: remove the last occurrences of the "safe" argument This one was used to indicate whether the callee had to follow particularly safe code path when removing resolutions. Since the code now uses a kill list, this is not needed anymore.
2021-10-20 08:07:31 -04:00
resolv_detach_from_resolution_answer_items(requester->resolution, requester);
BUG/MINOR: resolvers: answser item list was randomly purged or errors In case of SRV records, The answer item list was purged by the error callback of the first requester which considers the error could not be safely ignored. It makes this item list unavailable for subsequent requesters even if they consider the error could be ignored. On A resolution or do_resolve action error, the answer items were never trashed. This patch re-work the error callbacks and the code to check the return code If a callback return 1, we consider the error was ignored and the answer item list must be kept. At the opposite, If all error callbacks of all requesters of the same resolution returns 0 the list will be purged This patch should be backported as far as 2.0.
2021-06-10 09:25:25 -04:00
return 0;
}
BUILD: threads: Rename SPIN/RWLOCK macros using HA_ prefix This remove any name conflicts, especially on Solaris.
2017-11-07 04:42:54 -05:00
HA_SPIN_UNLOCK(SERVER_LOCK, &s->lock);
BUG/MINOR: resolvers: answser item list was randomly purged or errors In case of SRV records, The answer item list was purged by the error callback of the first requester which considers the error could not be safely ignored. It makes this item list unavailable for subsequent requesters even if they consider the error could be ignored. On A resolution or do_resolve action error, the answer items were never trashed. This patch re-work the error callbacks and the code to check the return code If a callback return 1, we consider the error was ignored and the answer item list must be kept. At the opposite, If all error callbacks of all requesters of the same resolution returns 0 the list will be purged This patch should be backported as far as 2.0.
2021-06-10 09:25:25 -04:00
MAJOR: server: add DNS-based server name resolution Relies on the DNS protocol freshly implemented in HAProxy. It performs a server IP addr resolution based on a server hostname.
2015-04-13 19:15:08 -04:00
return 1;
}
MINOR: dns: new snr_check_ip_callback function In the process of breaking links between dns_* functions and other structures (mainly server and a bit of resolution), the function dns_get_ip_from_response needs to be reworked: it now can call "callback" functions based on resolution's owner type to allow modifying the way the response is processed. For now, main purpose of the callback function is to check that an IP address is not already affected to an element of the same type. For now, only server type has a callback.
2017-05-03 09:43:12 -04:00
/*
* Function to check if <ip> is already affected to a server in the backend
MINOR: dns: Cache previous DNS answers. As DNS servers may not return all IPs in one answer, we want to cache the previous entries. Those entries are removed when considered obsolete, which happens when the IP hasn't been returned by the DNS server for a time defined in the "hold obsolete" parameter of the resolver section. The default is 30s.
2017-07-06 12:46:47 -04:00
* which owns <srv> and is up.
MINOR: dns: new snr_check_ip_callback function In the process of breaking links between dns_* functions and other structures (mainly server and a bit of resolution), the function dns_get_ip_from_response needs to be reworked: it now can call "callback" functions based on resolution's owner type to allow modifying the way the response is processed. For now, main purpose of the callback function is to check that an IP address is not already affected to an element of the same type. For now, only server type has a callback.
2017-05-03 09:43:12 -04:00
* It returns a pointer to the first server found or NULL if <ip> is not yet
* assigned.
BUG/MINOR: dns: Don't lock the server lock in snr_check_ip_callback(). snr_check_ip_callback() may be called with the server lock, so don't attempt to lock it again, instead, make sure the callers always have the lock before calling it.
2017-11-06 11:30:28 -05:00
*
* Must be called with server lock held
MINOR: dns: new snr_check_ip_callback function In the process of breaking links between dns_* functions and other structures (mainly server and a bit of resolution), the function dns_get_ip_from_response needs to be reworked: it now can call "callback" functions based on resolution's owner type to allow modifying the way the response is processed. For now, main purpose of the callback function is to check that an IP address is not already affected to an element of the same type. For now, only server type has a callback.
2017-05-03 09:43:12 -04:00
*/
struct server *snr_check_ip_callback(struct server *srv, void *ip, unsigned char *ip_family)
{
struct server *tmpsrv;
struct proxy *be;
if (!srv)
return NULL;
be = srv->proxy;
for (tmpsrv = be->srv; tmpsrv; tmpsrv = tmpsrv->next) {
BUG/MINOR: dns: fix missing lock protection on server. To avoid inconsistencies server's attributes must be read or updated under lock.
2017-11-02 12:20:39 -04:00
/* we found the current server is the same, ignore it */
if (srv == tmpsrv)
continue;
MINOR: dns: new snr_check_ip_callback function In the process of breaking links between dns_* functions and other structures (mainly server and a bit of resolution), the function dns_get_ip_from_response needs to be reworked: it now can call "callback" functions based on resolution's owner type to allow modifying the way the response is processed. For now, main purpose of the callback function is to check that an IP address is not already affected to an element of the same type. For now, only server type has a callback.
2017-05-03 09:43:12 -04:00
/* We want to compare the IP in the record with the IP of the servers in the
* same backend, only if:
* * DNS resolution is enabled on the server
* * the hostname used for the resolution by our server is the same than the
* one used for the server found in the backend
* * the server found in the backend is not our current server
*/
BUILD: threads: Rename SPIN/RWLOCK macros using HA_ prefix This remove any name conflicts, especially on Solaris.
2017-11-07 04:42:54 -05:00
HA_SPIN_LOCK(SERVER_LOCK, &tmpsrv->lock);
MAJOR/REORG: dns: DNS resolution task and requester queues This patch is a major upgrade of the internal run-time DNS resolver in HAProxy and it brings the following 2 main changes: 1. DNS resolution task Up to now, DNS resolution was triggered by the health check task. From now, DNS resolution task is autonomous. It is started by HAProxy right after the scheduler is available and it is woken either when a network IO occurs for one of its nameserver or when a timeout is matched. From now, this means we can enable DNS resolution for a server without enabling health checking. 2. Introduction of a dns_requester structure Up to now, DNS resolution was purposely made for resolving server hostnames. The idea, is to ensure that any HAProxy internal object should be able to trigger a DNS resolution. For this purpose, 2 things has to be done: - clean up the DNS code from the server structure (this was already quite clean actually) and clean up the server's callbacks from manipulating too much DNS resolution - create an agnostic structure which allows linking a DNS resolution and a requester of any type (using obj_type enum) 3. Manage requesters through queues Up to now, there was an uniq relationship between a resolution and it's owner (aka the requester now). It's a shame, because in some cases, multiple objects may share the same hostname and may benefit from a resolution being performed by a third party. This patch introduces the notion of queues, which are basically lists of either currently running resolution or waiting ones. The resolutions are now available as a pool, which belongs to the resolvers. The pool has has a default size of 64 resolutions per resolvers and is allocated at configuration parsing.
2017-05-22 09:17:15 -04:00
if ((tmpsrv->hostname_dn == NULL) ||
(srv->hostname_dn_len != tmpsrv->hostname_dn_len) ||
BUG/MINOR: resolvers: don't lower the case of binary DNS format The server's "hostname_dn" is in Domain Name format, not a pure string, as converted by resolv_str_to_dn_label(). It is made of lower-case string components delimited by binary lengths, e.g. <0x03>www<0x07>haproxy<0x03)org. As such it must not be lowercased again in srv_state_srv_update(), because 1) it's useless on the name components since already done, and 2) because it would replace component lengths 97 and above by 32-char shorter ones. Granted, not many domain names have that large components so the risk is very low but the operation is always wrong anyway. This was brought in 2.5 by commit 3406766d57 ("MEDIUM: resolvers: add a ref between servers and srv request or used SRV record"). In the same vein, let's fix the confusing strcasecmp() that are applied to this binary format, and use memcmp() instead. Here there's basically no risk to incorrectly match the wrong record, but that test alone is confusing enough to provoke the existence of the bug above. Finally let's update the component for that field to mention that it's in this format and already lower cased. Better not backport this, the risk of facing this bug is almost zero, and every time we touch such files something breaks for bad reasons.
2025-07-07 10:33:02 -04:00
(memcmp(srv->hostname_dn, tmpsrv->hostname_dn, srv->hostname_dn_len) != 0) ||
BUG/MINOR: dns: fix missing lock protection on server. To avoid inconsistencies server's attributes must be read or updated under lock.
2017-11-02 12:20:39 -04:00
(srv->puid == tmpsrv->puid)) {
BUILD: threads: Rename SPIN/RWLOCK macros using HA_ prefix This remove any name conflicts, especially on Solaris.
2017-11-07 04:42:54 -05:00
HA_SPIN_UNLOCK(SERVER_LOCK, &tmpsrv->lock);
MINOR: dns: new snr_check_ip_callback function In the process of breaking links between dns_* functions and other structures (mainly server and a bit of resolution), the function dns_get_ip_from_response needs to be reworked: it now can call "callback" functions based on resolution's owner type to allow modifying the way the response is processed. For now, main purpose of the callback function is to check that an IP address is not already affected to an element of the same type. For now, only server type has a callback.
2017-05-03 09:43:12 -04:00
continue;
BUG/MINOR: dns: fix missing lock protection on server. To avoid inconsistencies server's attributes must be read or updated under lock.
2017-11-02 12:20:39 -04:00
}
MINOR: dns: new snr_check_ip_callback function In the process of breaking links between dns_* functions and other structures (mainly server and a bit of resolution), the function dns_get_ip_from_response needs to be reworked: it now can call "callback" functions based on resolution's owner type to allow modifying the way the response is processed. For now, main purpose of the callback function is to check that an IP address is not already affected to an element of the same type. For now, only server type has a callback.
2017-05-03 09:43:12 -04:00
MINOR: dns: Cache previous DNS answers. As DNS servers may not return all IPs in one answer, we want to cache the previous entries. Those entries are removed when considered obsolete, which happens when the IP hasn't been returned by the DNS server for a time defined in the "hold obsolete" parameter of the resolver section. The default is 30s.
2017-07-06 12:46:47 -04:00
/* If the server has been taken down, don't consider it */
BUG/MINOR: dns: fix missing lock protection on server. To avoid inconsistencies server's attributes must be read or updated under lock.
2017-11-02 12:20:39 -04:00
if (tmpsrv->next_admin & SRV_ADMF_RMAINT) {
BUILD: threads: Rename SPIN/RWLOCK macros using HA_ prefix This remove any name conflicts, especially on Solaris.
2017-11-07 04:42:54 -05:00
HA_SPIN_UNLOCK(SERVER_LOCK, &tmpsrv->lock);
MINOR: dns: Cache previous DNS answers. As DNS servers may not return all IPs in one answer, we want to cache the previous entries. Those entries are removed when considered obsolete, which happens when the IP hasn't been returned by the DNS server for a time defined in the "hold obsolete" parameter of the resolver section. The default is 30s.
2017-07-06 12:46:47 -04:00
continue;
BUG/MINOR: dns: fix missing lock protection on server. To avoid inconsistencies server's attributes must be read or updated under lock.
2017-11-02 12:20:39 -04:00
}
MINOR: dns: Cache previous DNS answers. As DNS servers may not return all IPs in one answer, we want to cache the previous entries. Those entries are removed when considered obsolete, which happens when the IP hasn't been returned by the DNS server for a time defined in the "hold obsolete" parameter of the resolver section. The default is 30s.
2017-07-06 12:46:47 -04:00
MINOR: dns: new snr_check_ip_callback function In the process of breaking links between dns_* functions and other structures (mainly server and a bit of resolution), the function dns_get_ip_from_response needs to be reworked: it now can call "callback" functions based on resolution's owner type to allow modifying the way the response is processed. For now, main purpose of the callback function is to check that an IP address is not already affected to an element of the same type. For now, only server type has a callback.
2017-05-03 09:43:12 -04:00
/* At this point, we have 2 different servers using the same DNS hostname
* for their respective resolution.
*/
if (*ip_family == tmpsrv->addr.ss_family &&
((tmpsrv->addr.ss_family == AF_INET &&
memcmp(ip, &((struct sockaddr_in *)&tmpsrv->addr)->sin_addr, 4) == 0) ||
(tmpsrv->addr.ss_family == AF_INET6 &&
memcmp(ip, &((struct sockaddr_in6 *)&tmpsrv->addr)->sin6_addr, 16) == 0))) {
BUILD: threads: Rename SPIN/RWLOCK macros using HA_ prefix This remove any name conflicts, especially on Solaris.
2017-11-07 04:42:54 -05:00
HA_SPIN_UNLOCK(SERVER_LOCK, &tmpsrv->lock);
MINOR: dns: new snr_check_ip_callback function In the process of breaking links between dns_* functions and other structures (mainly server and a bit of resolution), the function dns_get_ip_from_response needs to be reworked: it now can call "callback" functions based on resolution's owner type to allow modifying the way the response is processed. For now, main purpose of the callback function is to check that an IP address is not already affected to an element of the same type. For now, only server type has a callback.
2017-05-03 09:43:12 -04:00
return tmpsrv;
}
BUILD: threads: Rename SPIN/RWLOCK macros using HA_ prefix This remove any name conflicts, especially on Solaris.
2017-11-07 04:42:54 -05:00
HA_SPIN_UNLOCK(SERVER_LOCK, &tmpsrv->lock);
MINOR: dns: new snr_check_ip_callback function In the process of breaking links between dns_* functions and other structures (mainly server and a bit of resolution), the function dns_get_ip_from_response needs to be reworked: it now can call "callback" functions based on resolution's owner type to allow modifying the way the response is processed. For now, main purpose of the callback function is to check that an IP address is not already affected to an element of the same type. For now, only server type has a callback.
2017-05-03 09:43:12 -04:00
}
BUG/MINOR: dns: fix missing lock protection on server. To avoid inconsistencies server's attributes must be read or updated under lock.
2017-11-02 12:20:39 -04:00
MINOR: dns: new snr_check_ip_callback function In the process of breaking links between dns_* functions and other structures (mainly server and a bit of resolution), the function dns_get_ip_from_response needs to be reworked: it now can call "callback" functions based on resolution's owner type to allow modifying the way the response is processed. For now, main purpose of the callback function is to check that an IP address is not already affected to an element of the same type. For now, only server type has a callback.
2017-05-03 09:43:12 -04:00
return NULL;
}
MAJOR: server: postpone address resolution Server addresses are not resolved anymore upon the first pass so that we don't fail if an address cannot be resolved by the libc. Instead they are processed all at once after the configuration is fully loaded, by the new function srv_init_addr(). This function only acts on the server's address if this address uses an FQDN, which appears in server->hostname. For now the function does two things, to followup with HAProxy's historical default behavior: 1. apply server IP address found in server-state file if runtime DNS resolution is enabled for this server 2. use the DNS resolver provided by the libc If none of the 2 options above can find an IP address, then an error is returned. All of this will be needed to support the new server parameter "init-addr". For now, the biggest user-visible change is that all server resolution errors are dumped at once instead of causing a startup failure one by one.
2016-11-02 10:34:05 -04:00
/* Sets the server's address (srv->addr) from srv->hostname using the libc's
* resolver. This is suited for initial address configuration. Returns 0 on
* success otherwise a non-zero error code. In case of error, *err_code, if
* not NULL, is filled up.
*/
int srv_set_addr_via_libc(struct server *srv, int *err_code)
{
MINOR: server/ip: centralize server ip updates Add a new helper function named _srv_update_inetaddr() to centralize ip addr and port updates during runtime.
2023-11-13 10:42:56 -05:00
struct sockaddr_storage new_addr;
memset(&new_addr, 0, sizeof(new_addr));
BUG/MINOR: server: Use the configured address family for the initial resolution A regression was introduced by the commit c886fb58eb ("MINOR: server/ip: centralize server ip updates"). The configured address family is lost when the server address is initialized during the startup, for the resolution based on the libc or based on the server state-file. Thus, "ipv4@" and "ipv6@" prefixed are ignored. To fix the bug, we take care to use the configured address family before calling str2ip2() in srv_apply_lastaddr() and srv_apply_via_libc() functions. This patch should fix the issue #2393. It must be backported to 2.9.
2023-12-20 06:21:57 -05:00
/* Use the preferred family, if configured */
new_addr.ss_family = srv->addr.ss_family;
MINOR: server/ip: centralize server ip updates Add a new helper function named _srv_update_inetaddr() to centralize ip addr and port updates during runtime.
2023-11-13 10:42:56 -05:00
if (str2ip2(srv->hostname, &new_addr, 1) == NULL) {
MAJOR: server: postpone address resolution Server addresses are not resolved anymore upon the first pass so that we don't fail if an address cannot be resolved by the libc. Instead they are processed all at once after the configuration is fully loaded, by the new function srv_init_addr(). This function only acts on the server's address if this address uses an FQDN, which appears in server->hostname. For now the function does two things, to followup with HAProxy's historical default behavior: 1. apply server IP address found in server-state file if runtime DNS resolution is enabled for this server 2. use the DNS resolver provided by the libc If none of the 2 options above can find an IP address, then an error is returned. All of this will be needed to support the new server parameter "init-addr". For now, the biggest user-visible change is that all server resolution errors are dumped at once instead of causing a startup failure one by one.
2016-11-02 10:34:05 -04:00
if (err_code)
MEDIUM: server: make libc resolution failure non-fatal Now that we have "init-addr none", it becomes possible to recover on libc resolver's failures. Thus it's preferable not to alert nor fail at the moment the libc is called, and instead process the failure at the end of the list. This allows "none" to be set after libc to provide a smooth fallback in case of resolver issues.
2016-11-07 13:19:22 -05:00
*err_code |= ERR_WARN;
MAJOR: server: postpone address resolution Server addresses are not resolved anymore upon the first pass so that we don't fail if an address cannot be resolved by the libc. Instead they are processed all at once after the configuration is fully loaded, by the new function srv_init_addr(). This function only acts on the server's address if this address uses an FQDN, which appears in server->hostname. For now the function does two things, to followup with HAProxy's historical default behavior: 1. apply server IP address found in server-state file if runtime DNS resolution is enabled for this server 2. use the DNS resolver provided by the libc If none of the 2 options above can find an IP address, then an error is returned. All of this will be needed to support the new server parameter "init-addr". For now, the biggest user-visible change is that all server resolution errors are dumped at once instead of causing a startup failure one by one.
2016-11-02 10:34:05 -04:00
return 1;
}
BUG/MINOR: server/event_hdl: propagate map port info through inetaddr event server addr:svc_port updates during runtime might set or clear the SRV_F_MAPPORTS flag. Unfortunately, the flag update is still directly performed by srv_update_addr_port() function while the addr:svc_port update is being scheduled for atomic update. Given that existing readers don't take server's lock to read addr:svc_port, they also check the SRV_F_MAPPORTS flag right after without the lock. So we could cause the readers to incorrectly interpret the svc_port from the server struct because the mapport information is not published atomically, resulting in inconsistencies between svc_port / mapport flag. (MAPPORTS flag causes svc_port to be used differently by the reader) To fix this, we publish the mapport information within the INETADDR server event and we let the task responsible for updating server's addr and port position or clear the flag depending on the mapport hint. This patch depends on: - MINOR: server/event_hdl: add server_inetaddr struct to facilitate event data usage - MINOR: server/event_hdl: update _srv_event_hdl_prepare_inetaddr prototype This should be backported in 2.9 with 683b2ae01 ("MINOR: server/event_hdl: add SERVER_INETADDR event")
2023-12-07 11:08:08 -05:00
_srv_set_inetaddr(srv, &new_addr);
MAJOR: server: postpone address resolution Server addresses are not resolved anymore upon the first pass so that we don't fail if an address cannot be resolved by the libc. Instead they are processed all at once after the configuration is fully loaded, by the new function srv_init_addr(). This function only acts on the server's address if this address uses an FQDN, which appears in server->hostname. For now the function does two things, to followup with HAProxy's historical default behavior: 1. apply server IP address found in server-state file if runtime DNS resolution is enabled for this server 2. use the DNS resolver provided by the libc If none of the 2 options above can find an IP address, then an error is returned. All of this will be needed to support the new server parameter "init-addr". For now, the biggest user-visible change is that all server resolution errors are dumped at once instead of causing a startup failure one by one.
2016-11-02 10:34:05 -04:00
return 0;
}
MINOR: server: cli: Add server FQDNs to server-state file and stats socket. This patch adds a new stats socket command to modify server FQDNs at run time. Its syntax: set server <backend>/<server> fqdn <FQDN> This patch also adds FQDNs to server state file at the end of each line for backward compatibility ("-" if not present).
2017-04-26 05:24:02 -04:00
/* Set the server's FDQN (->hostname) from <hostname>.
* Returns -1 if failed, 0 if not.
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
*
* Must be called with the server lock held.
MINOR: server: cli: Add server FQDNs to server-state file and stats socket. This patch adds a new stats socket command to modify server FQDNs at run time. Its syntax: set server <backend>/<server> fqdn <FQDN> This patch also adds FQDNs to server state file at the end of each line for backward compatibility ("-" if not present).
2017-04-26 05:24:02 -04:00
*/
MINOR: resolvers: renames some resolvers specific types to not use dns prefix This patch applies those changes on names: -struct dns_resolution { +struct resolv_resolution { -struct dns_requester { +struct resolv_requester { -struct dns_srvrq { +struct resolv_srvrq { @@ -185,12 +185,12 @@ struct stream { struct { - struct dns_requester *dns_requester; + struct resolv_requester *requester; ... - } dns_ctx; + } resolv_ctx;
2020-12-23 11:41:43 -05:00
int srv_set_fqdn(struct server *srv, const char *hostname, int resolv_locked)
MINOR: server: cli: Add server FQDNs to server-state file and stats socket. This patch adds a new stats socket command to modify server FQDNs at run time. Its syntax: set server <backend>/<server> fqdn <FQDN> This patch also adds FQDNs to server state file at the end of each line for backward compatibility ("-" if not present).
2017-04-26 05:24:02 -04:00
{
MINOR: resolvers: renames some resolvers specific types to not use dns prefix This patch applies those changes on names: -struct dns_resolution { +struct resolv_resolution { -struct dns_requester { +struct resolv_requester { -struct dns_srvrq { +struct resolv_srvrq { @@ -185,12 +185,12 @@ struct stream { struct { - struct dns_requester *dns_requester; + struct resolv_requester *requester; ... - } dns_ctx; + } resolv_ctx;
2020-12-23 11:41:43 -05:00
struct resolv_resolution *resolution;
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
char *hostname_dn;
int hostname_len, hostname_dn_len;
MINOR: server: cli: Add server FQDNs to server-state file and stats socket. This patch adds a new stats socket command to modify server FQDNs at run time. Its syntax: set server <backend>/<server> fqdn <FQDN> This patch also adds FQDNs to server state file at the end of each line for backward compatibility ("-" if not present).
2017-04-26 05:24:02 -04:00
BUG/MINOR: server: Crash when setting FQDN via CLI. This patch ensures that a DNS resolution may be launched before setting a server FQDN via the CLI. Especially, it checks that resolvers was set. A LEVEL 4 reg testing file is provided. Thanks to Lukas Tribus for having reported this issue. Must be backported to 1.8.
2018-08-21 09:04:23 -04:00
/* Note that the server lock is already held. */
if (!srv->resolvers)
return -1;
MINOR: resolvers: renames some resolvers specific types to not use dns prefix This patch applies those changes on names: -struct dns_resolution { +struct resolv_resolution { -struct dns_requester { +struct resolv_requester { -struct dns_srvrq { +struct resolv_srvrq { @@ -185,12 +185,12 @@ struct stream { struct { - struct dns_requester *dns_requester; + struct resolv_requester *requester; ... - } dns_ctx; + } resolv_ctx;
2020-12-23 11:41:43 -05:00
if (!resolv_locked)
BUILD: threads: Rename SPIN/RWLOCK macros using HA_ prefix This remove any name conflicts, especially on Solaris.
2017-11-07 04:42:54 -05:00
HA_SPIN_LOCK(DNS_LOCK, &srv->resolvers->lock);
BUG/MEDIUM: resolvers: Skip DNS resolution at startup if SRV resolution is set At startup, if a SRV resolution is set for a server, no DNS resolution is created. We must wait the first SRV resolution to know if it must be triggered. It is important to do so for two reasons. First, during a "classical" startup, a server based on a SRV resolution has no hostname. Thus the created DNS resolution is useless. Best waiting the first SRV resolution. It is not really a bug at this stage, it is just useless. Second, in the same situation, if the server state is loaded from a file, its hosname will be set a bit later. Thus, if there is no additionnal record for this server, because there is already a DNS resolution, it inhibits any new DNS resolution. But there is no hostname attached to the existing DNS resolution. So no resolution is performed at all for this server. To avoid any problem, it is fairly easier to handle this special case during startup. But this means we must be prepared to have no "resolv_requester" field for a server at runtime. This patch must be backported as far as 2.2.
2021-03-12 04:23:05 -05:00
/* run time DNS/SRV resolution was not active for this server
MAJOR/REORG: dns: DNS resolution task and requester queues This patch is a major upgrade of the internal run-time DNS resolver in HAProxy and it brings the following 2 main changes: 1. DNS resolution task Up to now, DNS resolution was triggered by the health check task. From now, DNS resolution task is autonomous. It is started by HAProxy right after the scheduler is available and it is woken either when a network IO occurs for one of its nameserver or when a timeout is matched. From now, this means we can enable DNS resolution for a server without enabling health checking. 2. Introduction of a dns_requester structure Up to now, DNS resolution was purposely made for resolving server hostnames. The idea, is to ensure that any HAProxy internal object should be able to trigger a DNS resolution. For this purpose, 2 things has to be done: - clean up the DNS code from the server structure (this was already quite clean actually) and clean up the server's callbacks from manipulating too much DNS resolution - create an agnostic structure which allows linking a DNS resolution and a requester of any type (using obj_type enum) 3. Manage requesters through queues Up to now, there was an uniq relationship between a resolution and it's owner (aka the requester now). It's a shame, because in some cases, multiple objects may share the same hostname and may benefit from a resolution being performed by a third party. This patch introduces the notion of queues, which are basically lists of either currently running resolution or waiting ones. The resolutions are now available as a pool, which belongs to the resolvers. The pool has has a default size of 64 resolutions per resolvers and is allocated at configuration parsing.
2017-05-22 09:17:15 -04:00
* and we can't enable it at run time for now.
*/
BUG/MEDIUM: resolvers: Skip DNS resolution at startup if SRV resolution is set At startup, if a SRV resolution is set for a server, no DNS resolution is created. We must wait the first SRV resolution to know if it must be triggered. It is important to do so for two reasons. First, during a "classical" startup, a server based on a SRV resolution has no hostname. Thus the created DNS resolution is useless. Best waiting the first SRV resolution. It is not really a bug at this stage, it is just useless. Second, in the same situation, if the server state is loaded from a file, its hosname will be set a bit later. Thus, if there is no additionnal record for this server, because there is already a DNS resolution, it inhibits any new DNS resolution. But there is no hostname attached to the existing DNS resolution. So no resolution is performed at all for this server. To avoid any problem, it is fairly easier to handle this special case during startup. But this means we must be prepared to have no "resolv_requester" field for a server at runtime. This patch must be backported as far as 2.2.
2021-03-12 04:23:05 -05:00
if (!srv->resolv_requester && !srv->srvrq)
MEDIUM: thread/dns: Make DNS thread-safe
2017-10-04 10:17:58 -04:00
goto err;
MAJOR/REORG: dns: DNS resolution task and requester queues This patch is a major upgrade of the internal run-time DNS resolver in HAProxy and it brings the following 2 main changes: 1. DNS resolution task Up to now, DNS resolution was triggered by the health check task. From now, DNS resolution task is autonomous. It is started by HAProxy right after the scheduler is available and it is woken either when a network IO occurs for one of its nameserver or when a timeout is matched. From now, this means we can enable DNS resolution for a server without enabling health checking. 2. Introduction of a dns_requester structure Up to now, DNS resolution was purposely made for resolving server hostnames. The idea, is to ensure that any HAProxy internal object should be able to trigger a DNS resolution. For this purpose, 2 things has to be done: - clean up the DNS code from the server structure (this was already quite clean actually) and clean up the server's callbacks from manipulating too much DNS resolution - create an agnostic structure which allows linking a DNS resolution and a requester of any type (using obj_type enum) 3. Manage requesters through queues Up to now, there was an uniq relationship between a resolution and it's owner (aka the requester now). It's a shame, because in some cases, multiple objects may share the same hostname and may benefit from a resolution being performed by a third party. This patch introduces the notion of queues, which are basically lists of either currently running resolution or waiting ones. The resolutions are now available as a pool, which belongs to the resolvers. The pool has has a default size of 64 resolutions per resolvers and is allocated at configuration parsing.
2017-05-22 09:17:15 -04:00
chunk_reset(&trash);
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
hostname_len = strlen(hostname);
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
hostname_dn = trash.area;
MINOR: resolvers: fix the resolv_str_to_dn_label() API about trailing zero This function is bogus at the API level: it demands that the input string is zero-terminated *and* that its length *including* the trailing zero is passed on input. While that already looks smelly, the trailing zero is copied as-is, and is then explicitly replaced with a zero... Not only all callers have to pass hostname_len+1 everywhere to work around this absurdity, but this requirement causes a bug in the do-resolve() action that passes random string lengths on input, and that will be fixed on a subsequent patch. Let's fix this API issue for now. This patch will have to be backported, and in versions 2.3 and older, the function is in dns.c and is called dns_str_to_dn_label().
2021-10-14 01:49:49 -04:00
hostname_dn_len = resolv_str_to_dn_label(hostname, hostname_len,
MINOR: resolvers: rework prototype suffixes to split resolving and dns. A lot of prototypes in dns.h are specific to resolvers and must be renamed to split resolving and DNS layers.
2020-12-23 12:49:16 -05:00
hostname_dn, trash.size);
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
if (hostname_dn_len == -1)
MEDIUM: thread/dns: Make DNS thread-safe
2017-10-04 10:17:58 -04:00
goto err;
MAJOR/REORG: dns: DNS resolution task and requester queues This patch is a major upgrade of the internal run-time DNS resolver in HAProxy and it brings the following 2 main changes: 1. DNS resolution task Up to now, DNS resolution was triggered by the health check task. From now, DNS resolution task is autonomous. It is started by HAProxy right after the scheduler is available and it is woken either when a network IO occurs for one of its nameserver or when a timeout is matched. From now, this means we can enable DNS resolution for a server without enabling health checking. 2. Introduction of a dns_requester structure Up to now, DNS resolution was purposely made for resolving server hostnames. The idea, is to ensure that any HAProxy internal object should be able to trigger a DNS resolution. For this purpose, 2 things has to be done: - clean up the DNS code from the server structure (this was already quite clean actually) and clean up the server's callbacks from manipulating too much DNS resolution - create an agnostic structure which allows linking a DNS resolution and a requester of any type (using obj_type enum) 3. Manage requesters through queues Up to now, there was an uniq relationship between a resolution and it's owner (aka the requester now). It's a shame, because in some cases, multiple objects may share the same hostname and may benefit from a resolution being performed by a third party. This patch introduces the notion of queues, which are basically lists of either currently running resolution or waiting ones. The resolutions are now available as a pool, which belongs to the resolvers. The pool has has a default size of 64 resolutions per resolvers and is allocated at configuration parsing.
2017-05-22 09:17:15 -04:00
BUG/MEDIUM: resolvers: Skip DNS resolution at startup if SRV resolution is set At startup, if a SRV resolution is set for a server, no DNS resolution is created. We must wait the first SRV resolution to know if it must be triggered. It is important to do so for two reasons. First, during a "classical" startup, a server based on a SRV resolution has no hostname. Thus the created DNS resolution is useless. Best waiting the first SRV resolution. It is not really a bug at this stage, it is just useless. Second, in the same situation, if the server state is loaded from a file, its hosname will be set a bit later. Thus, if there is no additionnal record for this server, because there is already a DNS resolution, it inhibits any new DNS resolution. But there is no hostname attached to the existing DNS resolution. So no resolution is performed at all for this server. To avoid any problem, it is fairly easier to handle this special case during startup. But this means we must be prepared to have no "resolv_requester" field for a server at runtime. This patch must be backported as far as 2.2.
2021-03-12 04:23:05 -05:00
resolution = (srv->resolv_requester ? srv->resolv_requester->resolution : NULL);
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
if (resolution &&
resolution->hostname_dn &&
BUG/MINOR: resolvers: Add missing case-insensitive comparisons of DNS hostnames DNS hostname comparisons were fixed to be case-insensitive (see b17b88487 "BUG/MEDIUM: dns: Consider the fact that dns answers are case-insensitive"). However 2 comparisons are still case-sensitive. This patch must be backported as far as 1.8.
2021-03-16 06:21:04 -04:00
resolution->hostname_dn_len == hostname_dn_len &&
BUG/MINOR: resolvers: don't lower the case of binary DNS format The server's "hostname_dn" is in Domain Name format, not a pure string, as converted by resolv_str_to_dn_label(). It is made of lower-case string components delimited by binary lengths, e.g. <0x03>www<0x07>haproxy<0x03)org. As such it must not be lowercased again in srv_state_srv_update(), because 1) it's useless on the name components since already done, and 2) because it would replace component lengths 97 and above by 32-char shorter ones. Granted, not many domain names have that large components so the risk is very low but the operation is always wrong anyway. This was brought in 2.5 by commit 3406766d57 ("MEDIUM: resolvers: add a ref between servers and srv request or used SRV record"). In the same vein, let's fix the confusing strcasecmp() that are applied to this binary format, and use memcmp() instead. Here there's basically no risk to incorrectly match the wrong record, but that test alone is confusing enough to provoke the existence of the bug above. Finally let's update the component for that field to mention that it's in this format and already lower cased. Better not backport this, the risk of facing this bug is almost zero, and every time we touch such files something breaks for bad reasons.
2025-07-07 10:33:02 -04:00
memcmp(resolution->hostname_dn, hostname_dn, hostname_dn_len) == 0)
MEDIUM: thread/dns: Make DNS thread-safe
2017-10-04 10:17:58 -04:00
goto end;
MAJOR/REORG: dns: DNS resolution task and requester queues This patch is a major upgrade of the internal run-time DNS resolver in HAProxy and it brings the following 2 main changes: 1. DNS resolution task Up to now, DNS resolution was triggered by the health check task. From now, DNS resolution task is autonomous. It is started by HAProxy right after the scheduler is available and it is woken either when a network IO occurs for one of its nameserver or when a timeout is matched. From now, this means we can enable DNS resolution for a server without enabling health checking. 2. Introduction of a dns_requester structure Up to now, DNS resolution was purposely made for resolving server hostnames. The idea, is to ensure that any HAProxy internal object should be able to trigger a DNS resolution. For this purpose, 2 things has to be done: - clean up the DNS code from the server structure (this was already quite clean actually) and clean up the server's callbacks from manipulating too much DNS resolution - create an agnostic structure which allows linking a DNS resolution and a requester of any type (using obj_type enum) 3. Manage requesters through queues Up to now, there was an uniq relationship between a resolution and it's owner (aka the requester now). It's a shame, because in some cases, multiple objects may share the same hostname and may benefit from a resolution being performed by a third party. This patch introduces the notion of queues, which are basically lists of either currently running resolution or waiting ones. The resolutions are now available as a pool, which belongs to the resolvers. The pool has has a default size of 64 resolutions per resolvers and is allocated at configuration parsing.
2017-05-22 09:17:15 -04:00
MEDIUM: resolvers: remove the last occurrences of the "safe" argument This one was used to indicate whether the callee had to follow particularly safe code path when removing resolutions. Since the code now uses a kill list, this is not needed anymore.
2021-10-20 08:07:31 -04:00
resolv_unlink_resolution(srv->resolv_requester);
MAJOR/REORG: dns: DNS resolution task and requester queues This patch is a major upgrade of the internal run-time DNS resolver in HAProxy and it brings the following 2 main changes: 1. DNS resolution task Up to now, DNS resolution was triggered by the health check task. From now, DNS resolution task is autonomous. It is started by HAProxy right after the scheduler is available and it is woken either when a network IO occurs for one of its nameserver or when a timeout is matched. From now, this means we can enable DNS resolution for a server without enabling health checking. 2. Introduction of a dns_requester structure Up to now, DNS resolution was purposely made for resolving server hostnames. The idea, is to ensure that any HAProxy internal object should be able to trigger a DNS resolution. For this purpose, 2 things has to be done: - clean up the DNS code from the server structure (this was already quite clean actually) and clean up the server's callbacks from manipulating too much DNS resolution - create an agnostic structure which allows linking a DNS resolution and a requester of any type (using obj_type enum) 3. Manage requesters through queues Up to now, there was an uniq relationship between a resolution and it's owner (aka the requester now). It's a shame, because in some cases, multiple objects may share the same hostname and may benefit from a resolution being performed by a third party. This patch introduces the notion of queues, which are basically lists of either currently running resolution or waiting ones. The resolutions are now available as a pool, which belongs to the resolvers. The pool has has a default size of 64 resolutions per resolvers and is allocated at configuration parsing.
2017-05-22 09:17:15 -04:00
free(srv->hostname);
free(srv->hostname_dn);
MAJOR: dns: Refactor the DNS code This is a huge patch with many changes, all about the DNS. Initially, the idea was to update the DNS part to ease the threads support integration. But quickly, I started to refactor some parts. And after several iterations, it was impossible for me to commit the different parts atomically. So, instead of adding tens of patches, often reworking the same parts, it was easier to merge all my changes in a uniq patch. Here are all changes made on the DNS. First, the DNS initialization has been refactored. The DNS configuration parsing remains untouched, in cfgparse.c. But all checks have been moved in a post-check callback. In the function dns_finalize_config, for each resolvers, the nameservers configuration is tested and the task used to manage DNS resolutions is created. The links between the backend's servers and the resolvers are also created at this step. Here no connection are kept alive. So there is no needs anymore to reopen them after HAProxy fork. Connections used to send DNS queries will be opened on demand. Then, the way DNS requesters are linked to a DNS resolution has been reworked. The resolution used by a requester is now referenced into the dns_requester structure and the resolution pointers in server and dns_srvrq structures have been removed. wait and curr list of requesters, for a DNS resolution, have been replaced by a uniq list. And Finally, the way a requester is removed from a DNS resolution has been simplified. Now everything is done in dns_unlink_resolution. srv_set_fqdn function has been simplified. Now, there is only 1 way to set the server's FQDN, independently it is done by the CLI or when a SRV record is resolved. The static DNS resolutions pool has been replaced by a dynamoc pool. The part has been modified by Baptiste Assmann. The way the DNS resolutions are triggered by the task or by a health-check has been totally refactored. Now, all timeouts are respected. Especially hold.valid. The default frequency to wake up a resolvers is now configurable using "timeout resolve" parameter. Now, as documented, as long as invalid repsonses are received, we really wait all name servers responses before retrying. As far as possible, resources allocated during DNS configuration parsing are releases when HAProxy is shutdown. Beside all these changes, the code has been cleaned to ease code review and the doc has been updated.
2017-09-27 05:00:59 -04:00
srv->hostname = strdup(hostname);
srv->hostname_dn = strdup(hostname_dn);
MAJOR/REORG: dns: DNS resolution task and requester queues This patch is a major upgrade of the internal run-time DNS resolver in HAProxy and it brings the following 2 main changes: 1. DNS resolution task Up to now, DNS resolution was triggered by the health check task. From now, DNS resolution task is autonomous. It is started by HAProxy right after the scheduler is available and it is woken either when a network IO occurs for one of its nameserver or when a timeout is matched. From now, this means we can enable DNS resolution for a server without enabling health checking. 2. Introduction of a dns_requester structure Up to now, DNS resolution was purposely made for resolving server hostnames. The idea, is to ensure that any HAProxy internal object should be able to trigger a DNS resolution. For this purpose, 2 things has to be done: - clean up the DNS code from the server structure (this was already quite clean actually) and clean up the server's callbacks from manipulating too much DNS resolution - create an agnostic structure which allows linking a DNS resolution and a requester of any type (using obj_type enum) 3. Manage requesters through queues Up to now, there was an uniq relationship between a resolution and it's owner (aka the requester now). It's a shame, because in some cases, multiple objects may share the same hostname and may benefit from a resolution being performed by a third party. This patch introduces the notion of queues, which are basically lists of either currently running resolution or waiting ones. The resolutions are now available as a pool, which belongs to the resolvers. The pool has has a default size of 64 resolutions per resolvers and is allocated at configuration parsing.
2017-05-22 09:17:15 -04:00
srv->hostname_dn_len = hostname_dn_len;
if (!srv->hostname || !srv->hostname_dn)
MEDIUM: thread/dns: Make DNS thread-safe
2017-10-04 10:17:58 -04:00
goto err;
MAJOR/REORG: dns: DNS resolution task and requester queues This patch is a major upgrade of the internal run-time DNS resolver in HAProxy and it brings the following 2 main changes: 1. DNS resolution task Up to now, DNS resolution was triggered by the health check task. From now, DNS resolution task is autonomous. It is started by HAProxy right after the scheduler is available and it is woken either when a network IO occurs for one of its nameserver or when a timeout is matched. From now, this means we can enable DNS resolution for a server without enabling health checking. 2. Introduction of a dns_requester structure Up to now, DNS resolution was purposely made for resolving server hostnames. The idea, is to ensure that any HAProxy internal object should be able to trigger a DNS resolution. For this purpose, 2 things has to be done: - clean up the DNS code from the server structure (this was already quite clean actually) and clean up the server's callbacks from manipulating too much DNS resolution - create an agnostic structure which allows linking a DNS resolution and a requester of any type (using obj_type enum) 3. Manage requesters through queues Up to now, there was an uniq relationship between a resolution and it's owner (aka the requester now). It's a shame, because in some cases, multiple objects may share the same hostname and may benefit from a resolution being performed by a third party. This patch introduces the notion of queues, which are basically lists of either currently running resolution or waiting ones. The resolutions are now available as a pool, which belongs to the resolvers. The pool has has a default size of 64 resolutions per resolvers and is allocated at configuration parsing.
2017-05-22 09:17:15 -04:00
MEDIUM: dns: use Additional records from SRV responses Most DNS servers provide A/AAAA records in the Additional section of a response, which correspond to the SRV records from the Answer section: ;; QUESTION SECTION: ;_http._tcp.be1.domain.tld. IN SRV ;; ANSWER SECTION: _http._tcp.be1.domain.tld. 3600 IN SRV 5 500 80 A1.domain.tld. _http._tcp.be1.domain.tld. 3600 IN SRV 5 500 80 A8.domain.tld. _http._tcp.be1.domain.tld. 3600 IN SRV 5 500 80 A5.domain.tld. _http._tcp.be1.domain.tld. 3600 IN SRV 5 500 80 A6.domain.tld. _http._tcp.be1.domain.tld. 3600 IN SRV 5 500 80 A4.domain.tld. _http._tcp.be1.domain.tld. 3600 IN SRV 5 500 80 A3.domain.tld. _http._tcp.be1.domain.tld. 3600 IN SRV 5 500 80 A2.domain.tld. _http._tcp.be1.domain.tld. 3600 IN SRV 5 500 80 A7.domain.tld. ;; ADDITIONAL SECTION: A1.domain.tld. 3600 IN A 192.168.0.1 A8.domain.tld. 3600 IN A 192.168.0.8 A5.domain.tld. 3600 IN A 192.168.0.5 A6.domain.tld. 3600 IN A 192.168.0.6 A4.domain.tld. 3600 IN A 192.168.0.4 A3.domain.tld. 3600 IN A 192.168.0.3 A2.domain.tld. 3600 IN A 192.168.0.2 A7.domain.tld. 3600 IN A 192.168.0.7 SRV record support was introduced in HAProxy 1.8 and the first design did not take into account the records from the Additional section. Instead, a new resolution is associated to each server with its relevant FQDN. This behavior generates a lot of DNS requests (1 SRV + 1 per server associated). This patch aims at fixing this by: - when a DNS response is validated, we associate A/AAAA records to relevant SRV ones - set a flag on associated servers to prevent them from running a DNS resolution for said FADN - update server IP address with information found in the Additional section If no relevant record can be found in the Additional section, then HAProxy will failback to running a dedicated resolution for this server, as it used to do. This behavior is the one described in RFC 2782.
2019-06-07 03:40:55 -04:00
if (srv->flags & SRV_F_NO_RESOLUTION)
goto end;
MINOR: resolvers: rework prototype suffixes to split resolving and dns. A lot of prototypes in dns.h are specific to resolvers and must be renamed to split resolving and DNS layers.
2020-12-23 12:49:16 -05:00
if (resolv_link_resolution(srv, OBJ_TYPE_SERVER, 1) == -1)
MEDIUM: thread/dns: Make DNS thread-safe
2017-10-04 10:17:58 -04:00
goto err;
end:
MINOR: resolvers: renames some resolvers specific types to not use dns prefix This patch applies those changes on names: -struct dns_resolution { +struct resolv_resolution { -struct dns_requester { +struct resolv_requester { -struct dns_srvrq { +struct resolv_srvrq { @@ -185,12 +185,12 @@ struct stream { struct { - struct dns_requester *dns_requester; + struct resolv_requester *requester; ... - } dns_ctx; + } resolv_ctx;
2020-12-23 11:41:43 -05:00
if (!resolv_locked)
BUILD: threads: Rename SPIN/RWLOCK macros using HA_ prefix This remove any name conflicts, especially on Solaris.
2017-11-07 04:42:54 -05:00
HA_SPIN_UNLOCK(DNS_LOCK, &srv->resolvers->lock);
MAJOR/REORG: dns: DNS resolution task and requester queues This patch is a major upgrade of the internal run-time DNS resolver in HAProxy and it brings the following 2 main changes: 1. DNS resolution task Up to now, DNS resolution was triggered by the health check task. From now, DNS resolution task is autonomous. It is started by HAProxy right after the scheduler is available and it is woken either when a network IO occurs for one of its nameserver or when a timeout is matched. From now, this means we can enable DNS resolution for a server without enabling health checking. 2. Introduction of a dns_requester structure Up to now, DNS resolution was purposely made for resolving server hostnames. The idea, is to ensure that any HAProxy internal object should be able to trigger a DNS resolution. For this purpose, 2 things has to be done: - clean up the DNS code from the server structure (this was already quite clean actually) and clean up the server's callbacks from manipulating too much DNS resolution - create an agnostic structure which allows linking a DNS resolution and a requester of any type (using obj_type enum) 3. Manage requesters through queues Up to now, there was an uniq relationship between a resolution and it's owner (aka the requester now). It's a shame, because in some cases, multiple objects may share the same hostname and may benefit from a resolution being performed by a third party. This patch introduces the notion of queues, which are basically lists of either currently running resolution or waiting ones. The resolutions are now available as a pool, which belongs to the resolvers. The pool has has a default size of 64 resolutions per resolvers and is allocated at configuration parsing.
2017-05-22 09:17:15 -04:00
return 0;
MEDIUM: thread/dns: Make DNS thread-safe
2017-10-04 10:17:58 -04:00
err:
MINOR: resolvers: renames some resolvers specific types to not use dns prefix This patch applies those changes on names: -struct dns_resolution { +struct resolv_resolution { -struct dns_requester { +struct resolv_requester { -struct dns_srvrq { +struct resolv_srvrq { @@ -185,12 +185,12 @@ struct stream { struct { - struct dns_requester *dns_requester; + struct resolv_requester *requester; ... - } dns_ctx; + } resolv_ctx;
2020-12-23 11:41:43 -05:00
if (!resolv_locked)
BUILD: threads: Rename SPIN/RWLOCK macros using HA_ prefix This remove any name conflicts, especially on Solaris.
2017-11-07 04:42:54 -05:00
HA_SPIN_UNLOCK(DNS_LOCK, &srv->resolvers->lock);
MEDIUM: thread/dns: Make DNS thread-safe
2017-10-04 10:17:58 -04:00
return -1;
MINOR: server: cli: Add server FQDNs to server-state file and stats socket. This patch adds a new stats socket command to modify server FQDNs at run time. Its syntax: set server <backend>/<server> fqdn <FQDN> This patch also adds FQDNs to server state file at the end of each line for backward compatibility ("-" if not present).
2017-04-26 05:24:02 -04:00
}
MAJOR: server: postpone address resolution Server addresses are not resolved anymore upon the first pass so that we don't fail if an address cannot be resolved by the libc. Instead they are processed all at once after the configuration is fully loaded, by the new function srv_init_addr(). This function only acts on the server's address if this address uses an FQDN, which appears in server->hostname. For now the function does two things, to followup with HAProxy's historical default behavior: 1. apply server IP address found in server-state file if runtime DNS resolution is enabled for this server 2. use the DNS resolver provided by the libc If none of the 2 options above can find an IP address, then an error is returned. All of this will be needed to support the new server parameter "init-addr". For now, the biggest user-visible change is that all server resolution errors are dumped at once instead of causing a startup failure one by one.
2016-11-02 10:34:05 -04:00
/* Sets the server's address (srv->addr) from srv->lastaddr which was filled
* from the state file. This is suited for initial address configuration.
* Returns 0 on success otherwise a non-zero error code. In case of error,
* *err_code, if not NULL, is filled up.
*/
static int srv_apply_lastaddr(struct server *srv, int *err_code)
{
MINOR: server/ip: centralize server ip updates Add a new helper function named _srv_update_inetaddr() to centralize ip addr and port updates during runtime.
2023-11-13 10:42:56 -05:00
struct sockaddr_storage new_addr;
memset(&new_addr, 0, sizeof(new_addr));
BUG/MINOR: server: Use the configured address family for the initial resolution A regression was introduced by the commit c886fb58eb ("MINOR: server/ip: centralize server ip updates"). The configured address family is lost when the server address is initialized during the startup, for the resolution based on the libc or based on the server state-file. Thus, "ipv4@" and "ipv6@" prefixed are ignored. To fix the bug, we take care to use the configured address family before calling str2ip2() in srv_apply_lastaddr() and srv_apply_via_libc() functions. This patch should fix the issue #2393. It must be backported to 2.9.
2023-12-20 06:21:57 -05:00
/* Use the preferred family, if configured */
new_addr.ss_family = srv->addr.ss_family;
MINOR: server/ip: centralize server ip updates Add a new helper function named _srv_update_inetaddr() to centralize ip addr and port updates during runtime.
2023-11-13 10:42:56 -05:00
if (!str2ip2(srv->lastaddr, &new_addr, 0)) {
MAJOR: server: postpone address resolution Server addresses are not resolved anymore upon the first pass so that we don't fail if an address cannot be resolved by the libc. Instead they are processed all at once after the configuration is fully loaded, by the new function srv_init_addr(). This function only acts on the server's address if this address uses an FQDN, which appears in server->hostname. For now the function does two things, to followup with HAProxy's historical default behavior: 1. apply server IP address found in server-state file if runtime DNS resolution is enabled for this server 2. use the DNS resolver provided by the libc If none of the 2 options above can find an IP address, then an error is returned. All of this will be needed to support the new server parameter "init-addr". For now, the biggest user-visible change is that all server resolution errors are dumped at once instead of causing a startup failure one by one.
2016-11-02 10:34:05 -04:00
if (err_code)
*err_code |= ERR_WARN;
return 1;
}
BUG/MINOR: server/event_hdl: propagate map port info through inetaddr event server addr:svc_port updates during runtime might set or clear the SRV_F_MAPPORTS flag. Unfortunately, the flag update is still directly performed by srv_update_addr_port() function while the addr:svc_port update is being scheduled for atomic update. Given that existing readers don't take server's lock to read addr:svc_port, they also check the SRV_F_MAPPORTS flag right after without the lock. So we could cause the readers to incorrectly interpret the svc_port from the server struct because the mapport information is not published atomically, resulting in inconsistencies between svc_port / mapport flag. (MAPPORTS flag causes svc_port to be used differently by the reader) To fix this, we publish the mapport information within the INETADDR server event and we let the task responsible for updating server's addr and port position or clear the flag depending on the mapport hint. This patch depends on: - MINOR: server/event_hdl: add server_inetaddr struct to facilitate event data usage - MINOR: server/event_hdl: update _srv_event_hdl_prepare_inetaddr prototype This should be backported in 2.9 with 683b2ae01 ("MINOR: server/event_hdl: add SERVER_INETADDR event")
2023-12-07 11:08:08 -05:00
_srv_set_inetaddr(srv, &new_addr);
MAJOR: server: postpone address resolution Server addresses are not resolved anymore upon the first pass so that we don't fail if an address cannot be resolved by the libc. Instead they are processed all at once after the configuration is fully loaded, by the new function srv_init_addr(). This function only acts on the server's address if this address uses an FQDN, which appears in server->hostname. For now the function does two things, to followup with HAProxy's historical default behavior: 1. apply server IP address found in server-state file if runtime DNS resolution is enabled for this server 2. use the DNS resolver provided by the libc If none of the 2 options above can find an IP address, then an error is returned. All of this will be needed to support the new server parameter "init-addr". For now, the biggest user-visible change is that all server resolution errors are dumped at once instead of causing a startup failure one by one.
2016-11-02 10:34:05 -04:00
return 0;
}
MEDIUM: server: make use of init-addr It is now supported. If not set, we default to the legacy methods list which is "last,libc".
2016-11-04 10:10:17 -04:00
/* returns 0 if no error, otherwise a combination of ERR_* flags */
static int srv_iterate_initaddr(struct server *srv)
{
BUG/MINOR: server: Set server without addr but with dns in RMAINT on startup On startup, if a server has no address but the dns resolutions are configured, "none" method is added to the default init-addr methods, in addition to "last" and "libc". Thus on startup, this server is set to RMAINT mode if no address is found. It is only performed if no other init-addr method is configured. Setting the RMAINT mode on startup is important to inhibit the health checks. For instance, following servers will now be set to RMAINT mode on startup : server srv nofound.tld:80 check resolvers mydns server srv _http._tcp.service.local check resolvers mydns server-template srv 1-3 _http._tcp.service.local check resolvers mydns while followings ones will trigger an error : server srv nofound.tld:80 check server srv nofound.tld:80 check resolvers mydns init-addr libc server srv _http._tcp.service.local check server srv _http._tcp.service.local check resolvers mydns init-addr libc server-template srv 1-3 _http._tcp.service.local check resolvers mydns init-addr libc This patch must be backported as far as 1.8.
2020-10-26 05:31:17 -04:00
char *name = srv->hostname;
MEDIUM: server: make use of init-addr It is now supported. If not set, we default to the legacy methods list which is "last,libc".
2016-11-04 10:10:17 -04:00
int return_code = 0;
int err_code;
unsigned int methods;
BUG/MINOR: server: Set server without addr but with dns in RMAINT on startup On startup, if a server has no address but the dns resolutions are configured, "none" method is added to the default init-addr methods, in addition to "last" and "libc". Thus on startup, this server is set to RMAINT mode if no address is found. It is only performed if no other init-addr method is configured. Setting the RMAINT mode on startup is important to inhibit the health checks. For instance, following servers will now be set to RMAINT mode on startup : server srv nofound.tld:80 check resolvers mydns server srv _http._tcp.service.local check resolvers mydns server-template srv 1-3 _http._tcp.service.local check resolvers mydns while followings ones will trigger an error : server srv nofound.tld:80 check server srv nofound.tld:80 check resolvers mydns init-addr libc server srv _http._tcp.service.local check server srv _http._tcp.service.local check resolvers mydns init-addr libc server-template srv 1-3 _http._tcp.service.local check resolvers mydns init-addr libc This patch must be backported as far as 1.8.
2020-10-26 05:31:17 -04:00
/* If no addr and no hostname set, get the name from the DNS SRV request */
if (!name && srv->srvrq)
name = srv->srvrq->name;
MEDIUM: server: make use of init-addr It is now supported. If not set, we default to the legacy methods list which is "last,libc".
2016-11-04 10:10:17 -04:00
methods = srv->init_addr_methods;
BUG/MINOR: server: Set server without addr but with dns in RMAINT on startup On startup, if a server has no address but the dns resolutions are configured, "none" method is added to the default init-addr methods, in addition to "last" and "libc". Thus on startup, this server is set to RMAINT mode if no address is found. It is only performed if no other init-addr method is configured. Setting the RMAINT mode on startup is important to inhibit the health checks. For instance, following servers will now be set to RMAINT mode on startup : server srv nofound.tld:80 check resolvers mydns server srv _http._tcp.service.local check resolvers mydns server-template srv 1-3 _http._tcp.service.local check resolvers mydns while followings ones will trigger an error : server srv nofound.tld:80 check server srv nofound.tld:80 check resolvers mydns init-addr libc server srv _http._tcp.service.local check server srv _http._tcp.service.local check resolvers mydns init-addr libc server-template srv 1-3 _http._tcp.service.local check resolvers mydns init-addr libc This patch must be backported as far as 1.8.
2020-10-26 05:31:17 -04:00
if (!methods) {
/* otherwise default to "last,libc" */
MEDIUM: server: make use of init-addr It is now supported. If not set, we default to the legacy methods list which is "last,libc".
2016-11-04 10:10:17 -04:00
srv_append_initaddr(&methods, SRV_IADDR_LAST);
srv_append_initaddr(&methods, SRV_IADDR_LIBC);
BUG/MINOR: server: Set server without addr but with dns in RMAINT on startup On startup, if a server has no address but the dns resolutions are configured, "none" method is added to the default init-addr methods, in addition to "last" and "libc". Thus on startup, this server is set to RMAINT mode if no address is found. It is only performed if no other init-addr method is configured. Setting the RMAINT mode on startup is important to inhibit the health checks. For instance, following servers will now be set to RMAINT mode on startup : server srv nofound.tld:80 check resolvers mydns server srv _http._tcp.service.local check resolvers mydns server-template srv 1-3 _http._tcp.service.local check resolvers mydns while followings ones will trigger an error : server srv nofound.tld:80 check server srv nofound.tld:80 check resolvers mydns init-addr libc server srv _http._tcp.service.local check server srv _http._tcp.service.local check resolvers mydns init-addr libc server-template srv 1-3 _http._tcp.service.local check resolvers mydns init-addr libc This patch must be backported as far as 1.8.
2020-10-26 05:31:17 -04:00
if (srv->resolvers_id) {
/* dns resolution is configured, add "none" to not fail on startup */
srv_append_initaddr(&methods, SRV_IADDR_NONE);
}
MEDIUM: server: make use of init-addr It is now supported. If not set, we default to the legacy methods list which is "last,libc".
2016-11-04 10:10:17 -04:00
}
MINOR: init: add -dr to ignore server address resolution failures It is very common when validating a configuration out of production not to have access to the same resolvers and to fail on server address resolution, making it difficult to test a configuration. This option simply appends the "none" method to the list of address resolution methods for all servers, ensuring that even if the libc fails to resolve an address, the startup sequence is not interrupted.
2016-11-07 15:03:16 -05:00
/* "-dr" : always append "none" so that server addresses resolution
* failures are silently ignored, this is convenient to validate some
* configs out of their environment.
*/
if (global.tune.options & GTUNE_RESOLVE_DONTFAIL)
srv_append_initaddr(&methods, SRV_IADDR_NONE);
MEDIUM: server: make use of init-addr It is now supported. If not set, we default to the legacy methods list which is "last,libc".
2016-11-04 10:10:17 -04:00
while (methods) {
err_code = 0;
switch (srv_get_next_initaddr(&methods)) {
case SRV_IADDR_LAST:
if (!srv->lastaddr)
continue;
if (srv_apply_lastaddr(srv, &err_code) == 0)
MINOR: server: Add dynamic session cookies. This adds a new "dynamic" keyword for the cookie option. If set, a cookie will be generated for each server (assuming one isn't already provided on the "server" line), from the IP of the server, the TCP port, and a secret key provided. To provide the secret key, a new keyword as been added, "dynamic-cookie-key", for backends. Example : backend bk_web balance roundrobin dynamic-cookie-key "bla" cookie WEBSRV insert dynamic server s1 127.0.0.1:80 check server s2 192.168.56.1:80 check This is a first step to be able to dynamically add and remove servers, without modifying the configuration file, and still have all the load balancers redirect the traffic to the right server. Provide a way to generate session cookies, based on the IP address of the server, the TCP port, and a secret key provided.
2017-03-14 15:01:29 -04:00
goto out;
MEDIUM: server: make use of init-addr It is now supported. If not set, we default to the legacy methods list which is "last,libc".
2016-11-04 10:10:17 -04:00
return_code |= err_code;
break;
case SRV_IADDR_LIBC:
if (!srv->hostname)
continue;
if (srv_set_addr_via_libc(srv, &err_code) == 0)
MINOR: server: Add dynamic session cookies. This adds a new "dynamic" keyword for the cookie option. If set, a cookie will be generated for each server (assuming one isn't already provided on the "server" line), from the IP of the server, the TCP port, and a secret key provided. To provide the secret key, a new keyword as been added, "dynamic-cookie-key", for backends. Example : backend bk_web balance roundrobin dynamic-cookie-key "bla" cookie WEBSRV insert dynamic server s1 127.0.0.1:80 check server s2 192.168.56.1:80 check This is a first step to be able to dynamically add and remove servers, without modifying the configuration file, and still have all the load balancers redirect the traffic to the right server. Provide a way to generate session cookies, based on the IP address of the server, the TCP port, and a secret key provided.
2017-03-14 15:01:29 -04:00
goto out;
MEDIUM: server: make use of init-addr It is now supported. If not set, we default to the legacy methods list which is "last,libc".
2016-11-04 10:10:17 -04:00
return_code |= err_code;
break;
MINOR: server: implement init-addr none The server is put into the "no address" maintenance state in this case.
2016-11-04 10:17:58 -04:00
case SRV_IADDR_NONE:
MINOR: server: change adm_st_chg_cause storage type Even though it doesn't look like it at first glance, this is more like a cleanup than an actual code improvement: Given that srv->adm_st_chg_cause has been used to exclusively store static strings ever since it was implemented, we make the choice to store it as an enum instead of a fixed-size string within server struct. This will allow to save some space in server struct, and will make it more easily exportable (ie: event handlers) because of the reduced memory footprint during handling and the ability to later get the corresponding human-readable message when it's explicitly needed.
2023-04-03 11:40:28 -04:00
srv_set_admin_flag(srv, SRV_ADMF_RMAINT, SRV_ADM_STCHGC_NONE);
MEDIUM: server: make libc resolution failure non-fatal Now that we have "init-addr none", it becomes possible to recover on libc resolver's failures. Thus it's preferable not to alert nor fail at the moment the libc is called, and instead process the failure at the end of the list. This allows "none" to be set after libc to provide a smooth fallback in case of resolver issues.
2016-11-07 13:19:22 -05:00
if (return_code) {
BUG/MINOR: server: Don't warn on server resolution failure with init-addr none During startup, when the "none" method for "init-addr" is evaluated, a warning is emitted if a resolution failure was previously encountered. The documentation of the "none" method states it should be used to ignore server resolution failures and let the server starts in DOWN state. However, because a warning may be emitted, it is not possible to start HAProxy with "zero-warning" option. The same is true when "-dr" command line option is used. It is counter intuitive and, in a way, this contradict what is specified in the documentation. So instead, a notice message is now emitted. At the end, if "-dr" command line option is used or if "none" method is explicitly used, it means the admin is agree with server resolution failures. There is no reason to emit a warning. This patch should fix the issue #2176. It could be backported to all stable versions but backporting to 2.8 is probably enough for now.
2023-07-20 11:25:54 -04:00
ha_notice("could not resolve address '%s', disabling server.\n",
name);
MEDIUM: server: make libc resolution failure non-fatal Now that we have "init-addr none", it becomes possible to recover on libc resolver's failures. Thus it's preferable not to alert nor fail at the moment the libc is called, and instead process the failure at the end of the list. This allows "none" to be set after libc to provide a smooth fallback in case of resolver issues.
2016-11-07 13:19:22 -05:00
}
MINOR: server: implement init-addr none The server is put into the "no address" maintenance state in this case.
2016-11-04 10:17:58 -04:00
return return_code;
MINOR: server: add support for explicit numeric address in init-addr This will allow a server to automatically fall back to an explicit numeric IP address when all other methods fail. The address is simply specified in the address list.
2016-11-02 10:05:56 -04:00
case SRV_IADDR_IP:
BUG/MINOR: server/event_hdl: propagate map port info through inetaddr event server addr:svc_port updates during runtime might set or clear the SRV_F_MAPPORTS flag. Unfortunately, the flag update is still directly performed by srv_update_addr_port() function while the addr:svc_port update is being scheduled for atomic update. Given that existing readers don't take server's lock to read addr:svc_port, they also check the SRV_F_MAPPORTS flag right after without the lock. So we could cause the readers to incorrectly interpret the svc_port from the server struct because the mapport information is not published atomically, resulting in inconsistencies between svc_port / mapport flag. (MAPPORTS flag causes svc_port to be used differently by the reader) To fix this, we publish the mapport information within the INETADDR server event and we let the task responsible for updating server's addr and port position or clear the flag depending on the mapport hint. This patch depends on: - MINOR: server/event_hdl: add server_inetaddr struct to facilitate event data usage - MINOR: server/event_hdl: update _srv_event_hdl_prepare_inetaddr prototype This should be backported in 2.9 with 683b2ae01 ("MINOR: server/event_hdl: add SERVER_INETADDR event")
2023-12-07 11:08:08 -05:00
_srv_set_inetaddr(srv, &srv->init_addr);
MINOR: server: add support for explicit numeric address in init-addr This will allow a server to automatically fall back to an explicit numeric IP address when all other methods fail. The address is simply specified in the address list.
2016-11-02 10:05:56 -04:00
if (return_code) {
BUG/MINOR: server: Don't warn fallback IP is used during init-addr resolution When a fallback IP address is provided in the list of methods to use to resolve the server address, a warning is emitted if previous methods failed. The aim is to inform this address will be used for the server. However, it is valid use-case. It is the expected behavior. There is no reason to emit a warning. Having a message during HAProxy startup to inform the fallback IP address will be used is probably a good idea. But it should be a notice not a warning. Otherwise, checking the configuration validity will always failed, just like starting HAProxy in zero-warning mode while the option was set on purpose. This patch should fix the issue #2627. It must be backported to all stable versions.
2024-07-18 03:52:46 -04:00
ha_notice("could not resolve address '%s', falling back to configured address.\n",
name);
MINOR: server: add support for explicit numeric address in init-addr This will allow a server to automatically fall back to an explicit numeric IP address when all other methods fail. The address is simply specified in the address list.
2016-11-02 10:05:56 -04:00
}
MINOR: server: Add dynamic session cookies. This adds a new "dynamic" keyword for the cookie option. If set, a cookie will be generated for each server (assuming one isn't already provided on the "server" line), from the IP of the server, the TCP port, and a secret key provided. To provide the secret key, a new keyword as been added, "dynamic-cookie-key", for backends. Example : backend bk_web balance roundrobin dynamic-cookie-key "bla" cookie WEBSRV insert dynamic server s1 127.0.0.1:80 check server s2 192.168.56.1:80 check This is a first step to be able to dynamically add and remove servers, without modifying the configuration file, and still have all the load balancers redirect the traffic to the right server. Provide a way to generate session cookies, based on the IP address of the server, the TCP port, and a secret key provided.
2017-03-14 15:01:29 -04:00
goto out;
MINOR: server: add support for explicit numeric address in init-addr This will allow a server to automatically fall back to an explicit numeric IP address when all other methods fail. The address is simply specified in the address list.
2016-11-02 10:05:56 -04:00
MEDIUM: server: make use of init-addr It is now supported. If not set, we default to the legacy methods list which is "last,libc".
2016-11-04 10:10:17 -04:00
default: /* unhandled method */
break;
}
}
MINOR: server: use parsing ctx for server init addr Initialize the parsing context in srv_init_addr. This function is called after configuration check. This will standardize the stderr output on startup with the parse_server function.
2021-05-28 05:01:52 -04:00
if (!return_code)
ha_alert("no method found to resolve address '%s'.\n", name);
else
ha_alert("could not resolve address '%s'.\n", name);
MEDIUM: server: make use of init-addr It is now supported. If not set, we default to the legacy methods list which is "last,libc".
2016-11-04 10:10:17 -04:00
return_code |= ERR_ALERT | ERR_FATAL;
return return_code;
MINOR: server: Add dynamic session cookies. This adds a new "dynamic" keyword for the cookie option. If set, a cookie will be generated for each server (assuming one isn't already provided on the "server" line), from the IP of the server, the TCP port, and a secret key provided. To provide the secret key, a new keyword as been added, "dynamic-cookie-key", for backends. Example : backend bk_web balance roundrobin dynamic-cookie-key "bla" cookie WEBSRV insert dynamic server s1 127.0.0.1:80 check server s2 192.168.56.1:80 check This is a first step to be able to dynamically add and remove servers, without modifying the configuration file, and still have all the load balancers redirect the traffic to the right server. Provide a way to generate session cookies, based on the IP address of the server, the TCP port, and a secret key provided.
2017-03-14 15:01:29 -04:00
out:
srv_set_dyncookie(srv);
BUG/MEDIUM: server: do not auto insert a dynamic server in px addr_node Until then, the servers were automatically attached on their creation into the proxy addr_node tree via _srv_parse_init. In case of an invalid dynamic server which is instantly freed, no detach operation was made leaving a NULL server in the tree. Change this mode of operation by marking the attach operation as optional in _srv_parse_init. This operation is not conduct for a dynamic server. The server is attached only at the end of the CLI handler when it is marked as valid. This must be backported up to 2.4.
2021-06-08 09:19:51 -04:00
srv_set_addr_desc(srv, 1);
MINOR: server: Add dynamic session cookies. This adds a new "dynamic" keyword for the cookie option. If set, a cookie will be generated for each server (assuming one isn't already provided on the "server" line), from the IP of the server, the TCP port, and a secret key provided. To provide the secret key, a new keyword as been added, "dynamic-cookie-key", for backends. Example : backend bk_web balance roundrobin dynamic-cookie-key "bla" cookie WEBSRV insert dynamic server s1 127.0.0.1:80 check server s2 192.168.56.1:80 check This is a first step to be able to dynamically add and remove servers, without modifying the configuration file, and still have all the load balancers redirect the traffic to the right server. Provide a way to generate session cookies, based on the IP address of the server, the TCP port, and a secret key provided.
2017-03-14 15:01:29 -04:00
return return_code;
MEDIUM: server: make use of init-addr It is now supported. If not set, we default to the legacy methods list which is "last,libc".
2016-11-04 10:10:17 -04:00
}
MAJOR: server: postpone address resolution Server addresses are not resolved anymore upon the first pass so that we don't fail if an address cannot be resolved by the libc. Instead they are processed all at once after the configuration is fully loaded, by the new function srv_init_addr(). This function only acts on the server's address if this address uses an FQDN, which appears in server->hostname. For now the function does two things, to followup with HAProxy's historical default behavior: 1. apply server IP address found in server-state file if runtime DNS resolution is enabled for this server 2. use the DNS resolver provided by the libc If none of the 2 options above can find an IP address, then an error is returned. All of this will be needed to support the new server parameter "init-addr". For now, the biggest user-visible change is that all server resolution errors are dumped at once instead of causing a startup failure one by one.
2016-11-02 10:34:05 -04:00
/*
* This function parses all backends and all servers within each backend
* and performs servers' addr resolution based on information provided by:
* - configuration file
* - server-state file (states provided by an 'old' haproxy process)
*
* Returns 0 if no error, otherwise, a combination of ERR_ flags.
*/
int srv_init_addr(void)
{
struct proxy *curproxy;
int return_code = 0;
MINOR/CLEANUP: proxy: rename "proxy" to "proxies_list" Rename the global variable "proxy" to "proxies_list". There's been multiple proxies in haproxy for quite some time, and "proxy" is a potential source of bugs, a number of functions have a "proxy" argument, and some code used "proxy" when it really meant "px" or "curproxy". It worked by pure luck, because it usually happened while parsing the config, and thus "proxy" pointed to the currently parsed proxy, but we should probably not rely on this. [wt: some of these are definitely fixes that are worth backporting]
2017-11-24 10:54:05 -05:00
curproxy = proxies_list;
MAJOR: server: postpone address resolution Server addresses are not resolved anymore upon the first pass so that we don't fail if an address cannot be resolved by the libc. Instead they are processed all at once after the configuration is fully loaded, by the new function srv_init_addr(). This function only acts on the server's address if this address uses an FQDN, which appears in server->hostname. For now the function does two things, to followup with HAProxy's historical default behavior: 1. apply server IP address found in server-state file if runtime DNS resolution is enabled for this server 2. use the DNS resolver provided by the libc If none of the 2 options above can find an IP address, then an error is returned. All of this will be needed to support the new server parameter "init-addr". For now, the biggest user-visible change is that all server resolution errors are dumped at once instead of causing a startup failure one by one.
2016-11-02 10:34:05 -04:00
while (curproxy) {
struct server *srv;
/* servers are in backend only */
MINOR: proxy: Introduce proxy flags to replace disabled bitfield This change is required to support TCP/HTTP rules in defaults sections. The 'disabled' bitfield in the proxy structure, used to know if a proxy is disabled or stopped, is replaced a generic bitfield named 'flags'. PR_DISABLED and PR_STOPPED flags are renamed to PR_FL_DISABLED and PR_FL_STOPPED respectively. In addition, everywhere there is a test to know if a proxy is disabled or stopped, there is now a bitwise AND operation on PR_FL_DISABLED and/or PR_FL_STOPPED flags.
2021-10-06 08:24:19 -04:00
if (!(curproxy->cap & PR_CAP_BE) || (curproxy->flags & (PR_FL_DISABLED|PR_FL_STOPPED)))
MAJOR: server: postpone address resolution Server addresses are not resolved anymore upon the first pass so that we don't fail if an address cannot be resolved by the libc. Instead they are processed all at once after the configuration is fully loaded, by the new function srv_init_addr(). This function only acts on the server's address if this address uses an FQDN, which appears in server->hostname. For now the function does two things, to followup with HAProxy's historical default behavior: 1. apply server IP address found in server-state file if runtime DNS resolution is enabled for this server 2. use the DNS resolver provided by the libc If none of the 2 options above can find an IP address, then an error is returned. All of this will be needed to support the new server parameter "init-addr". For now, the biggest user-visible change is that all server resolution errors are dumped at once instead of causing a startup failure one by one.
2016-11-02 10:34:05 -04:00
goto srv_init_addr_next;
MINOR: server: use parsing ctx for server init addr Initialize the parsing context in srv_init_addr. This function is called after configuration check. This will standardize the stderr output on startup with the parse_server function.
2021-05-28 05:01:52 -04:00
for (srv = curproxy->srv; srv; srv = srv->next) {
set_usermsgs_ctx(srv->conf.file, srv->conf.line, &srv->obj_type);
BUG/MINOR: server: Set server without addr but with dns in RMAINT on startup On startup, if a server has no address but the dns resolutions are configured, "none" method is added to the default init-addr methods, in addition to "last" and "libc". Thus on startup, this server is set to RMAINT mode if no address is found. It is only performed if no other init-addr method is configured. Setting the RMAINT mode on startup is important to inhibit the health checks. For instance, following servers will now be set to RMAINT mode on startup : server srv nofound.tld:80 check resolvers mydns server srv _http._tcp.service.local check resolvers mydns server-template srv 1-3 _http._tcp.service.local check resolvers mydns while followings ones will trigger an error : server srv nofound.tld:80 check server srv nofound.tld:80 check resolvers mydns init-addr libc server srv _http._tcp.service.local check server srv _http._tcp.service.local check resolvers mydns init-addr libc server-template srv 1-3 _http._tcp.service.local check resolvers mydns init-addr libc This patch must be backported as far as 1.8.
2020-10-26 05:31:17 -04:00
if (srv->hostname || srv->srvrq)
Revert "BUG/MINOR: server: Remove FQDN requirement for using init-addr and state file" This reverts commit 19e8aa58f7c42e602a95b4ceb4b254c424aed11c. It causes some trouble reported by Manu : listen tls [...] server bla 127.0.0.1:8080 [ALERT] 248/130258 (21960) : parsing [/etc/haproxy/test.cfg:53] : 'server bla' : no method found to resolve address '(null)' [ALERT] 248/130258 (21960) : Failed to initialize server(s) addr. According to Nenad : "It's not a good way to fix the issue we were experiencing before. It will need a bigger rewrite, because the logic in srv_iterate_initaddr needs to be changed."
2017-09-06 08:22:45 -04:00
return_code |= srv_iterate_initaddr(srv);
MINOR: server: use parsing ctx for server init addr Initialize the parsing context in srv_init_addr. This function is called after configuration check. This will standardize the stderr output on startup with the parse_server function.
2021-05-28 05:01:52 -04:00
reset_usermsgs_ctx();
}
MAJOR: server: postpone address resolution Server addresses are not resolved anymore upon the first pass so that we don't fail if an address cannot be resolved by the libc. Instead they are processed all at once after the configuration is fully loaded, by the new function srv_init_addr(). This function only acts on the server's address if this address uses an FQDN, which appears in server->hostname. For now the function does two things, to followup with HAProxy's historical default behavior: 1. apply server IP address found in server-state file if runtime DNS resolution is enabled for this server 2. use the DNS resolver provided by the libc If none of the 2 options above can find an IP address, then an error is returned. All of this will be needed to support the new server parameter "init-addr". For now, the biggest user-visible change is that all server resolution errors are dumped at once instead of causing a startup failure one by one.
2016-11-02 10:34:05 -04:00
srv_init_addr_next:
curproxy = curproxy->next;
}
return return_code;
}
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
/*
* Must be called with the server lock held.
*/
REORG: server: Export and rename some functions updating server info Some static functions are now exported and renamed to follow the same pattern of other exported functions. Here is the list : * update_server_fqdn: Renamed to srv_update_fqdn and exported * update_server_check_addr_port: renamed to srv_update_check_addr_port and exported * update_server_agent_addr_port: renamed to srv_update_agent_addr_port and exported * update_server_addr: renamed to srv_update_addr * update_server_addr_potr: renamed to srv_update_addr_port * srv_prepare_for_resolution: exported This change is mandatory to move all functions dealing with the server-state files in a separate file.
2021-02-16 06:07:47 -05:00
const char *srv_update_fqdn(struct server *server, const char *fqdn, const char *updater, int resolv_locked)
MINOR: server: cli: Add server FQDNs to server-state file and stats socket. This patch adds a new stats socket command to modify server FQDNs at run time. Its syntax: set server <backend>/<server> fqdn <FQDN> This patch also adds FQDNs to server state file at the end of each line for backward compatibility ("-" if not present).
2017-04-26 05:24:02 -04:00
{
MAJOR: chunks: replace struct chunk with struct buffer Now all the code used to manipulate chunks uses a struct buffer instead. The functions are still called "chunk*", and some of them will progressively move to the generic buffer handling code as they are cleaned up.
2018-07-13 05:56:34 -04:00
struct buffer *msg;
MINOR: server: cli: Add server FQDNs to server-state file and stats socket. This patch adds a new stats socket command to modify server FQDNs at run time. Its syntax: set server <backend>/<server> fqdn <FQDN> This patch also adds FQDNs to server state file at the end of each line for backward compatibility ("-" if not present).
2017-04-26 05:24:02 -04:00
msg = get_trash_chunk();
chunk_reset(msg);
CLEANUP: Compare the return value of `XXXcmp()` functions with zero According to coding-style.txt it is recommended to use: `strcmp(a, b) == 0` instead of `!strcmp(a, b)` So let's do this. The change was performed by running the following (very long) coccinelle patch on src/: @@ statement S; expression E; expression F; @@ if ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) ( S | { ... } ) @@ statement S; expression E; expression F; @@ if ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) ( S | { ... } ) @@ expression E; expression F; expression G; @@ ( G && ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( G || ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 && G ) @@ expression E; expression F; expression G; @@ ( ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) != 0 || G ) @@ expression E; expression F; expression G; @@ ( G && - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( G || - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 && G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 || G ) @@ expression E; expression F; expression G; @@ ( - ! ( dns_hostname_cmp | eb_memcmp | memcmp | strcasecmp | strcmp | strncasecmp | strncmp ) - (E, F) + (E, F) == 0 )
2021-01-02 16:31:53 -05:00
if (server->hostname && strcmp(fqdn, server->hostname) == 0) {
MINOR: server: cli: Add server FQDNs to server-state file and stats socket. This patch adds a new stats socket command to modify server FQDNs at run time. Its syntax: set server <backend>/<server> fqdn <FQDN> This patch also adds FQDNs to server state file at the end of each line for backward compatibility ("-" if not present).
2017-04-26 05:24:02 -04:00
chunk_appendf(msg, "no need to change the FDQN");
goto out;
}
if (strlen(fqdn) > DNS_MAX_NAME_SIZE || invalid_domainchar(fqdn)) {
chunk_appendf(msg, "invalid fqdn '%s'", fqdn);
goto out;
}
chunk_appendf(msg, "%s/%s changed its FQDN from %s to %s",
server->proxy->id, server->id, server->hostname, fqdn);
MINOR: resolvers: renames some resolvers specific types to not use dns prefix This patch applies those changes on names: -struct dns_resolution { +struct resolv_resolution { -struct dns_requester { +struct resolv_requester { -struct dns_srvrq { +struct resolv_srvrq { @@ -185,12 +185,12 @@ struct stream { struct { - struct dns_requester *dns_requester; + struct resolv_requester *requester; ... - } dns_ctx; + } resolv_ctx;
2020-12-23 11:41:43 -05:00
if (srv_set_fqdn(server, fqdn, resolv_locked) < 0) {
MINOR: server: cli: Add server FQDNs to server-state file and stats socket. This patch adds a new stats socket command to modify server FQDNs at run time. Its syntax: set server <backend>/<server> fqdn <FQDN> This patch also adds FQDNs to server state file at the end of each line for backward compatibility ("-" if not present).
2017-04-26 05:24:02 -04:00
chunk_reset(msg);
chunk_appendf(msg, "could not update %s/%s FQDN",
server->proxy->id, server->id);
goto out;
}
BUG/MEDIUM: server: server stuck in maintenance after FQDN change Pierre Bonnat reported that SRV-based server-template recently stopped to work properly. After reviewing the changes, it was found that the regression was caused by a4d04c6 ("BUG/MINOR: server: make sure the HMAINT state is part of MAINT") Indeed, HMAINT is not a regular maintenance flag. It was implemented in b418c122 a4d04c6 ("BUG/MINOR: server: make sure the HMAINT state is part of MAINT"). This flag is only set (and never removed) when the server FQDN is changed from its initial config-time value. This can happen with "set server fqdn" command as well as SRV records updates from the DNS. This flag should ideally belong to server flags.. but it was stored under srv_admin enum because cur_admin is properly exported/imported via server state-file while regular server's flags are not. Due to a4d04c6, when a server FQDN changes, the server is considered in maintenance, and since the HMAINT flag is never removed, the server is stuck in maintenance. To fix the issue, we partially revert a4d04c6. But this latter commit is right on one point: HMAINT flag was way too confusing and mixed-up between regular MAINT flags, thus there's nothing to blame about a4d04c6 as it was error-prone anyway.. To prevent such kind of bugs from happening again, let's rename HMAINT to something more explicit (SRV_ADMF_FQDN_CHANGED) and make it stand out under srv_admin enum so we're not tempted to mix it with regular maintenance flags anymore. Since a4d04c6 was set to be backported in all versions, this patch must be backported there as well.
2024-10-16 04:57:32 -04:00
/* Flag as FQDN changed (e.g.: set from stats socket or resolvers) */
server->next_admin |= SRV_ADMF_FQDN_CHANGED;
MINOR: server: cli: Add server FQDNs to server-state file and stats socket. This patch adds a new stats socket command to modify server FQDNs at run time. Its syntax: set server <backend>/<server> fqdn <FQDN> This patch also adds FQDNs to server state file at the end of each line for backward compatibility ("-" if not present).
2017-04-26 05:24:02 -04:00
out:
if (updater)
chunk_appendf(msg, " by '%s'", updater);
chunk_appendf(msg, "\n");
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
return msg->area;
MINOR: server: cli: Add server FQDNs to server-state file and stats socket. This patch adds a new stats socket command to modify server FQDNs at run time. Its syntax: set server <backend>/<server> fqdn <FQDN> This patch also adds FQDNs to server state file at the end of each line for backward compatibility ("-" if not present).
2017-04-26 05:24:02 -04:00
}
MINOR: server: create new function cli_find_server() to find a server Several CLI commands require a server, so let's have a function to look this one up and prepare the appropriate error message and the appctx's state in case of failure.
2016-11-23 11:15:08 -05:00
/* Expects to find a backend and a server in <arg> under the form <backend>/<server>,
* and returns the pointer to the server. Otherwise, display adequate error messages
CLEANUP: cli: rename STAT_CLI_* to CLI_ST_* These are in CLI states, not stats states anymore. STAT_CLI_O_CUSTOM was more appropriately renamed CLI_ST_CALLBACK.
2016-11-24 09:53:53 -05:00
* on the CLI, sets the CLI's state to CLI_ST_PRINT and returns NULL. This is only
MINOR: server: create new function cli_find_server() to find a server Several CLI commands require a server, so let's have a function to look this one up and prepare the appropriate error message and the appctx's state in case of failure.
2016-11-23 11:15:08 -05:00
* used for CLI commands requiring a server name.
* Important: the <arg> is modified to remove the '/'.
*/
struct server *cli_find_server(struct appctx *appctx, char *arg)
{
struct proxy *px;
struct server *sv;
MINOR: proxy: simplify parsing 'backend/server' Several CLI handlers use a server argument specified with the format '<backend>/<server>'. The parsing of this arguement is done in two steps, first splitting the string with '/' delimiter and then use get_backend_server() to retrieve the server instance. Refactor this code sections with the following changes : * splitting is reimplented using ist API * get_backend_server() is removed. Instead use the already existing proxy_be_by_name() then server_find_by_name() which contains duplicated code with the now removed function. No functional change occurs with this commit. However, it will be useful to add new configuration options reusing the same '<backend>/<server>' for reverse connect.
2023-08-07 10:24:24 -04:00
struct ist be_name, sv_name = ist(arg);
MINOR: server: create new function cli_find_server() to find a server Several CLI commands require a server, so let's have a function to look this one up and prepare the appropriate error message and the appctx's state in case of failure.
2016-11-23 11:15:08 -05:00
MINOR: proxy: simplify parsing 'backend/server' Several CLI handlers use a server argument specified with the format '<backend>/<server>'. The parsing of this arguement is done in two steps, first splitting the string with '/' delimiter and then use get_backend_server() to retrieve the server instance. Refactor this code sections with the following changes : * splitting is reimplented using ist API * get_backend_server() is removed. Instead use the already existing proxy_be_by_name() then server_find_by_name() which contains duplicated code with the now removed function. No functional change occurs with this commit. However, it will be useful to add new configuration options reusing the same '<backend>/<server>' for reverse connect.
2023-08-07 10:24:24 -04:00
be_name = istsplit(&sv_name, '/');
if (!istlen(sv_name)) {
BUG/MINOR: server/cli: add missing LF at the end of certain notice/error lines Some cli_err(), cli_msg() or even ha_error() etc are missing the trailing LF, which breaks the continuity of the CLI parsing: the extra LF that serves to mark the end of the command is in fact taken as the missing LF and no extra one is added. This patch adds the missing LF on identified messages. It might be worth trying to proceed in a more generic way with this, given the amount of code that is possibly at risk.
2024-02-08 11:43:14 -05:00
cli_err(appctx, "Require 'backend/server'.\n");
MINOR: server: create new function cli_find_server() to find a server Several CLI commands require a server, so let's have a function to look this one up and prepare the appropriate error message and the appctx's state in case of failure.
2016-11-23 11:15:08 -05:00
return NULL;
}
MINOR: proxy: simplify parsing 'backend/server' Several CLI handlers use a server argument specified with the format '<backend>/<server>'. The parsing of this arguement is done in two steps, first splitting the string with '/' delimiter and then use get_backend_server() to retrieve the server instance. Refactor this code sections with the following changes : * splitting is reimplented using ist API * get_backend_server() is removed. Instead use the already existing proxy_be_by_name() then server_find_by_name() which contains duplicated code with the now removed function. No functional change occurs with this commit. However, it will be useful to add new configuration options reusing the same '<backend>/<server>' for reverse connect.
2023-08-07 10:24:24 -04:00
if (!(px = proxy_be_by_name(ist0(be_name)))) {
BUG/MINOR: server/cli: add missing LF at the end of certain notice/error lines Some cli_err(), cli_msg() or even ha_error() etc are missing the trailing LF, which breaks the continuity of the CLI parsing: the extra LF that serves to mark the end of the command is in fact taken as the missing LF and no extra one is added. This patch adds the missing LF on identified messages. It might be worth trying to proceed in a more generic way with this, given the amount of code that is possibly at risk.
2024-02-08 11:43:14 -05:00
cli_err(appctx, "No such backend.\n");
MINOR: proxy: simplify parsing 'backend/server' Several CLI handlers use a server argument specified with the format '<backend>/<server>'. The parsing of this arguement is done in two steps, first splitting the string with '/' delimiter and then use get_backend_server() to retrieve the server instance. Refactor this code sections with the following changes : * splitting is reimplented using ist API * get_backend_server() is removed. Instead use the already existing proxy_be_by_name() then server_find_by_name() which contains duplicated code with the now removed function. No functional change occurs with this commit. However, it will be useful to add new configuration options reusing the same '<backend>/<server>' for reverse connect.
2023-08-07 10:24:24 -04:00
return NULL;
}
CLEANUP: server: rename server_find_by_name() to server_find() This function doesn't just look at the name but also the ID when the argument starts with a '#'. So the name is not correct and explains why this function is not always used when the name only is needed, and why the list-based findserver() is used instead. So let's just call the function "server_find()", and rename its generation-id based cousin "server_find_unique()".
2025-07-10 04:59:06 -04:00
if (!(sv = server_find(px, ist0(sv_name)))) {
BUG/MINOR: server/cli: add missing LF at the end of certain notice/error lines Some cli_err(), cli_msg() or even ha_error() etc are missing the trailing LF, which breaks the continuity of the CLI parsing: the extra LF that serves to mark the end of the command is in fact taken as the missing LF and no extra one is added. This patch adds the missing LF on identified messages. It might be worth trying to proceed in a more generic way with this, given the amount of code that is possibly at risk.
2024-02-08 11:43:14 -05:00
cli_err(appctx, "No such server.\n");
MINOR: server: create new function cli_find_server() to find a server Several CLI commands require a server, so let's have a function to look this one up and prepare the appropriate error message and the appctx's state in case of failure.
2016-11-23 11:15:08 -05:00
return NULL;
}
MINOR: proxy: Introduce proxy flags to replace disabled bitfield This change is required to support TCP/HTTP rules in defaults sections. The 'disabled' bitfield in the proxy structure, used to know if a proxy is disabled or stopped, is replaced a generic bitfield named 'flags'. PR_DISABLED and PR_STOPPED flags are renamed to PR_FL_DISABLED and PR_FL_STOPPED respectively. In addition, everywhere there is a test to know if a proxy is disabled or stopped, there is now a bitwise AND operation on PR_FL_DISABLED and/or PR_FL_STOPPED flags.
2021-10-06 08:24:19 -04:00
if (px->flags & (PR_FL_DISABLED|PR_FL_STOPPED)) {
CLEANUP: cli: replace all occurrences of manual handling of return messages There were 221 places where a status message or an error message were built to be returned on the CLI. All of them were replaced to use cli_err(), cli_msg(), cli_dynerr() or cli_dynmsg() depending on what was expected. This removed a lot of duplicated code because most of the times, 4 lines are replaced by a single, safer one.
2019-08-09 05:21:01 -04:00
cli_err(appctx, "Proxy is disabled.\n");
MINOR: server: create new function cli_find_server() to find a server Several CLI commands require a server, so let's have a function to look this one up and prepare the appropriate error message and the appctx's state in case of failure.
2016-11-23 11:15:08 -05:00
return NULL;
}
return sv;
}
MAJOR: server: postpone address resolution Server addresses are not resolved anymore upon the first pass so that we don't fail if an address cannot be resolved by the libc. Instead they are processed all at once after the configuration is fully loaded, by the new function srv_init_addr(). This function only acts on the server's address if this address uses an FQDN, which appears in server->hostname. For now the function does two things, to followup with HAProxy's historical default behavior: 1. apply server IP address found in server-state file if runtime DNS resolution is enabled for this server 2. use the DNS resolver provided by the libc If none of the 2 options above can find an IP address, then an error is returned. All of this will be needed to support the new server parameter "init-addr". For now, the biggest user-visible change is that all server resolution errors are dumped at once instead of causing a startup failure one by one.
2016-11-02 10:34:05 -04:00
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
/* grabs the server lock */
MEDIUM: cli: Add payload support In order to use arbitrary data in the CLI (multiple lines or group of words that must be considered as a whole, for example), it is now possible to add a payload to the commands. To do so, the first line needs to end with a special pattern: <<\n. Everything that follows will be left untouched by the CLI parser and will be passed to the commands parsers. Per-command support will need to be added to take advantage of this feature. Signed-off-by: Aurlien Nephtali <aurelien.nephtali@corp.ovh.com>
2018-04-18 07:26:46 -04:00
static int cli_parse_set_server(char **args, char *payload, struct appctx *appctx, void *private)
REORG: cli: move 'set server' to server.c Move 'set server' CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-18 20:00:33 -05:00
{
struct server *sv;
const char *warning;
if (!cli_has_level(appctx, ACCESS_LVL_ADMIN))
return 1;
sv = cli_find_server(appctx, args[2]);
if (!sv)
return 1;
if (strcmp(args[3], "weight") == 0) {
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
HA_SPIN_LOCK(SERVER_LOCK, &sv->lock);
REORG: cli: move 'set server' to server.c Move 'set server' CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-18 20:00:33 -05:00
warning = server_parse_weight_change_request(sv, args[4]);
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
HA_SPIN_UNLOCK(SERVER_LOCK, &sv->lock);
CLEANUP: cli: replace all occurrences of manual handling of return messages There were 221 places where a status message or an error message were built to be returned on the CLI. All of them were replaced to use cli_err(), cli_msg(), cli_dynerr() or cli_dynmsg() depending on what was expected. This removed a lot of duplicated code because most of the times, 4 lines are replaced by a single, safer one.
2019-08-09 05:21:01 -04:00
if (warning)
cli_err(appctx, warning);
REORG: cli: move 'set server' to server.c Move 'set server' CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-18 20:00:33 -05:00
}
else if (strcmp(args[3], "state") == 0) {
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
HA_SPIN_LOCK(SERVER_LOCK, &sv->lock);
REORG: cli: move 'set server' to server.c Move 'set server' CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-18 20:00:33 -05:00
if (strcmp(args[4], "ready") == 0)
srv_adm_set_ready(sv);
else if (strcmp(args[4], "drain") == 0)
srv_adm_set_drain(sv);
else if (strcmp(args[4], "maint") == 0)
srv_adm_set_maint(sv);
CLEANUP: cli: replace all occurrences of manual handling of return messages There were 221 places where a status message or an error message were built to be returned on the CLI. All of them were replaced to use cli_err(), cli_msg(), cli_dynerr() or cli_dynmsg() depending on what was expected. This removed a lot of duplicated code because most of the times, 4 lines are replaced by a single, safer one.
2019-08-09 05:21:01 -04:00
else
cli_err(appctx, "'set server <srv> state' expects 'ready', 'drain' and 'maint'.\n");
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
HA_SPIN_UNLOCK(SERVER_LOCK, &sv->lock);
REORG: cli: move 'set server' to server.c Move 'set server' CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-18 20:00:33 -05:00
}
else if (strcmp(args[3], "health") == 0) {
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
HA_SPIN_LOCK(SERVER_LOCK, &sv->lock);
CLEANUP: cli: replace all occurrences of manual handling of return messages There were 221 places where a status message or an error message were built to be returned on the CLI. All of them were replaced to use cli_err(), cli_msg(), cli_dynerr() or cli_dynmsg() depending on what was expected. This removed a lot of duplicated code because most of the times, 4 lines are replaced by a single, safer one.
2019-08-09 05:21:01 -04:00
if (sv->track)
cli_err(appctx, "cannot change health on a tracking server.\n");
REORG: cli: move 'set server' to server.c Move 'set server' CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-18 20:00:33 -05:00
else if (strcmp(args[4], "up") == 0) {
sv->check.health = sv->check.rise + sv->check.fall - 1;
MINOR: server: change srv_op_st_chg_cause storage type This one is greatly inspired by "MINOR: server: change adm_st_chg_cause storage type". While looking at current srv_op_st_chg_cause usage, it was clear that the struct needed some cleanup since some leftovers from asynchronous server state change updates were left behind and resulted in some useless code duplication, and making the whole thing harder to maintain. Two observations were made: - by tracking down srv_set_{running, stopped, stopping} usage, we can see that the <reason> argument is always a fixed statically allocated string. - check-related state change context (duration, status, code...) is not used anymore since srv_append_status() directly extracts the values from the server->check. This is pure legacy from when the state changes were applied asynchronously. To prevent code duplication, useless string copies and make the reason/cause more exportable, we store it as an enum now, and we provide srv_op_st_chg_cause() function to fetch the related description string. HEALTH and AGENT causes (check related) are now explicitly identified to make consumers like srv_append_op_chg_cause() able to fetch checks info from the server itself if they need to.
2023-04-04 04:17:40 -04:00
srv_set_running(sv, SRV_OP_STCHGC_CLI);
REORG: cli: move 'set server' to server.c Move 'set server' CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-18 20:00:33 -05:00
}
else if (strcmp(args[4], "stopping") == 0) {
sv->check.health = sv->check.rise + sv->check.fall - 1;
MINOR: server: change srv_op_st_chg_cause storage type This one is greatly inspired by "MINOR: server: change adm_st_chg_cause storage type". While looking at current srv_op_st_chg_cause usage, it was clear that the struct needed some cleanup since some leftovers from asynchronous server state change updates were left behind and resulted in some useless code duplication, and making the whole thing harder to maintain. Two observations were made: - by tracking down srv_set_{running, stopped, stopping} usage, we can see that the <reason> argument is always a fixed statically allocated string. - check-related state change context (duration, status, code...) is not used anymore since srv_append_status() directly extracts the values from the server->check. This is pure legacy from when the state changes were applied asynchronously. To prevent code duplication, useless string copies and make the reason/cause more exportable, we store it as an enum now, and we provide srv_op_st_chg_cause() function to fetch the related description string. HEALTH and AGENT causes (check related) are now explicitly identified to make consumers like srv_append_op_chg_cause() able to fetch checks info from the server itself if they need to.
2023-04-04 04:17:40 -04:00
srv_set_stopping(sv, SRV_OP_STCHGC_CLI);
REORG: cli: move 'set server' to server.c Move 'set server' CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-18 20:00:33 -05:00
}
else if (strcmp(args[4], "down") == 0) {
sv->check.health = 0;
MINOR: server: change srv_op_st_chg_cause storage type This one is greatly inspired by "MINOR: server: change adm_st_chg_cause storage type". While looking at current srv_op_st_chg_cause usage, it was clear that the struct needed some cleanup since some leftovers from asynchronous server state change updates were left behind and resulted in some useless code duplication, and making the whole thing harder to maintain. Two observations were made: - by tracking down srv_set_{running, stopped, stopping} usage, we can see that the <reason> argument is always a fixed statically allocated string. - check-related state change context (duration, status, code...) is not used anymore since srv_append_status() directly extracts the values from the server->check. This is pure legacy from when the state changes were applied asynchronously. To prevent code duplication, useless string copies and make the reason/cause more exportable, we store it as an enum now, and we provide srv_op_st_chg_cause() function to fetch the related description string. HEALTH and AGENT causes (check related) are now explicitly identified to make consumers like srv_append_op_chg_cause() able to fetch checks info from the server itself if they need to.
2023-04-04 04:17:40 -04:00
srv_set_stopped(sv, SRV_OP_STCHGC_CLI);
REORG: cli: move 'set server' to server.c Move 'set server' CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-18 20:00:33 -05:00
}
CLEANUP: cli: replace all occurrences of manual handling of return messages There were 221 places where a status message or an error message were built to be returned on the CLI. All of them were replaced to use cli_err(), cli_msg(), cli_dynerr() or cli_dynmsg() depending on what was expected. This removed a lot of duplicated code because most of the times, 4 lines are replaced by a single, safer one.
2019-08-09 05:21:01 -04:00
else
cli_err(appctx, "'set server <srv> health' expects 'up', 'stopping', or 'down'.\n");
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
HA_SPIN_UNLOCK(SERVER_LOCK, &sv->lock);
REORG: cli: move 'set server' to server.c Move 'set server' CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-18 20:00:33 -05:00
}
else if (strcmp(args[3], "agent") == 0) {
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
HA_SPIN_LOCK(SERVER_LOCK, &sv->lock);
CLEANUP: cli: replace all occurrences of manual handling of return messages There were 221 places where a status message or an error message were built to be returned on the CLI. All of them were replaced to use cli_err(), cli_msg(), cli_dynerr() or cli_dynmsg() depending on what was expected. This removed a lot of duplicated code because most of the times, 4 lines are replaced by a single, safer one.
2019-08-09 05:21:01 -04:00
if (!(sv->agent.state & CHK_ST_ENABLED))
cli_err(appctx, "agent checks are not enabled on this server.\n");
REORG: cli: move 'set server' to server.c Move 'set server' CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-18 20:00:33 -05:00
else if (strcmp(args[4], "up") == 0) {
sv->agent.health = sv->agent.rise + sv->agent.fall - 1;
MINOR: server: change srv_op_st_chg_cause storage type This one is greatly inspired by "MINOR: server: change adm_st_chg_cause storage type". While looking at current srv_op_st_chg_cause usage, it was clear that the struct needed some cleanup since some leftovers from asynchronous server state change updates were left behind and resulted in some useless code duplication, and making the whole thing harder to maintain. Two observations were made: - by tracking down srv_set_{running, stopped, stopping} usage, we can see that the <reason> argument is always a fixed statically allocated string. - check-related state change context (duration, status, code...) is not used anymore since srv_append_status() directly extracts the values from the server->check. This is pure legacy from when the state changes were applied asynchronously. To prevent code duplication, useless string copies and make the reason/cause more exportable, we store it as an enum now, and we provide srv_op_st_chg_cause() function to fetch the related description string. HEALTH and AGENT causes (check related) are now explicitly identified to make consumers like srv_append_op_chg_cause() able to fetch checks info from the server itself if they need to.
2023-04-04 04:17:40 -04:00
srv_set_running(sv, SRV_OP_STCHGC_CLI);
REORG: cli: move 'set server' to server.c Move 'set server' CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-18 20:00:33 -05:00
}
else if (strcmp(args[4], "down") == 0) {
sv->agent.health = 0;
MINOR: server: change srv_op_st_chg_cause storage type This one is greatly inspired by "MINOR: server: change adm_st_chg_cause storage type". While looking at current srv_op_st_chg_cause usage, it was clear that the struct needed some cleanup since some leftovers from asynchronous server state change updates were left behind and resulted in some useless code duplication, and making the whole thing harder to maintain. Two observations were made: - by tracking down srv_set_{running, stopped, stopping} usage, we can see that the <reason> argument is always a fixed statically allocated string. - check-related state change context (duration, status, code...) is not used anymore since srv_append_status() directly extracts the values from the server->check. This is pure legacy from when the state changes were applied asynchronously. To prevent code duplication, useless string copies and make the reason/cause more exportable, we store it as an enum now, and we provide srv_op_st_chg_cause() function to fetch the related description string. HEALTH and AGENT causes (check related) are now explicitly identified to make consumers like srv_append_op_chg_cause() able to fetch checks info from the server itself if they need to.
2023-04-04 04:17:40 -04:00
srv_set_stopped(sv, SRV_OP_STCHGC_CLI);
REORG: cli: move 'set server' to server.c Move 'set server' CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-18 20:00:33 -05:00
}
CLEANUP: cli: replace all occurrences of manual handling of return messages There were 221 places where a status message or an error message were built to be returned on the CLI. All of them were replaced to use cli_err(), cli_msg(), cli_dynerr() or cli_dynmsg() depending on what was expected. This removed a lot of duplicated code because most of the times, 4 lines are replaced by a single, safer one.
2019-08-09 05:21:01 -04:00
else
cli_err(appctx, "'set server <srv> agent' expects 'up' or 'down'.\n");
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
HA_SPIN_UNLOCK(SERVER_LOCK, &sv->lock);
REORG: cli: move 'set server' to server.c Move 'set server' CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-18 20:00:33 -05:00
}
MINOR: cli: Add possiblity to change agent config via CLI/socket This change adds possibility to change agent-addr and agent-send directives by CLI/socket. Now you can replace server's and their configuration without reloading/restarting whole haproxy, so it's a step in no-reload/no-restart direction. Depends on #e9602af - agent-addr is implemented there. Can be backported to 1.7.
2017-01-09 03:40:42 -05:00
else if (strcmp(args[3], "agent-addr") == 0) {
MEDIUM: cli: add agent-port command this patch allows to set agent port at runtime. In order to align with both `addr` and `check-addr` commands, also add the possibility to optionnaly set port on `agent-addr` command. This led to a small refactor in order to use the same function for both `agent-addr` and `agent-port` commands. Signed-off-by: William Dauchy <wdauchy@gmail.com>
2021-02-11 16:51:24 -05:00
char *addr = NULL;
char *port = NULL;
if (strlen(args[4]) == 0) {
cli_err(appctx, "set server <b>/<s> agent-addr requires"
" an address and optionally a port.\n");
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
goto out;
MEDIUM: cli: add agent-port command this patch allows to set agent port at runtime. In order to align with both `addr` and `check-addr` commands, also add the possibility to optionnaly set port on `agent-addr` command. This led to a small refactor in order to use the same function for both `agent-addr` and `agent-port` commands. Signed-off-by: William Dauchy <wdauchy@gmail.com>
2021-02-11 16:51:24 -05:00
}
addr = args[4];
if (strcmp(args[5], "port") == 0)
port = args[6];
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
HA_SPIN_LOCK(SERVER_LOCK, &sv->lock);
REORG: server: Export and rename some functions updating server info Some static functions are now exported and renamed to follow the same pattern of other exported functions. Here is the list : * update_server_fqdn: Renamed to srv_update_fqdn and exported * update_server_check_addr_port: renamed to srv_update_check_addr_port and exported * update_server_agent_addr_port: renamed to srv_update_agent_addr_port and exported * update_server_addr: renamed to srv_update_addr * update_server_addr_potr: renamed to srv_update_addr_port * srv_prepare_for_resolution: exported This change is mandatory to move all functions dealing with the server-state files in a separate file.
2021-02-16 06:07:47 -05:00
warning = srv_update_agent_addr_port(sv, addr, port);
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
HA_SPIN_UNLOCK(SERVER_LOCK, &sv->lock);
MEDIUM: cli: add agent-port command this patch allows to set agent port at runtime. In order to align with both `addr` and `check-addr` commands, also add the possibility to optionnaly set port on `agent-addr` command. This led to a small refactor in order to use the same function for both `agent-addr` and `agent-port` commands. Signed-off-by: William Dauchy <wdauchy@gmail.com>
2021-02-11 16:51:24 -05:00
if (warning)
cli_msg(appctx, LOG_WARNING, warning);
}
else if (strcmp(args[3], "agent-port") == 0) {
char *port = NULL;
if (strlen(args[4]) == 0) {
cli_err(appctx, "set server <b>/<s> agent-port requires"
" a port.\n");
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
goto out;
MEDIUM: cli: add agent-port command this patch allows to set agent port at runtime. In order to align with both `addr` and `check-addr` commands, also add the possibility to optionnaly set port on `agent-addr` command. This led to a small refactor in order to use the same function for both `agent-addr` and `agent-port` commands. Signed-off-by: William Dauchy <wdauchy@gmail.com>
2021-02-11 16:51:24 -05:00
}
port = args[4];
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
HA_SPIN_LOCK(SERVER_LOCK, &sv->lock);
REORG: server: Export and rename some functions updating server info Some static functions are now exported and renamed to follow the same pattern of other exported functions. Here is the list : * update_server_fqdn: Renamed to srv_update_fqdn and exported * update_server_check_addr_port: renamed to srv_update_check_addr_port and exported * update_server_agent_addr_port: renamed to srv_update_agent_addr_port and exported * update_server_addr: renamed to srv_update_addr * update_server_addr_potr: renamed to srv_update_addr_port * srv_prepare_for_resolution: exported This change is mandatory to move all functions dealing with the server-state files in a separate file.
2021-02-16 06:07:47 -05:00
warning = srv_update_agent_addr_port(sv, NULL, port);
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
HA_SPIN_UNLOCK(SERVER_LOCK, &sv->lock);
MEDIUM: cli: add agent-port command this patch allows to set agent port at runtime. In order to align with both `addr` and `check-addr` commands, also add the possibility to optionnaly set port on `agent-addr` command. This led to a small refactor in order to use the same function for both `agent-addr` and `agent-port` commands. Signed-off-by: William Dauchy <wdauchy@gmail.com>
2021-02-11 16:51:24 -05:00
if (warning)
cli_msg(appctx, LOG_WARNING, warning);
MINOR: cli: Add possiblity to change agent config via CLI/socket This change adds possibility to change agent-addr and agent-send directives by CLI/socket. Now you can replace server's and their configuration without reloading/restarting whole haproxy, so it's a step in no-reload/no-restart direction. Depends on #e9602af - agent-addr is implemented there. Can be backported to 1.7.
2017-01-09 03:40:42 -05:00
}
else if (strcmp(args[3], "agent-send") == 0) {
BUG/MINOR: server/cli: Fix locking in function processing "set server" command The commit c7b391aed ("BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI") introduced 2 bugs. The first one is a typo on the server's lock label (s/SERVER_UNLOCK/SERVER_LOCK/). The second one is about the server's lock itself. It must be acquired to execute the "agent-send" subcommand. The patch above is marked to be backported as far as 1.8. Thus, this one must also backported as far 1.8. BUG/MINOR: server/cli: Don't forget to lock server on agent-send subcommand
2021-06-18 02:47:14 -04:00
HA_SPIN_LOCK(SERVER_LOCK, &sv->lock);
CLEANUP: cli: replace all occurrences of manual handling of return messages There were 221 places where a status message or an error message were built to be returned on the CLI. All of them were replaced to use cli_err(), cli_msg(), cli_dynerr() or cli_dynmsg() depending on what was expected. This removed a lot of duplicated code because most of the times, 4 lines are replaced by a single, safer one.
2019-08-09 05:21:01 -04:00
if (!(sv->agent.state & CHK_ST_ENABLED))
cli_err(appctx, "agent checks are not enabled on this server.\n");
else {
MEDIUM: checks: Implement agent check using tcp-check rules A shared tcp-check ruleset is now created to support agent checks. The following sequence is used : tcp-check send "%[var(check.agent_string)] log-format tcp-check expect custom The custom function to evaluate the expect rule does the same that it was done to handle agent response when a custom check was used.
2020-04-06 11:54:24 -04:00
if (!set_srv_agent_send(sv, args[4]))
CLEANUP: cli: replace all occurrences of manual handling of return messages There were 221 places where a status message or an error message were built to be returned on the CLI. All of them were replaced to use cli_err(), cli_msg(), cli_dynerr() or cli_dynmsg() depending on what was expected. This removed a lot of duplicated code because most of the times, 4 lines are replaced by a single, safer one.
2019-08-09 05:21:01 -04:00
cli_err(appctx, "cannot allocate memory for new string.\n");
MINOR: cli: Add possiblity to change agent config via CLI/socket This change adds possibility to change agent-addr and agent-send directives by CLI/socket. Now you can replace server's and their configuration without reloading/restarting whole haproxy, so it's a step in no-reload/no-restart direction. Depends on #e9602af - agent-addr is implemented there. Can be backported to 1.7.
2017-01-09 03:40:42 -05:00
}
BUG/MINOR: server/cli: Fix locking in function processing "set server" command The commit c7b391aed ("BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI") introduced 2 bugs. The first one is a typo on the server's lock label (s/SERVER_UNLOCK/SERVER_LOCK/). The second one is about the server's lock itself. It must be acquired to execute the "agent-send" subcommand. The patch above is marked to be backported as far as 1.8. Thus, this one must also backported as far 1.8. BUG/MINOR: server/cli: Don't forget to lock server on agent-send subcommand
2021-06-18 02:47:14 -04:00
HA_SPIN_UNLOCK(SERVER_LOCK, &sv->lock);
MINOR: cli: Add possiblity to change agent config via CLI/socket This change adds possibility to change agent-addr and agent-send directives by CLI/socket. Now you can replace server's and their configuration without reloading/restarting whole haproxy, so it's a step in no-reload/no-restart direction. Depends on #e9602af - agent-addr is implemented there. Can be backported to 1.7.
2017-01-09 03:40:42 -05:00
}
MEDIUM: cli: add check-addr command this patch allows to set server health check address at runtime. In order to align with `addr` command, also allow to set port optionnaly. This led to a small refactor in order to use the same function for both `check-addr` and `check-port` commands. for `check-port`, we however don't permit the change anymore if checks are not enabled on the server. This command becomes more and more useful for people having a consul like architecture: - the backend server is located on a container with its own IP - the health checks are done the consul instance located on the host with the host IP Signed-off-by: William Dauchy <wdauchy@gmail.com>
2021-02-11 16:51:23 -05:00
else if (strcmp(args[3], "check-addr") == 0) {
char *addr = NULL;
char *port = NULL;
if (strlen(args[4]) == 0) {
cli_err(appctx, "set server <b>/<s> check-addr requires"
" an address and optionally a port.\n");
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
goto out;
REORG: cli: move 'set server' to server.c Move 'set server' CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-18 20:00:33 -05:00
}
MEDIUM: cli: add check-addr command this patch allows to set server health check address at runtime. In order to align with `addr` command, also allow to set port optionnaly. This led to a small refactor in order to use the same function for both `check-addr` and `check-port` commands. for `check-port`, we however don't permit the change anymore if checks are not enabled on the server. This command becomes more and more useful for people having a consul like architecture: - the backend server is located on a container with its own IP - the health checks are done the consul instance located on the host with the host IP Signed-off-by: William Dauchy <wdauchy@gmail.com>
2021-02-11 16:51:23 -05:00
addr = args[4];
if (strcmp(args[5], "port") == 0)
port = args[6];
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
HA_SPIN_LOCK(SERVER_LOCK, &sv->lock);
REORG: server: Export and rename some functions updating server info Some static functions are now exported and renamed to follow the same pattern of other exported functions. Here is the list : * update_server_fqdn: Renamed to srv_update_fqdn and exported * update_server_check_addr_port: renamed to srv_update_check_addr_port and exported * update_server_agent_addr_port: renamed to srv_update_agent_addr_port and exported * update_server_addr: renamed to srv_update_addr * update_server_addr_potr: renamed to srv_update_addr_port * srv_prepare_for_resolution: exported This change is mandatory to move all functions dealing with the server-state files in a separate file.
2021-02-16 06:07:47 -05:00
warning = srv_update_check_addr_port(sv, addr, port);
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
HA_SPIN_UNLOCK(SERVER_LOCK, &sv->lock);
MEDIUM: cli: add check-addr command this patch allows to set server health check address at runtime. In order to align with `addr` command, also allow to set port optionnaly. This led to a small refactor in order to use the same function for both `check-addr` and `check-port` commands. for `check-port`, we however don't permit the change anymore if checks are not enabled on the server. This command becomes more and more useful for people having a consul like architecture: - the backend server is located on a container with its own IP - the health checks are done the consul instance located on the host with the host IP Signed-off-by: William Dauchy <wdauchy@gmail.com>
2021-02-11 16:51:23 -05:00
if (warning)
cli_msg(appctx, LOG_WARNING, warning);
}
else if (strcmp(args[3], "check-port") == 0) {
char *port = NULL;
if (strlen(args[4]) == 0) {
cli_err(appctx, "set server <b>/<s> check-port requires"
" a port.\n");
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
goto out;
REORG: cli: move 'set server' to server.c Move 'set server' CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-18 20:00:33 -05:00
}
MEDIUM: cli: add check-addr command this patch allows to set server health check address at runtime. In order to align with `addr` command, also allow to set port optionnaly. This led to a small refactor in order to use the same function for both `check-addr` and `check-port` commands. for `check-port`, we however don't permit the change anymore if checks are not enabled on the server. This command becomes more and more useful for people having a consul like architecture: - the backend server is located on a container with its own IP - the health checks are done the consul instance located on the host with the host IP Signed-off-by: William Dauchy <wdauchy@gmail.com>
2021-02-11 16:51:23 -05:00
port = args[4];
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
HA_SPIN_LOCK(SERVER_LOCK, &sv->lock);
REORG: server: Export and rename some functions updating server info Some static functions are now exported and renamed to follow the same pattern of other exported functions. Here is the list : * update_server_fqdn: Renamed to srv_update_fqdn and exported * update_server_check_addr_port: renamed to srv_update_check_addr_port and exported * update_server_agent_addr_port: renamed to srv_update_agent_addr_port and exported * update_server_addr: renamed to srv_update_addr * update_server_addr_potr: renamed to srv_update_addr_port * srv_prepare_for_resolution: exported This change is mandatory to move all functions dealing with the server-state files in a separate file.
2021-02-16 06:07:47 -05:00
warning = srv_update_check_addr_port(sv, NULL, port);
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
HA_SPIN_UNLOCK(SERVER_LOCK, &sv->lock);
MEDIUM: cli: add check-addr command this patch allows to set server health check address at runtime. In order to align with `addr` command, also allow to set port optionnaly. This led to a small refactor in order to use the same function for both `check-addr` and `check-port` commands. for `check-port`, we however don't permit the change anymore if checks are not enabled on the server. This command becomes more and more useful for people having a consul like architecture: - the backend server is located on a container with its own IP - the health checks are done the consul instance located on the host with the host IP Signed-off-by: William Dauchy <wdauchy@gmail.com>
2021-02-11 16:51:23 -05:00
if (warning)
cli_msg(appctx, LOG_WARNING, warning);
REORG: cli: move 'set server' to server.c Move 'set server' CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-18 20:00:33 -05:00
}
else if (strcmp(args[3], "addr") == 0) {
char *addr = NULL;
char *port = NULL;
if (strlen(args[4]) == 0) {
CLEANUP: cli: replace all occurrences of manual handling of return messages There were 221 places where a status message or an error message were built to be returned on the CLI. All of them were replaced to use cli_err(), cli_msg(), cli_dynerr() or cli_dynmsg() depending on what was expected. This removed a lot of duplicated code because most of the times, 4 lines are replaced by a single, safer one.
2019-08-09 05:21:01 -04:00
cli_err(appctx, "set server <b>/<s> addr requires an address and optionally a port.\n");
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
goto out;
REORG: cli: move 'set server' to server.c Move 'set server' CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-18 20:00:33 -05:00
}
else {
addr = args[4];
}
if (strcmp(args[5], "port") == 0) {
port = args[6];
}
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
HA_SPIN_LOCK(SERVER_LOCK, &sv->lock);
MEDIUM: server: make server_set_inetaddr() updater serializable server_set_inetaddr() updater argument is a simple char * string containing infos about the caller responsible for the update. In this patch, we try to make this argument serializable, that is, make it so that we can easily export it without having to keep the original pointer passed by the caller or having to work with strings of variable lengths. This was a prerequisite for exposing more updater information through SERVER_INETADDR event (upcoming patch). Static strings were simply mapped to a fixed ID that can be converted back to a string when needed using server_inetaddr_updater_by_to_str(). One special case one made for the SERVER_INETADDR_UPDATER_DNS_RESOLVER updater since in this case the updater hint has to be generated from the corresponding resolver id / nameserver id combination. This was achieved by saving the nameserver id within the updater struct. Knowing that the resolver id can be guessed from the server struct directly, it was not exposed through the updater struct. This patch depends on: - "MINOR: resolvers: add unique numeric id to nameservers" No functional change should be expected.
2023-12-11 09:06:43 -05:00
warning = srv_update_addr_port(sv, addr, port, SERVER_INETADDR_UPDATER_CLI);
CLEANUP: cli: replace all occurrences of manual handling of return messages There were 221 places where a status message or an error message were built to be returned on the CLI. All of them were replaced to use cli_err(), cli_msg(), cli_dynerr() or cli_dynmsg() depending on what was expected. This removed a lot of duplicated code because most of the times, 4 lines are replaced by a single, safer one.
2019-08-09 05:21:01 -04:00
if (warning)
cli_msg(appctx, LOG_WARNING, warning);
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
HA_SPIN_UNLOCK(SERVER_LOCK, &sv->lock);
REORG: cli: move 'set server' to server.c Move 'set server' CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-18 20:00:33 -05:00
}
MINOR: server: cli: Add server FQDNs to server-state file and stats socket. This patch adds a new stats socket command to modify server FQDNs at run time. Its syntax: set server <backend>/<server> fqdn <FQDN> This patch also adds FQDNs to server state file at the end of each line for backward compatibility ("-" if not present).
2017-04-26 05:24:02 -04:00
else if (strcmp(args[3], "fqdn") == 0) {
if (!*args[4]) {
CLEANUP: cli: replace all occurrences of manual handling of return messages There were 221 places where a status message or an error message were built to be returned on the CLI. All of them were replaced to use cli_err(), cli_msg(), cli_dynerr() or cli_dynmsg() depending on what was expected. This removed a lot of duplicated code because most of the times, 4 lines are replaced by a single, safer one.
2019-08-09 05:21:01 -04:00
cli_err(appctx, "set server <b>/<s> fqdn requires a FQDN.\n");
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
goto out;
}
if (!sv->resolvers) {
cli_err(appctx, "set server <b>/<s> fqdn failed because no resolution is configured.\n");
goto out;
MINOR: server: cli: Add server FQDNs to server-state file and stats socket. This patch adds a new stats socket command to modify server FQDNs at run time. Its syntax: set server <backend>/<server> fqdn <FQDN> This patch also adds FQDNs to server state file at the end of each line for backward compatibility ("-" if not present).
2017-04-26 05:24:02 -04:00
}
BUG/MINOR: server: Forbid to set fqdn on the CLI if SRV resolution is enabled If a server is configured to rely on a SRV resolution, we must forbid to change its fqdn on the CLI. Indeed, in this case, the server retrieves its fqdn from the SRV resolution. If the fqdn is changed via the CLI, this conflicts with the SRV resolution and leaves the server in an undefined state. Most of time, the SRV resolution remains enabled with no effect on the server (no update). Some time the A/AAAA resolution for the new fqdn is not enabled at all. It depends on the server state and resolver state when the CLI command is executed. This patch must be backported as far as 2.0 (maybe to 1.8 too ?) after some observation period.
2021-06-15 05:37:40 -04:00
if (sv->srvrq) {
cli_err(appctx, "set server <b>/<s> fqdn failed because SRV resolution is configured.\n");
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
goto out;
BUG/MINOR: server: Forbid to set fqdn on the CLI if SRV resolution is enabled If a server is configured to rely on a SRV resolution, we must forbid to change its fqdn on the CLI. Indeed, in this case, the server retrieves its fqdn from the SRV resolution. If the fqdn is changed via the CLI, this conflicts with the SRV resolution and leaves the server in an undefined state. Most of time, the SRV resolution remains enabled with no effect on the server (no update). Some time the A/AAAA resolution for the new fqdn is not enabled at all. It depends on the server state and resolver state when the CLI command is executed. This patch must be backported as far as 2.0 (maybe to 1.8 too ?) after some observation period.
2021-06-15 05:37:40 -04:00
}
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
HA_SPIN_LOCK(DNS_LOCK, &sv->resolvers->lock);
HA_SPIN_LOCK(SERVER_LOCK, &sv->lock);
MEDIUM: dns: use Additional records from SRV responses Most DNS servers provide A/AAAA records in the Additional section of a response, which correspond to the SRV records from the Answer section: ;; QUESTION SECTION: ;_http._tcp.be1.domain.tld. IN SRV ;; ANSWER SECTION: _http._tcp.be1.domain.tld. 3600 IN SRV 5 500 80 A1.domain.tld. _http._tcp.be1.domain.tld. 3600 IN SRV 5 500 80 A8.domain.tld. _http._tcp.be1.domain.tld. 3600 IN SRV 5 500 80 A5.domain.tld. _http._tcp.be1.domain.tld. 3600 IN SRV 5 500 80 A6.domain.tld. _http._tcp.be1.domain.tld. 3600 IN SRV 5 500 80 A4.domain.tld. _http._tcp.be1.domain.tld. 3600 IN SRV 5 500 80 A3.domain.tld. _http._tcp.be1.domain.tld. 3600 IN SRV 5 500 80 A2.domain.tld. _http._tcp.be1.domain.tld. 3600 IN SRV 5 500 80 A7.domain.tld. ;; ADDITIONAL SECTION: A1.domain.tld. 3600 IN A 192.168.0.1 A8.domain.tld. 3600 IN A 192.168.0.8 A5.domain.tld. 3600 IN A 192.168.0.5 A6.domain.tld. 3600 IN A 192.168.0.6 A4.domain.tld. 3600 IN A 192.168.0.4 A3.domain.tld. 3600 IN A 192.168.0.3 A2.domain.tld. 3600 IN A 192.168.0.2 A7.domain.tld. 3600 IN A 192.168.0.7 SRV record support was introduced in HAProxy 1.8 and the first design did not take into account the records from the Additional section. Instead, a new resolution is associated to each server with its relevant FQDN. This behavior generates a lot of DNS requests (1 SRV + 1 per server associated). This patch aims at fixing this by: - when a DNS response is validated, we associate A/AAAA records to relevant SRV ones - set a flag on associated servers to prevent them from running a DNS resolution for said FADN - update server IP address with information found in the Additional section If no relevant record can be found in the Additional section, then HAProxy will failback to running a dedicated resolution for this server, as it used to do. This behavior is the one described in RFC 2782.
2019-06-07 03:40:55 -04:00
/* ensure runtime resolver will process this new fqdn */
if (sv->flags & SRV_F_NO_RESOLUTION) {
sv->flags &= ~SRV_F_NO_RESOLUTION;
}
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
warning = srv_update_fqdn(sv, args[4], "stats socket command", 1);
BUG/MINOR: server/cli: Fix locking in function processing "set server" command The commit c7b391aed ("BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI") introduced 2 bugs. The first one is a typo on the server's lock label (s/SERVER_UNLOCK/SERVER_LOCK/). The second one is about the server's lock itself. It must be acquired to execute the "agent-send" subcommand. The patch above is marked to be backported as far as 1.8. Thus, this one must also backported as far 1.8. BUG/MINOR: server/cli: Don't forget to lock server on agent-send subcommand
2021-06-18 02:47:14 -04:00
HA_SPIN_UNLOCK(SERVER_LOCK, &sv->lock);
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
HA_SPIN_UNLOCK(DNS_LOCK, &sv->resolvers->lock);
CLEANUP: cli: replace all occurrences of manual handling of return messages There were 221 places where a status message or an error message were built to be returned on the CLI. All of them were replaced to use cli_err(), cli_msg(), cli_dynerr() or cli_dynmsg() depending on what was expected. This removed a lot of duplicated code because most of the times, 4 lines are replaced by a single, safer one.
2019-08-09 05:21:01 -04:00
if (warning)
cli_msg(appctx, LOG_WARNING, warning);
MINOR: server: cli: Add server FQDNs to server-state file and stats socket. This patch adds a new stats socket command to modify server FQDNs at run time. Its syntax: set server <backend>/<server> fqdn <FQDN> This patch also adds FQDNs to server state file at the end of each line for backward compatibility ("-" if not present).
2017-04-26 05:24:02 -04:00
}
MEDIUM: cli/ssl: configure ssl on server at runtime in the context of a progressive backend migration, we want to be able to activate SSL on outgoing connections to the server at runtime without reloading. This patch adds a `set server ssl` command; in order to allow that: - add `srv_use_ssl` to `show servers state` command for compatibility, also update associated parsing - when using default-server ssl setting, and `no-ssl` on server line, init SSL ctx without activating it - when triggering ssl API, de/activate SSL connections as requested - clean ongoing connections as it is done for addr/port changes, without checking prior server state example config: backend be_foo default-server ssl server srv0 127.0.0.1:6011 weight 1 no-ssl show servers state: 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - -1 where srv0 can switch to ssl later during the runtime: set server be_foo/srv0 ssl on 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - 1 Also update existing tests and create a new one. Signed-off-by: William Dauchy <wdauchy@gmail.com>
2020-11-14 13:25:33 -05:00
else if (strcmp(args[3], "ssl") == 0) {
#ifdef USE_OPENSSL
BUG/MEDIUM: server: Use sni as pool connection name for SSL server only By default, for a given server, when no pool-conn-name is specified, the configured sni is used. However, this must only be done when SSL is in-use for the server. Of course, it is uncommon to have a sni expression for now-ssl server. But this may happen. In addition, the SSL may be disabled via the CLI. In that case, the pool-conn-name must be discarded if it was copied from the sni. And, we must of course take care to set it if the ssl is enabled. Finally, when the attac-srv action is checked, we now checked the pool-conn-name expression. This patch should be backported as far as 3.0. It relies on "MINOR: server: Parse sni and pool-conn-name expressions in a dedicated function" which should be backported too.
2025-09-03 09:29:56 -04:00
char *err = NULL;
MINOR: server: disable CLI 'set server ssl' for dynamic servers 'set server ssl' uses ssl parameters from default-server. As dynamic servers does not reuse any default-server parameters, this command has no sense for them.
2021-05-19 09:00:54 -04:00
if (sv->flags & SRV_F_DYNAMIC) {
cli_err(appctx, "'set server <srv> ssl' not supported on dynamic servers\n");
goto out;
}
MEDIUM: cli/ssl: configure ssl on server at runtime in the context of a progressive backend migration, we want to be able to activate SSL on outgoing connections to the server at runtime without reloading. This patch adds a `set server ssl` command; in order to allow that: - add `srv_use_ssl` to `show servers state` command for compatibility, also update associated parsing - when using default-server ssl setting, and `no-ssl` on server line, init SSL ctx without activating it - when triggering ssl API, de/activate SSL connections as requested - clean ongoing connections as it is done for addr/port changes, without checking prior server state example config: backend be_foo default-server ssl server srv0 127.0.0.1:6011 weight 1 no-ssl show servers state: 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - -1 where srv0 can switch to ssl later during the runtime: set server be_foo/srv0 ssl on 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - 1 Also update existing tests and create a new one. Signed-off-by: William Dauchy <wdauchy@gmail.com>
2020-11-14 13:25:33 -05:00
if (sv->ssl_ctx.ctx == NULL) {
cli_err(appctx, "'set server <srv> ssl' cannot be set. "
" default-server should define ssl settings\n");
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
goto out;
}
HA_SPIN_LOCK(SERVER_LOCK, &sv->lock);
if (strcmp(args[4], "on") == 0) {
BUG/MEDIUM: server: Use sni as pool connection name for SSL server only By default, for a given server, when no pool-conn-name is specified, the configured sni is used. However, this must only be done when SSL is in-use for the server. Of course, it is uncommon to have a sni expression for now-ssl server. But this may happen. In addition, the SSL may be disabled via the CLI. In that case, the pool-conn-name must be discarded if it was copied from the sni. And, we must of course take care to set it if the ssl is enabled. Finally, when the attac-srv action is checked, we now checked the pool-conn-name expression. This patch should be backported as far as 3.0. It relies on "MINOR: server: Parse sni and pool-conn-name expressions in a dedicated function" which should be backported too.
2025-09-03 09:29:56 -04:00
if (srv_set_ssl(sv, 1)) {
cli_dynerr(appctx, memprintf(&err, "failed to enable ssl for server %s.\n", args[2]));
goto out;
}
MEDIUM: cli/ssl: configure ssl on server at runtime in the context of a progressive backend migration, we want to be able to activate SSL on outgoing connections to the server at runtime without reloading. This patch adds a `set server ssl` command; in order to allow that: - add `srv_use_ssl` to `show servers state` command for compatibility, also update associated parsing - when using default-server ssl setting, and `no-ssl` on server line, init SSL ctx without activating it - when triggering ssl API, de/activate SSL connections as requested - clean ongoing connections as it is done for addr/port changes, without checking prior server state example config: backend be_foo default-server ssl server srv0 127.0.0.1:6011 weight 1 no-ssl show servers state: 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - -1 where srv0 can switch to ssl later during the runtime: set server be_foo/srv0 ssl on 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - 1 Also update existing tests and create a new one. Signed-off-by: William Dauchy <wdauchy@gmail.com>
2020-11-14 13:25:33 -05:00
} else if (strcmp(args[4], "off") == 0) {
BUG/MEDIUM: server: Use sni as pool connection name for SSL server only By default, for a given server, when no pool-conn-name is specified, the configured sni is used. However, this must only be done when SSL is in-use for the server. Of course, it is uncommon to have a sni expression for now-ssl server. But this may happen. In addition, the SSL may be disabled via the CLI. In that case, the pool-conn-name must be discarded if it was copied from the sni. And, we must of course take care to set it if the ssl is enabled. Finally, when the attac-srv action is checked, we now checked the pool-conn-name expression. This patch should be backported as far as 3.0. It relies on "MINOR: server: Parse sni and pool-conn-name expressions in a dedicated function" which should be backported too.
2025-09-03 09:29:56 -04:00
if (srv_set_ssl(sv, 0)) {
cli_dynerr(appctx, memprintf(&err, "failed to disable ssl for server %s.\n", args[2]));
goto out;
}
MEDIUM: cli/ssl: configure ssl on server at runtime in the context of a progressive backend migration, we want to be able to activate SSL on outgoing connections to the server at runtime without reloading. This patch adds a `set server ssl` command; in order to allow that: - add `srv_use_ssl` to `show servers state` command for compatibility, also update associated parsing - when using default-server ssl setting, and `no-ssl` on server line, init SSL ctx without activating it - when triggering ssl API, de/activate SSL connections as requested - clean ongoing connections as it is done for addr/port changes, without checking prior server state example config: backend be_foo default-server ssl server srv0 127.0.0.1:6011 weight 1 no-ssl show servers state: 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - -1 where srv0 can switch to ssl later during the runtime: set server be_foo/srv0 ssl on 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - 1 Also update existing tests and create a new one. Signed-off-by: William Dauchy <wdauchy@gmail.com>
2020-11-14 13:25:33 -05:00
} else {
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
HA_SPIN_UNLOCK(SERVER_LOCK, &sv->lock);
MEDIUM: cli/ssl: configure ssl on server at runtime in the context of a progressive backend migration, we want to be able to activate SSL on outgoing connections to the server at runtime without reloading. This patch adds a `set server ssl` command; in order to allow that: - add `srv_use_ssl` to `show servers state` command for compatibility, also update associated parsing - when using default-server ssl setting, and `no-ssl` on server line, init SSL ctx without activating it - when triggering ssl API, de/activate SSL connections as requested - clean ongoing connections as it is done for addr/port changes, without checking prior server state example config: backend be_foo default-server ssl server srv0 127.0.0.1:6011 weight 1 no-ssl show servers state: 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - -1 where srv0 can switch to ssl later during the runtime: set server be_foo/srv0 ssl on 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - 1 Also update existing tests and create a new one. Signed-off-by: William Dauchy <wdauchy@gmail.com>
2020-11-14 13:25:33 -05:00
cli_err(appctx, "'set server <srv> ssl' expects 'on' or 'off'.\n");
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
goto out;
MEDIUM: cli/ssl: configure ssl on server at runtime in the context of a progressive backend migration, we want to be able to activate SSL on outgoing connections to the server at runtime without reloading. This patch adds a `set server ssl` command; in order to allow that: - add `srv_use_ssl` to `show servers state` command for compatibility, also update associated parsing - when using default-server ssl setting, and `no-ssl` on server line, init SSL ctx without activating it - when triggering ssl API, de/activate SSL connections as requested - clean ongoing connections as it is done for addr/port changes, without checking prior server state example config: backend be_foo default-server ssl server srv0 127.0.0.1:6011 weight 1 no-ssl show servers state: 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - -1 where srv0 can switch to ssl later during the runtime: set server be_foo/srv0 ssl on 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - 1 Also update existing tests and create a new one. Signed-off-by: William Dauchy <wdauchy@gmail.com>
2020-11-14 13:25:33 -05:00
}
srv_cleanup_connections(sv);
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
HA_SPIN_UNLOCK(SERVER_LOCK, &sv->lock);
MEDIUM: cli/ssl: configure ssl on server at runtime in the context of a progressive backend migration, we want to be able to activate SSL on outgoing connections to the server at runtime without reloading. This patch adds a `set server ssl` command; in order to allow that: - add `srv_use_ssl` to `show servers state` command for compatibility, also update associated parsing - when using default-server ssl setting, and `no-ssl` on server line, init SSL ctx without activating it - when triggering ssl API, de/activate SSL connections as requested - clean ongoing connections as it is done for addr/port changes, without checking prior server state example config: backend be_foo default-server ssl server srv0 127.0.0.1:6011 weight 1 no-ssl show servers state: 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - -1 where srv0 can switch to ssl later during the runtime: set server be_foo/srv0 ssl on 5 be_foo 1 srv0 127.0.0.1 2 0 1 1 15 1 0 4 0 0 0 0 - 6011 - 1 Also update existing tests and create a new one. Signed-off-by: William Dauchy <wdauchy@gmail.com>
2020-11-14 13:25:33 -05:00
cli_msg(appctx, LOG_NOTICE, "server ssl setting updated.\n");
#else
cli_msg(appctx, LOG_NOTICE, "server ssl setting not supported.\n");
#endif
} else {
CLEANUP: cli: replace all occurrences of manual handling of return messages There were 221 places where a status message or an error message were built to be returned on the CLI. All of them were replaced to use cli_err(), cli_msg(), cli_dynerr() or cli_dynmsg() depending on what was expected. This removed a lot of duplicated code because most of the times, 4 lines are replaced by a single, safer one.
2019-08-09 05:21:01 -04:00
cli_err(appctx,
MINOR: cli: add missing agent commands for set server we previously forgot to add `agent-*` commands. Take this opportunity to rewrite the help string in a simpler way for readability (mainly removing simple quotes) Signed-off-by: William Dauchy <wdauchy@gmail.com>
2021-02-15 11:22:16 -05:00
"usage: set server <backend>/<server> "
"addr | agent | agent-addr | agent-port | agent-send | "
"check-addr | check-port | fqdn | health | ssl | "
"state | weight\n");
REORG: cli: move 'set server' to server.c Move 'set server' CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-18 20:00:33 -05:00
}
BUG/MEDIUM: server/cli: Fix ABBA deadlock when fqdn is set from the CLI To perform servers resolution, the resolver's lock is first acquired then the server's lock when necessary. However, when the fqdn is set via the CLI, the opposite is performed. So, it is possible to experience an ABBA deadlock. To fix this bug, the server's lock is acquired and released for each subcommand of "set server" with an exception when the fqdn is set. The resolver's lock is first acquired. Of course, this means we must be sure to have a resolver to lock. This patch must be backported as far as 1.8.
2021-06-15 06:01:29 -04:00
out:
REORG: cli: move 'set server' to server.c Move 'set server' CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-18 20:00:33 -05:00
return 1;
}
MEDIUM: cli: Add payload support In order to use arbitrary data in the CLI (multiple lines or group of words that must be considered as a whole, for example), it is now possible to add a payload to the commands. To do so, the first line needs to end with a special pattern: <<\n. Everything that follows will be left untouched by the CLI parser and will be passed to the commands parsers. Per-command support will need to be added to take advantage of this feature. Signed-off-by: Aurlien Nephtali <aurelien.nephtali@corp.ovh.com>
2018-04-18 07:26:46 -04:00
static int cli_parse_get_weight(char **args, char *payload, struct appctx *appctx, void *private)
REORG: cli: move get/set weight to server.c Move get/set weight CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-22 06:34:35 -05:00
{
MINOR: proxy: simplify parsing 'backend/server' Several CLI handlers use a server argument specified with the format '<backend>/<server>'. The parsing of this arguement is done in two steps, first splitting the string with '/' delimiter and then use get_backend_server() to retrieve the server instance. Refactor this code sections with the following changes : * splitting is reimplented using ist API * get_backend_server() is removed. Instead use the already existing proxy_be_by_name() then server_find_by_name() which contains duplicated code with the now removed function. No functional change occurs with this commit. However, it will be useful to add new configuration options reusing the same '<backend>/<server>' for reverse connect.
2023-08-07 10:24:24 -04:00
struct proxy *be;
REORG: cli: move get/set weight to server.c Move get/set weight CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-22 06:34:35 -05:00
struct server *sv;
MINOR: proxy: simplify parsing 'backend/server' Several CLI handlers use a server argument specified with the format '<backend>/<server>'. The parsing of this arguement is done in two steps, first splitting the string with '/' delimiter and then use get_backend_server() to retrieve the server instance. Refactor this code sections with the following changes : * splitting is reimplented using ist API * get_backend_server() is removed. Instead use the already existing proxy_be_by_name() then server_find_by_name() which contains duplicated code with the now removed function. No functional change occurs with this commit. However, it will be useful to add new configuration options reusing the same '<backend>/<server>' for reverse connect.
2023-08-07 10:24:24 -04:00
struct ist be_name, sv_name = ist(args[2]);
REORG: cli: move get/set weight to server.c Move get/set weight CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-22 06:34:35 -05:00
MINOR: proxy: simplify parsing 'backend/server' Several CLI handlers use a server argument specified with the format '<backend>/<server>'. The parsing of this arguement is done in two steps, first splitting the string with '/' delimiter and then use get_backend_server() to retrieve the server instance. Refactor this code sections with the following changes : * splitting is reimplented using ist API * get_backend_server() is removed. Instead use the already existing proxy_be_by_name() then server_find_by_name() which contains duplicated code with the now removed function. No functional change occurs with this commit. However, it will be useful to add new configuration options reusing the same '<backend>/<server>' for reverse connect.
2023-08-07 10:24:24 -04:00
be_name = istsplit(&sv_name, '/');
if (!istlen(sv_name))
BUG/MINOR: server/cli: add missing LF at the end of certain notice/error lines Some cli_err(), cli_msg() or even ha_error() etc are missing the trailing LF, which breaks the continuity of the CLI parsing: the extra LF that serves to mark the end of the command is in fact taken as the missing LF and no extra one is added. This patch adds the missing LF on identified messages. It might be worth trying to proceed in a more generic way with this, given the amount of code that is possibly at risk.
2024-02-08 11:43:14 -05:00
return cli_err(appctx, "Require 'backend/server'.\n");
REORG: cli: move get/set weight to server.c Move get/set weight CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-22 06:34:35 -05:00
MINOR: proxy: simplify parsing 'backend/server' Several CLI handlers use a server argument specified with the format '<backend>/<server>'. The parsing of this arguement is done in two steps, first splitting the string with '/' delimiter and then use get_backend_server() to retrieve the server instance. Refactor this code sections with the following changes : * splitting is reimplented using ist API * get_backend_server() is removed. Instead use the already existing proxy_be_by_name() then server_find_by_name() which contains duplicated code with the now removed function. No functional change occurs with this commit. However, it will be useful to add new configuration options reusing the same '<backend>/<server>' for reverse connect.
2023-08-07 10:24:24 -04:00
if (!(be = proxy_be_by_name(ist0(be_name))))
BUG/MINOR: server/cli: add missing LF at the end of certain notice/error lines Some cli_err(), cli_msg() or even ha_error() etc are missing the trailing LF, which breaks the continuity of the CLI parsing: the extra LF that serves to mark the end of the command is in fact taken as the missing LF and no extra one is added. This patch adds the missing LF on identified messages. It might be worth trying to proceed in a more generic way with this, given the amount of code that is possibly at risk.
2024-02-08 11:43:14 -05:00
return cli_err(appctx, "No such backend.\n");
CLEANUP: server: rename server_find_by_name() to server_find() This function doesn't just look at the name but also the ID when the argument starts with a '#'. So the name is not correct and explains why this function is not always used when the name only is needed, and why the list-based findserver() is used instead. So let's just call the function "server_find()", and rename its generation-id based cousin "server_find_unique()".
2025-07-10 04:59:06 -04:00
if (!(sv = server_find(be, ist0(sv_name))))
BUG/MINOR: server/cli: add missing LF at the end of certain notice/error lines Some cli_err(), cli_msg() or even ha_error() etc are missing the trailing LF, which breaks the continuity of the CLI parsing: the extra LF that serves to mark the end of the command is in fact taken as the missing LF and no extra one is added. This patch adds the missing LF on identified messages. It might be worth trying to proceed in a more generic way with this, given the amount of code that is possibly at risk.
2024-02-08 11:43:14 -05:00
return cli_err(appctx, "No such server.\n");
REORG: cli: move get/set weight to server.c Move get/set weight CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-22 06:34:35 -05:00
/* return server's effective weight at the moment */
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
snprintf(trash.area, trash.size, "%d (initial %d)\n", sv->uweight,
sv->iweight);
CLEANUP: applet: use applet_put*() everywhere possible This applies the change so that the applet code stops using ci_putchk() and friends everywhere possible, for the much saferapplet_put*() instead. The change is mechanical but large. Two or three functions used to have no appctx and a cs derived from the appctx instead, which was a reminiscence of old times' stream_interface. These were simply changed to directly take the appctx. No sensitive change was performed, and the old (more complex) API is still usable when needed (e.g. the channel is already known). The change touched roughly a hundred of locations, with no less than 124 lines removed. It's worth noting that the stats applet, the oldest of the series, could get a serious lifting, as it's still very channel-centric instead of propagating the appctx along the chain. Given that this code doesn't change often, there's no emergency to clean it up but it would look better.
2022-05-18 09:07:19 -04:00
if (applet_putstr(appctx, trash.area) == -1)
BUG/MINOR: cli: be sure to always warn the cli applet when input buffer is full [wt: may only strike if CLI commands are pipelined. Must be backported to 1.7 and 1.6, where it's a bit different and in dumpstats.c]
2016-12-05 08:25:08 -05:00
return 0;
REORG: cli: move get/set weight to server.c Move get/set weight CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-22 06:34:35 -05:00
return 1;
}
BUG/MEDIUM: cli/threads: protect some server commands against concurrent operations The server-specific CLI commands "set weight", "set maxconn", "disable agent", "enable agent", "disable health", "enable health", "disable server" and "enable server" were not protected against concurrent accesses. Now they take the server lock around the sensitive part. This patch must be backported to 1.8.
2018-08-21 09:35:31 -04:00
/* Parse a "set weight" command.
*
* Grabs the server lock.
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
*/
MEDIUM: cli: Add payload support In order to use arbitrary data in the CLI (multiple lines or group of words that must be considered as a whole, for example), it is now possible to add a payload to the commands. To do so, the first line needs to end with a special pattern: <<\n. Everything that follows will be left untouched by the CLI parser and will be passed to the commands parsers. Per-command support will need to be added to take advantage of this feature. Signed-off-by: Aurlien Nephtali <aurelien.nephtali@corp.ovh.com>
2018-04-18 07:26:46 -04:00
static int cli_parse_set_weight(char **args, char *payload, struct appctx *appctx, void *private)
REORG: cli: move get/set weight to server.c Move get/set weight CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-22 06:34:35 -05:00
{
struct server *sv;
const char *warning;
if (!cli_has_level(appctx, ACCESS_LVL_ADMIN))
return 1;
sv = cli_find_server(appctx, args[2]);
if (!sv)
return 1;
BUG/MEDIUM: cli/threads: protect some server commands against concurrent operations The server-specific CLI commands "set weight", "set maxconn", "disable agent", "enable agent", "disable health", "enable health", "disable server" and "enable server" were not protected against concurrent accesses. Now they take the server lock around the sensitive part. This patch must be backported to 1.8.
2018-08-21 09:35:31 -04:00
HA_SPIN_LOCK(SERVER_LOCK, &sv->lock);
REORG: cli: move get/set weight to server.c Move get/set weight CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-22 06:34:35 -05:00
warning = server_parse_weight_change_request(sv, args[3]);
CLEANUP: cli: replace all occurrences of manual handling of return messages There were 221 places where a status message or an error message were built to be returned on the CLI. All of them were replaced to use cli_err(), cli_msg(), cli_dynerr() or cli_dynmsg() depending on what was expected. This removed a lot of duplicated code because most of the times, 4 lines are replaced by a single, safer one.
2019-08-09 05:21:01 -04:00
if (warning)
cli_err(appctx, warning);
BUG/MEDIUM: cli/threads: protect some server commands against concurrent operations The server-specific CLI commands "set weight", "set maxconn", "disable agent", "enable agent", "disable health", "enable health", "disable server" and "enable server" were not protected against concurrent accesses. Now they take the server lock around the sensitive part. This patch must be backported to 1.8.
2018-08-21 09:35:31 -04:00
HA_SPIN_UNLOCK(SERVER_LOCK, &sv->lock);
REORG: cli: move get/set weight to server.c Move get/set weight CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-22 06:34:35 -05:00
return 1;
}
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
/* parse a "set maxconn server" command. It always returns 1.
*
BUG/MEDIUM: cli/threads: protect some server commands against concurrent operations The server-specific CLI commands "set weight", "set maxconn", "disable agent", "enable agent", "disable health", "enable health", "disable server" and "enable server" were not protected against concurrent accesses. Now they take the server lock around the sensitive part. This patch must be backported to 1.8.
2018-08-21 09:35:31 -04:00
* Grabs the server lock.
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
*/
MEDIUM: cli: Add payload support In order to use arbitrary data in the CLI (multiple lines or group of words that must be considered as a whole, for example), it is now possible to add a payload to the commands. To do so, the first line needs to end with a special pattern: <<\n. Everything that follows will be left untouched by the CLI parser and will be passed to the commands parsers. Per-command support will need to be added to take advantage of this feature. Signed-off-by: Aurlien Nephtali <aurelien.nephtali@corp.ovh.com>
2018-04-18 07:26:46 -04:00
static int cli_parse_set_maxconn_server(char **args, char *payload, struct appctx *appctx, void *private)
REORG: cli: move "set maxconn server" to server.c It's used to manipulate the server's maxconn setting.
2016-11-23 05:26:56 -05:00
{
struct server *sv;
const char *warning;
if (!cli_has_level(appctx, ACCESS_LVL_ADMIN))
return 1;
sv = cli_find_server(appctx, args[3]);
if (!sv)
return 1;
BUG/MAJOR: server: fix deadlock when changing maxconn via agent-check The server_parse_maxconn_change_request locks the server lock. However, this function can be called via agent-checks or lua code which already lock it. This bug has been introduced by the following commit : commit 79a88ba3d09f7e2b73ae27cb5d24cc087a548fa6 BUG/MAJOR: server: prevent deadlock when using 'set maxconn server' This commit tried to fix another deadlock with can occur because previoulsy server_parse_maxconn_change_request requires the server lock to be held. However, it may call internally process_srv_queue which also locks the server lock. The locking policy has thus been updated. The fix is functional for the CLI 'set maxconn' but fails to address the agent-check / lua counterparts. This new issue is fixed in two steps : - changes from the above commit have been reverted. This means that server_parse_maxconn_change_request must again be called with the server lock. - to counter the deadlock fixed by the above commit, process_srv_queue now takes an argument to render the server locking optional if the caller already held it. This is only used by server_parse_maxconn_change_request. The above commit was subject to backport up to 1.8. Thus this commit must be backported in every release where it is already present.
2021-06-18 05:11:36 -04:00
HA_SPIN_LOCK(SERVER_LOCK, &sv->lock);
REORG: cli: move "set maxconn server" to server.c It's used to manipulate the server's maxconn setting.
2016-11-23 05:26:56 -05:00
warning = server_parse_maxconn_change_request(sv, args[4]);
CLEANUP: cli: replace all occurrences of manual handling of return messages There were 221 places where a status message or an error message were built to be returned on the CLI. All of them were replaced to use cli_err(), cli_msg(), cli_dynerr() or cli_dynmsg() depending on what was expected. This removed a lot of duplicated code because most of the times, 4 lines are replaced by a single, safer one.
2019-08-09 05:21:01 -04:00
if (warning)
cli_err(appctx, warning);
BUG/MEDIUM: cli/threads: protect some server commands against concurrent operations The server-specific CLI commands "set weight", "set maxconn", "disable agent", "enable agent", "disable health", "enable health", "disable server" and "enable server" were not protected against concurrent accesses. Now they take the server lock around the sensitive part. This patch must be backported to 1.8.
2018-08-21 09:35:31 -04:00
BUG/MAJOR: server: fix deadlock when changing maxconn via agent-check The server_parse_maxconn_change_request locks the server lock. However, this function can be called via agent-checks or lua code which already lock it. This bug has been introduced by the following commit : commit 79a88ba3d09f7e2b73ae27cb5d24cc087a548fa6 BUG/MAJOR: server: prevent deadlock when using 'set maxconn server' This commit tried to fix another deadlock with can occur because previoulsy server_parse_maxconn_change_request requires the server lock to be held. However, it may call internally process_srv_queue which also locks the server lock. The locking policy has thus been updated. The fix is functional for the CLI 'set maxconn' but fails to address the agent-check / lua counterparts. This new issue is fixed in two steps : - changes from the above commit have been reverted. This means that server_parse_maxconn_change_request must again be called with the server lock. - to counter the deadlock fixed by the above commit, process_srv_queue now takes an argument to render the server locking optional if the caller already held it. This is only used by server_parse_maxconn_change_request. The above commit was subject to backport up to 1.8. Thus this commit must be backported in every release where it is already present.
2021-06-18 05:11:36 -04:00
HA_SPIN_UNLOCK(SERVER_LOCK, &sv->lock);
REORG: cli: move "set maxconn server" to server.c It's used to manipulate the server's maxconn setting.
2016-11-23 05:26:56 -05:00
return 1;
}
REORG: cli: move get/set weight to server.c Move get/set weight CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-22 06:34:35 -05:00
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
/* parse a "disable agent" command. It always returns 1.
*
BUG/MEDIUM: cli/threads: protect some server commands against concurrent operations The server-specific CLI commands "set weight", "set maxconn", "disable agent", "enable agent", "disable health", "enable health", "disable server" and "enable server" were not protected against concurrent accesses. Now they take the server lock around the sensitive part. This patch must be backported to 1.8.
2018-08-21 09:35:31 -04:00
* Grabs the server lock.
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
*/
MEDIUM: cli: Add payload support In order to use arbitrary data in the CLI (multiple lines or group of words that must be considered as a whole, for example), it is now possible to add a payload to the commands. To do so, the first line needs to end with a special pattern: <<\n. Everything that follows will be left untouched by the CLI parser and will be passed to the commands parsers. Per-command support will need to be added to take advantage of this feature. Signed-off-by: Aurlien Nephtali <aurelien.nephtali@corp.ovh.com>
2018-04-18 07:26:46 -04:00
static int cli_parse_disable_agent(char **args, char *payload, struct appctx *appctx, void *private)
REORG: cli: move "{enable|disable} agent" to server.c Also mention that "set server" is preferred now. Note that these were the last enable/disable commands in cli.c. Also remove the now unused expect_server_admin() function.
2016-11-24 06:56:01 -05:00
{
struct server *sv;
if (!cli_has_level(appctx, ACCESS_LVL_ADMIN))
return 1;
sv = cli_find_server(appctx, args[2]);
if (!sv)
return 1;
BUG/MEDIUM: cli/threads: protect some server commands against concurrent operations The server-specific CLI commands "set weight", "set maxconn", "disable agent", "enable agent", "disable health", "enable health", "disable server" and "enable server" were not protected against concurrent accesses. Now they take the server lock around the sensitive part. This patch must be backported to 1.8.
2018-08-21 09:35:31 -04:00
HA_SPIN_LOCK(SERVER_LOCK, &sv->lock);
REORG: cli: move "{enable|disable} agent" to server.c Also mention that "set server" is preferred now. Note that these were the last enable/disable commands in cli.c. Also remove the now unused expect_server_admin() function.
2016-11-24 06:56:01 -05:00
sv->agent.state &= ~CHK_ST_ENABLED;
BUG/MEDIUM: cli/threads: protect some server commands against concurrent operations The server-specific CLI commands "set weight", "set maxconn", "disable agent", "enable agent", "disable health", "enable health", "disable server" and "enable server" were not protected against concurrent accesses. Now they take the server lock around the sensitive part. This patch must be backported to 1.8.
2018-08-21 09:35:31 -04:00
HA_SPIN_UNLOCK(SERVER_LOCK, &sv->lock);
REORG: cli: move "{enable|disable} agent" to server.c Also mention that "set server" is preferred now. Note that these were the last enable/disable commands in cli.c. Also remove the now unused expect_server_admin() function.
2016-11-24 06:56:01 -05:00
return 1;
}
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
/* parse a "disable health" command. It always returns 1.
*
BUG/MEDIUM: cli/threads: protect some server commands against concurrent operations The server-specific CLI commands "set weight", "set maxconn", "disable agent", "enable agent", "disable health", "enable health", "disable server" and "enable server" were not protected against concurrent accesses. Now they take the server lock around the sensitive part. This patch must be backported to 1.8.
2018-08-21 09:35:31 -04:00
* Grabs the server lock.
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
*/
MEDIUM: cli: Add payload support In order to use arbitrary data in the CLI (multiple lines or group of words that must be considered as a whole, for example), it is now possible to add a payload to the commands. To do so, the first line needs to end with a special pattern: <<\n. Everything that follows will be left untouched by the CLI parser and will be passed to the commands parsers. Per-command support will need to be added to take advantage of this feature. Signed-off-by: Aurlien Nephtali <aurelien.nephtali@corp.ovh.com>
2018-04-18 07:26:46 -04:00
static int cli_parse_disable_health(char **args, char *payload, struct appctx *appctx, void *private)
REORG: cli: move "{enable|disable} health" to server.c Also mention that "set server" is preferred now.
2016-11-24 06:51:04 -05:00
{
struct server *sv;
if (!cli_has_level(appctx, ACCESS_LVL_ADMIN))
return 1;
sv = cli_find_server(appctx, args[2]);
if (!sv)
return 1;
BUG/MEDIUM: cli/threads: protect some server commands against concurrent operations The server-specific CLI commands "set weight", "set maxconn", "disable agent", "enable agent", "disable health", "enable health", "disable server" and "enable server" were not protected against concurrent accesses. Now they take the server lock around the sensitive part. This patch must be backported to 1.8.
2018-08-21 09:35:31 -04:00
HA_SPIN_LOCK(SERVER_LOCK, &sv->lock);
REORG: cli: move "{enable|disable} health" to server.c Also mention that "set server" is preferred now.
2016-11-24 06:51:04 -05:00
sv->check.state &= ~CHK_ST_ENABLED;
BUG/MEDIUM: cli/threads: protect some server commands against concurrent operations The server-specific CLI commands "set weight", "set maxconn", "disable agent", "enable agent", "disable health", "enable health", "disable server" and "enable server" were not protected against concurrent accesses. Now they take the server lock around the sensitive part. This patch must be backported to 1.8.
2018-08-21 09:35:31 -04:00
HA_SPIN_UNLOCK(SERVER_LOCK, &sv->lock);
REORG: cli: move "{enable|disable} health" to server.c Also mention that "set server" is preferred now.
2016-11-24 06:51:04 -05:00
return 1;
}
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
/* parse a "disable server" command. It always returns 1.
*
BUG/MEDIUM: cli/threads: protect some server commands against concurrent operations The server-specific CLI commands "set weight", "set maxconn", "disable agent", "enable agent", "disable health", "enable health", "disable server" and "enable server" were not protected against concurrent accesses. Now they take the server lock around the sensitive part. This patch must be backported to 1.8.
2018-08-21 09:35:31 -04:00
* Grabs the server lock.
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
*/
MEDIUM: cli: Add payload support In order to use arbitrary data in the CLI (multiple lines or group of words that must be considered as a whole, for example), it is now possible to add a payload to the commands. To do so, the first line needs to end with a special pattern: <<\n. Everything that follows will be left untouched by the CLI parser and will be passed to the commands parsers. Per-command support will need to be added to take advantage of this feature. Signed-off-by: Aurlien Nephtali <aurelien.nephtali@corp.ovh.com>
2018-04-18 07:26:46 -04:00
static int cli_parse_disable_server(char **args, char *payload, struct appctx *appctx, void *private)
REORG: cli: move "{enable|disable} server" to server.c Also mention that "set server" is preferred now.
2016-11-24 06:47:00 -05:00
{
struct server *sv;
if (!cli_has_level(appctx, ACCESS_LVL_ADMIN))
return 1;
sv = cli_find_server(appctx, args[2]);
if (!sv)
return 1;
BUG/MEDIUM: cli/threads: protect some server commands against concurrent operations The server-specific CLI commands "set weight", "set maxconn", "disable agent", "enable agent", "disable health", "enable health", "disable server" and "enable server" were not protected against concurrent accesses. Now they take the server lock around the sensitive part. This patch must be backported to 1.8.
2018-08-21 09:35:31 -04:00
HA_SPIN_LOCK(SERVER_LOCK, &sv->lock);
REORG: cli: move "{enable|disable} server" to server.c Also mention that "set server" is preferred now.
2016-11-24 06:47:00 -05:00
srv_adm_set_maint(sv);
BUG/MEDIUM: cli/threads: protect some server commands against concurrent operations The server-specific CLI commands "set weight", "set maxconn", "disable agent", "enable agent", "disable health", "enable health", "disable server" and "enable server" were not protected against concurrent accesses. Now they take the server lock around the sensitive part. This patch must be backported to 1.8.
2018-08-21 09:35:31 -04:00
HA_SPIN_UNLOCK(SERVER_LOCK, &sv->lock);
REORG: cli: move "{enable|disable} server" to server.c Also mention that "set server" is preferred now.
2016-11-24 06:47:00 -05:00
return 1;
}
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
/* parse a "enable agent" command. It always returns 1.
*
BUG/MEDIUM: cli/threads: protect some server commands against concurrent operations The server-specific CLI commands "set weight", "set maxconn", "disable agent", "enable agent", "disable health", "enable health", "disable server" and "enable server" were not protected against concurrent accesses. Now they take the server lock around the sensitive part. This patch must be backported to 1.8.
2018-08-21 09:35:31 -04:00
* Grabs the server lock.
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
*/
MEDIUM: cli: Add payload support In order to use arbitrary data in the CLI (multiple lines or group of words that must be considered as a whole, for example), it is now possible to add a payload to the commands. To do so, the first line needs to end with a special pattern: <<\n. Everything that follows will be left untouched by the CLI parser and will be passed to the commands parsers. Per-command support will need to be added to take advantage of this feature. Signed-off-by: Aurlien Nephtali <aurelien.nephtali@corp.ovh.com>
2018-04-18 07:26:46 -04:00
static int cli_parse_enable_agent(char **args, char *payload, struct appctx *appctx, void *private)
REORG: cli: move "{enable|disable} agent" to server.c Also mention that "set server" is preferred now. Note that these were the last enable/disable commands in cli.c. Also remove the now unused expect_server_admin() function.
2016-11-24 06:56:01 -05:00
{
struct server *sv;
if (!cli_has_level(appctx, ACCESS_LVL_ADMIN))
return 1;
sv = cli_find_server(appctx, args[2]);
if (!sv)
return 1;
CLEANUP: cli: replace all occurrences of manual handling of return messages There were 221 places where a status message or an error message were built to be returned on the CLI. All of them were replaced to use cli_err(), cli_msg(), cli_dynerr() or cli_dynmsg() depending on what was expected. This removed a lot of duplicated code because most of the times, 4 lines are replaced by a single, safer one.
2019-08-09 05:21:01 -04:00
if (!(sv->agent.state & CHK_ST_CONFIGURED))
return cli_err(appctx, "Agent was not configured on this server, cannot enable.\n");
REORG: cli: move "{enable|disable} agent" to server.c Also mention that "set server" is preferred now. Note that these were the last enable/disable commands in cli.c. Also remove the now unused expect_server_admin() function.
2016-11-24 06:56:01 -05:00
BUG/MEDIUM: cli/threads: protect some server commands against concurrent operations The server-specific CLI commands "set weight", "set maxconn", "disable agent", "enable agent", "disable health", "enable health", "disable server" and "enable server" were not protected against concurrent accesses. Now they take the server lock around the sensitive part. This patch must be backported to 1.8.
2018-08-21 09:35:31 -04:00
HA_SPIN_LOCK(SERVER_LOCK, &sv->lock);
REORG: cli: move "{enable|disable} agent" to server.c Also mention that "set server" is preferred now. Note that these were the last enable/disable commands in cli.c. Also remove the now unused expect_server_admin() function.
2016-11-24 06:56:01 -05:00
sv->agent.state |= CHK_ST_ENABLED;
BUG/MEDIUM: cli/threads: protect some server commands against concurrent operations The server-specific CLI commands "set weight", "set maxconn", "disable agent", "enable agent", "disable health", "enable health", "disable server" and "enable server" were not protected against concurrent accesses. Now they take the server lock around the sensitive part. This patch must be backported to 1.8.
2018-08-21 09:35:31 -04:00
HA_SPIN_UNLOCK(SERVER_LOCK, &sv->lock);
REORG: cli: move "{enable|disable} agent" to server.c Also mention that "set server" is preferred now. Note that these were the last enable/disable commands in cli.c. Also remove the now unused expect_server_admin() function.
2016-11-24 06:56:01 -05:00
return 1;
}
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
/* parse a "enable health" command. It always returns 1.
*
BUG/MEDIUM: cli/threads: protect some server commands against concurrent operations The server-specific CLI commands "set weight", "set maxconn", "disable agent", "enable agent", "disable health", "enable health", "disable server" and "enable server" were not protected against concurrent accesses. Now they take the server lock around the sensitive part. This patch must be backported to 1.8.
2018-08-21 09:35:31 -04:00
* Grabs the server lock.
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
*/
MEDIUM: cli: Add payload support In order to use arbitrary data in the CLI (multiple lines or group of words that must be considered as a whole, for example), it is now possible to add a payload to the commands. To do so, the first line needs to end with a special pattern: <<\n. Everything that follows will be left untouched by the CLI parser and will be passed to the commands parsers. Per-command support will need to be added to take advantage of this feature. Signed-off-by: Aurlien Nephtali <aurelien.nephtali@corp.ovh.com>
2018-04-18 07:26:46 -04:00
static int cli_parse_enable_health(char **args, char *payload, struct appctx *appctx, void *private)
REORG: cli: move "{enable|disable} health" to server.c Also mention that "set server" is preferred now.
2016-11-24 06:51:04 -05:00
{
struct server *sv;
if (!cli_has_level(appctx, ACCESS_LVL_ADMIN))
return 1;
sv = cli_find_server(appctx, args[2]);
if (!sv)
return 1;
BUG/MINOR: server: allow 'enable health' only if check configured Test that checks have been configured on the server before enabling via the 'enable health' CLI. This mirrors the 'enable agent' command. Without this, a user can use the command on the server without checks. This leaves the server in an undefined state. Notably, the stat page reports the server in check transition. This condition was left on the following reorg commit. 2c04eda8b58636ad2ae44e42b1f50f3b5a24a642 REORG: cli: move "{enable|disable} health" to server.c This should be backported up to 1.8.
2021-09-21 04:29:09 -04:00
if (!(sv->check.state & CHK_ST_CONFIGURED))
return cli_err(appctx, "Health check was not configured on this server, cannot enable.\n");
BUG/MEDIUM: cli/threads: protect some server commands against concurrent operations The server-specific CLI commands "set weight", "set maxconn", "disable agent", "enable agent", "disable health", "enable health", "disable server" and "enable server" were not protected against concurrent accesses. Now they take the server lock around the sensitive part. This patch must be backported to 1.8.
2018-08-21 09:35:31 -04:00
HA_SPIN_LOCK(SERVER_LOCK, &sv->lock);
REORG: cli: move "{enable|disable} health" to server.c Also mention that "set server" is preferred now.
2016-11-24 06:51:04 -05:00
sv->check.state |= CHK_ST_ENABLED;
BUG/MEDIUM: cli/threads: protect some server commands against concurrent operations The server-specific CLI commands "set weight", "set maxconn", "disable agent", "enable agent", "disable health", "enable health", "disable server" and "enable server" were not protected against concurrent accesses. Now they take the server lock around the sensitive part. This patch must be backported to 1.8.
2018-08-21 09:35:31 -04:00
HA_SPIN_UNLOCK(SERVER_LOCK, &sv->lock);
REORG: cli: move "{enable|disable} health" to server.c Also mention that "set server" is preferred now.
2016-11-24 06:51:04 -05:00
return 1;
}
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
/* parse a "enable server" command. It always returns 1.
*
BUG/MEDIUM: cli/threads: protect some server commands against concurrent operations The server-specific CLI commands "set weight", "set maxconn", "disable agent", "enable agent", "disable health", "enable health", "disable server" and "enable server" were not protected against concurrent accesses. Now they take the server lock around the sensitive part. This patch must be backported to 1.8.
2018-08-21 09:35:31 -04:00
* Grabs the server lock.
DOC: server/threads: document which functions need to be called with/without locks At the moment it's totally unclear while reading the server's code which functions require to be called with the server lock held and which ones grab it and cannot be called this way. This commit simply inventories all of them to indicate what is detected depending on how these functions use the struct server. Only functions used at runtime were checked, those dedicated to config parsing were skipped. Doing so already has uncovered a few bugs on some CLI actions.
2018-08-21 05:54:26 -04:00
*/
MEDIUM: cli: Add payload support In order to use arbitrary data in the CLI (multiple lines or group of words that must be considered as a whole, for example), it is now possible to add a payload to the commands. To do so, the first line needs to end with a special pattern: <<\n. Everything that follows will be left untouched by the CLI parser and will be passed to the commands parsers. Per-command support will need to be added to take advantage of this feature. Signed-off-by: Aurlien Nephtali <aurelien.nephtali@corp.ovh.com>
2018-04-18 07:26:46 -04:00
static int cli_parse_enable_server(char **args, char *payload, struct appctx *appctx, void *private)
REORG: cli: move "{enable|disable} server" to server.c Also mention that "set server" is preferred now.
2016-11-24 06:47:00 -05:00
{
struct server *sv;
if (!cli_has_level(appctx, ACCESS_LVL_ADMIN))
return 1;
sv = cli_find_server(appctx, args[2]);
if (!sv)
return 1;
BUG/MEDIUM: cli/threads: protect some server commands against concurrent operations The server-specific CLI commands "set weight", "set maxconn", "disable agent", "enable agent", "disable health", "enable health", "disable server" and "enable server" were not protected against concurrent accesses. Now they take the server lock around the sensitive part. This patch must be backported to 1.8.
2018-08-21 09:35:31 -04:00
HA_SPIN_LOCK(SERVER_LOCK, &sv->lock);
REORG: cli: move "{enable|disable} server" to server.c Also mention that "set server" is preferred now.
2016-11-24 06:47:00 -05:00
srv_adm_set_ready(sv);
MINOR: servers: Don't report duplicate dyncookies for disabled servers. Especially with server-templates, it can happen servers starts with a placeholder IP, in the disabled state. In this case, we don't want to report that the same cookie was generated for multiple servers. So defer the test until the server is enabled. This should be backported to 1.8.
2018-01-17 11:39:34 -05:00
if (!(sv->flags & SRV_F_COOKIESET)
&& (sv->proxy->ck_opts & PR_CK_DYNAMIC) &&
sv->cookie)
srv_check_for_dup_dyncookie(sv);
BUG/MEDIUM: cli/threads: protect some server commands against concurrent operations The server-specific CLI commands "set weight", "set maxconn", "disable agent", "enable agent", "disable health", "enable health", "disable server" and "enable server" were not protected against concurrent accesses. Now they take the server lock around the sensitive part. This patch must be backported to 1.8.
2018-08-21 09:35:31 -04:00
HA_SPIN_UNLOCK(SERVER_LOCK, &sv->lock);
REORG: cli: move "{enable|disable} server" to server.c Also mention that "set server" is preferred now.
2016-11-24 06:47:00 -05:00
return 1;
}
MEDIUM: server: implement 'add server' cli command Add a new cli command 'add server'. This command is used to create a new server at runtime attached on an existing backend. The syntax is the following one : $ add server <be_name>/<sv_name> [<kws>...] This command is only available through experimental mode for the moment. Currently, no server keywords are supported. They will be activated individually when deemed properly functional and safe. Another limitation is put on the backend load-balancing algorithm. The algorithm must use consistent hashing to guarantee a minimal reallocation of existing connections on the new server insertion.
2021-03-08 11:13:32 -05:00
/* Allocates data structure related to load balancing for the server <sv>. It
* is only required for dynamic servers.
*
* At the moment, the server lock is not used as this function is only called
* for a dynamic server not yet registered.
*
* Returns 1 on success, 0 on allocation failure.
*/
static int srv_alloc_lb(struct server *sv, struct proxy *be)
{
sv->lb_tree = (sv->flags & SRV_F_BACKUP) ?
&be->lbprm.chash.bck : &be->lbprm.chash.act;
sv->lb_nodes_tot = sv->uweight * BE_WEIGHT_SCALE;
sv->lb_nodes_now = 0;
BUG/MEDIUM: lb-chash: always properly initialize lb_nodes with dynamic servers An issue was introduced in 3.0 with commit faa8c3e024 ("MEDIUM: lb-chash: Deterministic node hashes based on server address"): the new server_key field and lb_nodes entries initialization were not updated for servers added at run time with "add server": server_key remains zero and the key used in lb_node remains the one depending only on the server's ID. This will cause trouble when adding new servers with consistent hashing, because the hash-key will be ignored until the server's weight changes and the key difference is detected, leading to its recalculation. This is essentially caused by the poorly placed lb_nodes initialization that is specific to lb-chash and had to be replicated in the code dealing with server addition. This commit solves the problem by adding a new ->server_init() function in the lbprm proxy struct, that is called by the server addition code. This also allows to abandon the complex check for LB algos that was placed there for that purpose. For now only lb-chash provides such a function, and calls it as well during initial setup. This way newly added servers always use the correct key now. While it should also theoretically have had an impact on servers added with the "random" algorithm, it's unlikely that the difference between proper server keys and those based on their ID could have had any visible effect. This patch should be backported as far as 3.0. The backport may be eased by a preliminary backport of previous commit "CLEANUP: lb-chash: free lb_nodes from chash's deinit(), not global", though this is not strictly necessary if context is manually adjusted.
2026-02-10 01:10:09 -05:00
if (be->lbprm.server_init && be->lbprm.server_init(sv) < 0)
return 0; // typically out of memory
MEDIUM: server: implement 'add server' cli command Add a new cli command 'add server'. This command is used to create a new server at runtime attached on an existing backend. The syntax is the following one : $ add server <be_name>/<sv_name> [<kws>...] This command is only available through experimental mode for the moment. Currently, no server keywords are supported. They will be activated individually when deemed properly functional and safe. Another limitation is put on the backend load-balancing algorithm. The algorithm must use consistent hashing to guarantee a minimal reallocation of existing connections on the new server insertion.
2021-03-08 11:13:32 -05:00
return 1;
}
REORG: server: move slowstart init outside of checks 'slowstart' can be used without check on a server, with the CLI handlers 'enable/disable server'. Move the code to initialize and start the slowstart task outside of check.c. This change will also be reused to enable slowstart for dynamic servers.
2021-09-21 05:51:29 -04:00
/* updates the server's weight during a warmup stage. Once the final weight is
* reached, the task automatically stops. Note that any server status change
MEDIUM: server: add and use a separate last_change variable for internal use last_change server metric is used for 2 separate purposes. First it is used to report last server state change date for stats and other related metrics. But it is also used internally, including in sensitive paths, such as lb related stuff to take decision or perform computations (ie: in srv_dynamic_maxconn()). Due to last_change counter now being split over thread groups since 16eb0fa ("MAJOR: counters: dispatch counters over thread groups"), reading the aggregated value has a cost, and we cannot afford to consult last_change value from srv_dynamic_maxconn() anymore. Moreover, since the value is used to take decision for the current process we don't wan't the variable to be updated by another process in our back. To prevent performance regression and sharing issues, let's instead add a separate srv->last_change value, which is not updated atomically (given how rare the updates are), and only serves for places where the use of the aggregated last_change counter/stats (split over thread groups) is too costly.
2025-06-30 04:57:29 -04:00
* must have updated server last_change accordingly.
REORG: server: move slowstart init outside of checks 'slowstart' can be used without check on a server, with the CLI handlers 'enable/disable server'. Move the code to initialize and start the slowstart task outside of check.c. This change will also be reused to enable slowstart for dynamic servers.
2021-09-21 05:51:29 -04:00
*/
static struct task *server_warmup(struct task *t, void *context, unsigned int state)
{
struct server *s = context;
/* by default, plan on stopping the task */
t->expire = TICK_ETERNITY;
if ((s->next_admin & SRV_ADMF_MAINT) ||
(s->next_state != SRV_ST_STARTING))
return t;
HA_SPIN_LOCK(SERVER_LOCK, &s->lock);
/* recalculate the weights and update the state */
server_recalc_eweight(s, 1);
MINOR: servers: Call process_srv_queue() without lock when possible In server_warmup(), call process_srv_queue() only once we released the server lock, as we don't need it.
2026-02-02 20:54:56 -05:00
HA_SPIN_UNLOCK(SERVER_LOCK, &s->lock);
REORG: server: move slowstart init outside of checks 'slowstart' can be used without check on a server, with the CLI handlers 'enable/disable server'. Move the code to initialize and start the slowstart task outside of check.c. This change will also be reused to enable slowstart for dynamic servers.
2021-09-21 05:51:29 -04:00
/* probably that we can refill this server with a bit more connections */
BUG/MEDIUM: queues: Do not use pendconn_grab_from_px(). pendconn_grab_from_px() was called when a server was brought back up, to get some streams waiting in the proxy's queue and get them to run on the newly available server. It is very similar to process_srv_queue(), except it only goes through the proxy's queue, which can be a problem, because there is a small race condition that could lead us to add more streams to the server queue just as it's going down. If that happens, the server would just be ignored when back up by new streams, as its queue is not empty, and it would never try to process its queue. The other problem with pendconn_grab_from_px() is that it is very liberal with how it dequeues streams, and it is not very good at enforcing maxconn, it could lead to having 3*maxconn connections. For both those reasons, just get rid of pendconn_grab_from_px(), and just use process_srv_queue(). Both problems are easy to reproduce, especially on a 64 threads machine, set a maxconn to 100, inject in H2 with 1000 concurrent connections containing up to 100 streams each, and after a few seconds/minutes the max number of concurrent output streams will be much higher than maxconn, and eventually the server will stop processing connections. It may be related to github issue #2744. Note that it doesn't totally fix the problem, we can occasionally see a few more connections than maxconn, but the max that have been observed is 4 more connections, we no longer get multiple times maxconn. have more outgoing connections than maxconn, This should be backported up to 2.6.
2024-12-17 09:39:21 -05:00
process_srv_queue(s);
REORG: server: move slowstart init outside of checks 'slowstart' can be used without check on a server, with the CLI handlers 'enable/disable server'. Move the code to initialize and start the slowstart task outside of check.c. This change will also be reused to enable slowstart for dynamic servers.
2021-09-21 05:51:29 -04:00
/* get back there in 1 second or 1/20th of the slowstart interval,
* whichever is greater, resulting in small 5% steps.
*/
if (s->next_state == SRV_ST_STARTING)
t->expire = tick_add(now_ms, MS_TO_TICKS(MAX(1000, s->slowstart / 20)));
return t;
}
/* Allocate the slowstart task if the server is configured with a slowstart
* timer. If server next_state is SRV_ST_STARTING, the task is scheduled.
*
* Returns 0 on success else non-zero.
*/
static int init_srv_slowstart(struct server *srv)
{
struct task *t;
if (srv->slowstart) {
MINOR: task: provide 3 task_new_* wrappers to simplify the API We'll need to improve the API to pass other arguments in the future, so let's start to adapt better to the current use cases. task_new() is used: - 18 times as task_new(tid_bit) - 18 times as task_new(MAX_THREADS_MASK) - 2 times with a single bit (in a loop) - 1 in the debug code that uses a mask This patch provides 3 new functions to achieve this: - task_new_here() to create a task on the calling thread - task_new_anywhere() to create a task to be run anywhere - task_new_on() to create a task to run on a specific thread The change is trivial and will allow us to later concentrate the required adaptations to these 3 functions only. It's still possible to call task_new() if needed but a comment was added to encourage the use of the new ones instead. The debug code was not changed and still uses it.
2021-10-01 12:23:30 -04:00
if ((t = task_new_anywhere()) == NULL) {
REORG: server: move slowstart init outside of checks 'slowstart' can be used without check on a server, with the CLI handlers 'enable/disable server'. Move the code to initialize and start the slowstart task outside of check.c. This change will also be reused to enable slowstart for dynamic servers.
2021-09-21 05:51:29 -04:00
ha_alert("Cannot activate slowstart for server %s/%s: out of memory.\n", srv->proxy->id, srv->id);
return ERR_ALERT | ERR_FATAL;
}
/* We need a warmup task that will be called when the server
* state switches from down to up.
*/
srv->warmup = t;
t->process = server_warmup;
t->context = srv;
/* server can be in this state only because of */
if (srv->next_state == SRV_ST_STARTING) {
task_schedule(srv->warmup,
tick_add(now_ms,
MEDIUM: server: add and use a separate last_change variable for internal use last_change server metric is used for 2 separate purposes. First it is used to report last server state change date for stats and other related metrics. But it is also used internally, including in sensitive paths, such as lb related stuff to take decision or perform computations (ie: in srv_dynamic_maxconn()). Due to last_change counter now being split over thread groups since 16eb0fa ("MAJOR: counters: dispatch counters over thread groups"), reading the aggregated value has a cost, and we cannot afford to consult last_change value from srv_dynamic_maxconn() anymore. Moreover, since the value is used to take decision for the current process we don't wan't the variable to be updated by another process in our back. To prevent performance regression and sharing issues, let's instead add a separate srv->last_change value, which is not updated atomically (given how rare the updates are), and only serves for places where the use of the aggregated last_change counter/stats (split over thread groups) is too costly.
2025-06-30 04:57:29 -04:00
MS_TO_TICKS(MAX(1000, (ns_to_sec(now_ns) - srv->last_change)) / 20)));
REORG: server: move slowstart init outside of checks 'slowstart' can be used without check on a server, with the CLI handlers 'enable/disable server'. Move the code to initialize and start the slowstart task outside of check.c. This change will also be reused to enable slowstart for dynamic servers.
2021-09-21 05:51:29 -04:00
}
}
return ERR_NONE;
}
MEDIUM: server: allocate a tasklet for asyncronous requeuing This creates a tasklet that only expects to be called when the LB algorithm is under contention when trying to reposition the server in its tree. Indeed, that's one of the operations that usually requires to take a write lock on a highly contended area, often for very little benefits under contention; indeed, under load, if a server keeps its previous position for a few extra microseconds, usually there's no harm. Thus this new tasklet can be woken up by the LB algo to ask the server to later call lbprm.server_requeue(). It does nothing else.
2025-02-11 11:18:36 -05:00
/* allocate the tasklet that's meant to permit a server */
static int init_srv_requeue(struct server *srv)
{
struct tasklet *t;
if ((t = tasklet_new()) == NULL) {
ha_alert("Cannot allocate a server requeuing tasklet for server %s/%s: out of memory.\n", srv->proxy->id, srv->id);
return ERR_ALERT | ERR_FATAL;
}
srv->requeue_tasklet = t;
t->process = server_requeue;
t->context = srv;
MEDIUM: servers: Schedule the server requeue target on creation On creation, schedule the server requeue once it's been created. It is possible that when the server went up, it tried to queue itself into the lb specific code, failed to do so, and expect the tasklet to run to take care of that. This should be backported to 3.2. This is part of an attempt to fix github issue #3143.
2025-10-01 11:56:52 -04:00
/*
* Run the tasklet once, in the very unlikely event the server
* failed to queue itself when brought up, which could happen if
* a memory allocation failed.
*/
tasklet_wakeup(t);
MEDIUM: server: allocate a tasklet for asyncronous requeuing This creates a tasklet that only expects to be called when the LB algorithm is under contention when trying to reposition the server in its tree. Indeed, that's one of the operations that usually requires to take a write lock on a highly contended area, often for very little benefits under contention; indeed, under load, if a server keeps its previous position for a few extra microseconds, usually there's no harm. Thus this new tasklet can be woken up by the LB algo to ask the server to later call lbprm.server_requeue(). It does nothing else.
2025-02-11 11:18:36 -05:00
return ERR_NONE;
}
CLEANUP: server: a separate function for initializing the per_thr field To avoid repeating the same source code, allocating memory and initializing the per_thr field from the server structure is transferred to a separate function.
2021-06-15 09:33:20 -04:00
/* Memory allocation and initialization of the per_thr field.
* Returns 0 if the field has been successfully initialized, -1 on failure.
*/
MEDIUM: server: add and use srv_init() function rename _srv_postparse() internal function to srv_init() function and group srv_init_per_thr() plus idle conns list init inside it. This way we can perform some simplifications as srv_init() performs multiple server init steps after parsing. SRV_F_CHECKED flag was added, it is automatically set when srv_init() runs successfully. If the flag is already set and srv_init() is called again, nothing is done. This permis to manually call srv_init() earlier than the default POST_CHECK hook when needed without risking to do things twice.
2025-05-09 14:27:29 -04:00
static int srv_init_per_thr(struct server *srv)
CLEANUP: server: a separate function for initializing the per_thr field To avoid repeating the same source code, allocating memory and initializing the per_thr field from the server structure is transferred to a separate function.
2021-06-15 09:33:20 -04:00
{
int i;
OPTIM: server: start to use aligned allocs in server This is currently for per-thread arrays like idle conns etc. We're now cache-aligning the per-thread arrays so as to put an end to false sharing. A comparative test between no alignment and alignment on a simple config with round robin between 4 servers showed an average rate of 1.75M/s vs 1.72M/s before for 100M requests. The gain seems to be more commonly less than 1% however. This should mostly help make measurements more reproducible across multiple runs.
2025-08-11 11:43:51 -04:00
srv->per_thr = ha_aligned_zalloc(64, global.nbthread * sizeof(*srv->per_thr));
srv->per_tgrp = ha_aligned_zalloc(64, global.nbtgroups * sizeof(*srv->per_tgrp));
MINOR: server/idle: make the next_takeover index per-tgroup In order to evenly pick idle connections from other threads, there is a "next_takeover" index in the server, that is incremented each time a connection is picked from another thread, and indicates which one to start from next time. With thread groups this doesn't work well because the index is the same regardless of the group, and if a group has more threads than another, there's even a risk to reintroduce an imbalance. This patch introduces a new per-tgroup storage in servers which, for now, only contains an instance of this next_takeover index. This way each thread will now only manipulate the index specific to its own group, and the takeover will become fair again. More entries may come soon.
2022-11-21 08:14:06 -05:00
if (!srv->per_thr || !srv->per_tgrp)
CLEANUP: server: a separate function for initializing the per_thr field To avoid repeating the same source code, allocating memory and initializing the per_thr field from the server structure is transferred to a separate function.
2021-06-15 09:33:20 -04:00
return -1;
for (i = 0; i < global.nbthread; i++) {
MEDIUM: connection: move idle connection trees to ceb64 Idle connection trees currently require a 56-byte conn_hash_node per connection, which can be reduced to 32 bytes by moving to ceb64. While ceb64 is theoretically slower, in practice here we're essentially dealing with trees that almost always contain a single key and many duplicates. In this case, ceb64 insert and lookup functions become faster than eb64 ones because all duplicates are a list accessed in O(1) while it's a subtree for eb64. In tests it is impossible to tell the difference between the two, so it's worth reducing the memory usage. This commit brings the following memory savings to conn_hash_node (one per backend connection), and to srv_per_thread (one per thread and per server): struct before after delta conn_hash_nodea 56 32 -24 srv_per_thread 96 72 -24 The delicate part is conn_delete_from_tree(), because we need to know the tree root the connection is attached to. But thanks to recent cleanups, it's now clear enough (i.e. idle/safe/avail vs session are easy to distinguish).
2025-09-12 09:28:33 -04:00
srv->per_thr[i].idle_conns = NULL;
srv->per_thr[i].safe_conns = NULL;
srv->per_thr[i].avail_conns = NULL;
MINOR: server: shard by thread sess_conns member Server member <sess_conns> is a mt_list which contains every backend connections attached to a session which targets this server. These connecions are not present in idle server trees. The main utility of this list is to be able to cleanup these connections prior to removing a server via "del server" CLI. However, this procedure will be adjusted by a future patch. As such, <sess_conns> member must be moved into srv_per_thread struct. Effectively, this duplicates a list for every threads. This commit does not introduce functional change. Its goal is to ensure that these connections are now ordered by their owning thread, which will allow to implement a purge, similarly to idle connections attached to servers.
2025-08-14 12:18:01 -04:00
MT_LIST_INIT(&srv->per_thr[i].sess_conns);
CLEANUP: server: a separate function for initializing the per_thr field To avoid repeating the same source code, allocating memory and initializing the per_thr field from the server structure is transferred to a separate function.
2021-06-15 09:33:20 -04:00
MT_LIST_INIT(&srv->per_thr[i].streams);
MAJOR: connection: purge idle conn by last usage Backend idle connections are purged on a recurring occurence during the process lifetime. An estimated number of needed connections is calculated and the excess is removed periodically. Before this patch, purge was done directly using the idle then the safe connection tree of a server instance. This has a major drawback to take no account of a specific ordre and it may removed functional connections while leaving ones which will fail on the next reuse. The problem can be worse when using criteria to differentiate idle connections such as the SSL SNI. In this case, purge may remove connections with a high rate of reusing while leaving connections with criteria never matched once, thus reducing drastically the reuse rate. To improve this, introduce an alternative storage for idle connection used in parallel of the idle/safe trees. Now, each connection inserted in one of this tree is also inserted in the new list at `srv_per_thread.idle_conn_list`. This guarantees that recently used connection is present at the end of the list. During the purge, use this list instead of idle/safe trees. Remove first connection in front of the list which were not reused recently. This will ensure that connection that are frequently reused are not purged and should increase the reuse rate, particularily if distinct idle connection criterias are in used.
2023-08-21 12:32:29 -04:00
LIST_INIT(&srv->per_thr[i].idle_conn_list);
CLEANUP: server: a separate function for initializing the per_thr field To avoid repeating the same source code, allocating memory and initializing the per_thr field from the server structure is transferred to a separate function.
2021-06-15 09:33:20 -04:00
}
MINOR: servers: Provide a pointer to the server in srv_per_tgroup. Add a pointer to the server into the struct srv_per_tgroup, so that if we only have access to that srv_per_tgroup, we can come back to the corresponding server.
2025-04-17 05:20:24 -04:00
for (i = 0; i < global.nbtgroups; i++) {
srv->per_tgrp[i].server = srv;
MINOR: Add fields to the per-thread group field in struct server. Add a per-thread group queue and associated fields in per-thread group field in struct server, as well as a new field, queues length. This is currently unused, so should change nothing.
2025-01-15 10:16:18 -05:00
queue_init(&srv->per_tgrp[i].queue, srv->proxy, srv);
MINOR: servers: Provide a pointer to the server in srv_per_tgroup. Add a pointer to the server into the struct srv_per_tgroup, so that if we only have access to that srv_per_tgroup, we can come back to the corresponding server.
2025-04-17 05:20:24 -04:00
}
MINOR: Add fields to the per-thread group field in struct server. Add a per-thread group queue and associated fields in per-thread group field in struct server, as well as a new field, queues length. This is currently unused, so should change nothing.
2025-01-15 10:16:18 -05:00
CLEANUP: server: a separate function for initializing the per_thr field To avoid repeating the same source code, allocating memory and initializing the per_thr field from the server structure is transferred to a separate function.
2021-06-15 09:33:20 -04:00
return 0;
}
MINOR: server: define CLI I/O handler for "add server" Extend "add server" to support an IO handler function named cli_io_handler_add_server(). A context object is also defined whose usage will depend on IO handler capabilities. IO handler is skipped when "add server" is run in default mode, i.e. on a dynamic server creation. Thus, currently IO handler is unneeded. However, it will become useful to support sub-commands for "add server". Note that return value of "add server" parser has been changed on server creation success. Previously, it was used incorrectly to report if server was inserted or not. In fact, parser return value is used by CLI generic code to detect if command processing has been completed, or should continue to the IO handler. Now, "add server" always returns 1 to signal that CLI processing is completed. This is necessary to preserve CLI output emitted by parser, even now that IO handler is defined for the command. Previously, output was emitted in every situations due to IO handler not defined. See below code snippet from cli.c for a better overview : if (kw->parse && kw->parse(args, payload, appctx, kw->private) != 0) { ret = 1; goto fail; } /* kw->parse could set its own io_handler or io_release handler */ if (!appctx->cli_ctx.io_handler) { ret = 1; goto fail; } appctx->st0 = CLI_ST_CALLBACK; ret = 1; goto end;
2025-05-22 11:07:59 -04:00
/* Distinguish between "add server" default usage or one of its sub-commands. */
enum add_srv_mode {
ADD_SRV_MODE_DEF, /* default mode, IO handler should be skipped by parser. */
MINOR: server: implement "add server help" Implement "help" as a sub-command for "add server" CLI. The objective is to list all the keywords that are supported for dynamic servers. CLI IO handler and add_srv_ctx are used to support reentrancy on full output buffer. Now that this command is implemented, the outdated keyword list on "add server" from management documentation can be removed.
2025-05-22 11:12:53 -04:00
ADD_SRV_MODE_HELP, /* help mode to list supported keywords */
MINOR: server: define CLI I/O handler for "add server" Extend "add server" to support an IO handler function named cli_io_handler_add_server(). A context object is also defined whose usage will depend on IO handler capabilities. IO handler is skipped when "add server" is run in default mode, i.e. on a dynamic server creation. Thus, currently IO handler is unneeded. However, it will become useful to support sub-commands for "add server". Note that return value of "add server" parser has been changed on server creation success. Previously, it was used incorrectly to report if server was inserted or not. In fact, parser return value is used by CLI generic code to detect if command processing has been completed, or should continue to the IO handler. Now, "add server" always returns 1 to signal that CLI processing is completed. This is necessary to preserve CLI output emitted by parser, even now that IO handler is defined for the command. Previously, output was emitted in every situations due to IO handler not defined. See below code snippet from cli.c for a better overview : if (kw->parse && kw->parse(args, payload, appctx, kw->private) != 0) { ret = 1; goto fail; } /* kw->parse could set its own io_handler or io_release handler */ if (!appctx->cli_ctx.io_handler) { ret = 1; goto fail; } appctx->st0 = CLI_ST_CALLBACK; ret = 1; goto end;
2025-05-22 11:07:59 -04:00
};
/* Context for "add server" CLI. */
struct add_srv_ctx {
enum add_srv_mode mode;
void *obj1;
void *obj2;
};
MINOR: server: implement "add server help" Implement "help" as a sub-command for "add server" CLI. The objective is to list all the keywords that are supported for dynamic servers. CLI IO handler and add_srv_ctx are used to support reentrancy on full output buffer. Now that this command is implemented, the outdated keyword list on "add server" from management documentation can be removed.
2025-05-22 11:12:53 -04:00
/* Handler for "add server" command. Should be reserved to extra sub-commands
* such as "help".
*/
MINOR: server: define CLI I/O handler for "add server" Extend "add server" to support an IO handler function named cli_io_handler_add_server(). A context object is also defined whose usage will depend on IO handler capabilities. IO handler is skipped when "add server" is run in default mode, i.e. on a dynamic server creation. Thus, currently IO handler is unneeded. However, it will become useful to support sub-commands for "add server". Note that return value of "add server" parser has been changed on server creation success. Previously, it was used incorrectly to report if server was inserted or not. In fact, parser return value is used by CLI generic code to detect if command processing has been completed, or should continue to the IO handler. Now, "add server" always returns 1 to signal that CLI processing is completed. This is necessary to preserve CLI output emitted by parser, even now that IO handler is defined for the command. Previously, output was emitted in every situations due to IO handler not defined. See below code snippet from cli.c for a better overview : if (kw->parse && kw->parse(args, payload, appctx, kw->private) != 0) { ret = 1; goto fail; } /* kw->parse could set its own io_handler or io_release handler */ if (!appctx->cli_ctx.io_handler) { ret = 1; goto fail; } appctx->st0 = CLI_ST_CALLBACK; ret = 1; goto end;
2025-05-22 11:07:59 -04:00
int cli_io_handler_add_server(struct appctx *appctx)
{
struct add_srv_ctx *ctx = appctx->svcctx;
MINOR: server: implement "add server help" Implement "help" as a sub-command for "add server" CLI. The objective is to list all the keywords that are supported for dynamic servers. CLI IO handler and add_srv_ctx are used to support reentrancy on full output buffer. Now that this command is implemented, the outdated keyword list on "add server" from management documentation can be removed.
2025-05-22 11:12:53 -04:00
struct srv_kw_list *kwl = ctx->obj1;
struct srv_kw *kw;
MINOR: server: define CLI I/O handler for "add server" Extend "add server" to support an IO handler function named cli_io_handler_add_server(). A context object is also defined whose usage will depend on IO handler capabilities. IO handler is skipped when "add server" is run in default mode, i.e. on a dynamic server creation. Thus, currently IO handler is unneeded. However, it will become useful to support sub-commands for "add server". Note that return value of "add server" parser has been changed on server creation success. Previously, it was used incorrectly to report if server was inserted or not. In fact, parser return value is used by CLI generic code to detect if command processing has been completed, or should continue to the IO handler. Now, "add server" always returns 1 to signal that CLI processing is completed. This is necessary to preserve CLI output emitted by parser, even now that IO handler is defined for the command. Previously, output was emitted in every situations due to IO handler not defined. See below code snippet from cli.c for a better overview : if (kw->parse && kw->parse(args, payload, appctx, kw->private) != 0) { ret = 1; goto fail; } /* kw->parse could set its own io_handler or io_release handler */ if (!appctx->cli_ctx.io_handler) { ret = 1; goto fail; } appctx->st0 = CLI_ST_CALLBACK; ret = 1; goto end;
2025-05-22 11:07:59 -04:00
switch (ctx->mode) {
MINOR: server: implement "add server help" Implement "help" as a sub-command for "add server" CLI. The objective is to list all the keywords that are supported for dynamic servers. CLI IO handler and add_srv_ctx are used to support reentrancy on full output buffer. Now that this command is implemented, the outdated keyword list on "add server" from management documentation can be removed.
2025-05-22 11:12:53 -04:00
case ADD_SRV_MODE_HELP:
if (!kwl) {
/* first invocation */
if (applet_putstr(appctx, "List of keywords supported for dynamic server:\n") < 0)
return cli_err(appctx, "output error");
kwl = LIST_NEXT(&srv_keywords.list, struct srv_kw_list *, list);
ctx->obj1 = kwl;
ctx->obj2 = kwl->kw;
}
while (kwl != &srv_keywords) {
for (kw = ctx->obj2; kw->kw; ++kw) {
if (!kw->dynamic_ok)
continue;
ctx->obj2 = kw;
chunk_reset(&trash);
chunk_printf(&trash, "%s\n", kw->kw);
MINOR: server: use stress mode for "add server help" Implement stress mode on "add server help". This ensures that the command is fully reentrant on full output buffer. For testing, it requires compilation with USE_STRESS and global setting "stress-level 1".
2025-05-22 11:13:20 -04:00
if (STRESS_RUN1(applet_putchk_stress(appctx, &trash) == -1,
applet_putchk(appctx, &trash) == -1)) {
MINOR: server: implement "add server help" Implement "help" as a sub-command for "add server" CLI. The objective is to list all the keywords that are supported for dynamic servers. CLI IO handler and add_srv_ctx are used to support reentrancy on full output buffer. Now that this command is implemented, the outdated keyword list on "add server" from management documentation can be removed.
2025-05-22 11:12:53 -04:00
goto full;
MINOR: server: use stress mode for "add server help" Implement stress mode on "add server help". This ensures that the command is fully reentrant on full output buffer. For testing, it requires compilation with USE_STRESS and global setting "stress-level 1".
2025-05-22 11:13:20 -04:00
}
MINOR: server: implement "add server help" Implement "help" as a sub-command for "add server" CLI. The objective is to list all the keywords that are supported for dynamic servers. CLI IO handler and add_srv_ctx are used to support reentrancy on full output buffer. Now that this command is implemented, the outdated keyword list on "add server" from management documentation can be removed.
2025-05-22 11:12:53 -04:00
}
kwl = LIST_NEXT(&kwl->list, struct srv_kw_list *, list);
ctx->obj1 = kwl;
ctx->obj2 = kwl->kw;
}
break;
MINOR: server: define CLI I/O handler for "add server" Extend "add server" to support an IO handler function named cli_io_handler_add_server(). A context object is also defined whose usage will depend on IO handler capabilities. IO handler is skipped when "add server" is run in default mode, i.e. on a dynamic server creation. Thus, currently IO handler is unneeded. However, it will become useful to support sub-commands for "add server". Note that return value of "add server" parser has been changed on server creation success. Previously, it was used incorrectly to report if server was inserted or not. In fact, parser return value is used by CLI generic code to detect if command processing has been completed, or should continue to the IO handler. Now, "add server" always returns 1 to signal that CLI processing is completed. This is necessary to preserve CLI output emitted by parser, even now that IO handler is defined for the command. Previously, output was emitted in every situations due to IO handler not defined. See below code snippet from cli.c for a better overview : if (kw->parse && kw->parse(args, payload, appctx, kw->private) != 0) { ret = 1; goto fail; } /* kw->parse could set its own io_handler or io_release handler */ if (!appctx->cli_ctx.io_handler) { ret = 1; goto fail; } appctx->st0 = CLI_ST_CALLBACK; ret = 1; goto end;
2025-05-22 11:07:59 -04:00
case ADD_SRV_MODE_DEF:
/* Add srv parser must return 1 to prevent I/O handler execution in default mode. */
ABORT_NOW();
break;
}
return 1;
MINOR: server: implement "add server help" Implement "help" as a sub-command for "add server" CLI. The objective is to list all the keywords that are supported for dynamic servers. CLI IO handler and add_srv_ctx are used to support reentrancy on full output buffer. Now that this command is implemented, the outdated keyword list on "add server" from management documentation can be removed.
2025-05-22 11:12:53 -04:00
full:
return 0;
MINOR: server: define CLI I/O handler for "add server" Extend "add server" to support an IO handler function named cli_io_handler_add_server(). A context object is also defined whose usage will depend on IO handler capabilities. IO handler is skipped when "add server" is run in default mode, i.e. on a dynamic server creation. Thus, currently IO handler is unneeded. However, it will become useful to support sub-commands for "add server". Note that return value of "add server" parser has been changed on server creation success. Previously, it was used incorrectly to report if server was inserted or not. In fact, parser return value is used by CLI generic code to detect if command processing has been completed, or should continue to the IO handler. Now, "add server" always returns 1 to signal that CLI processing is completed. This is necessary to preserve CLI output emitted by parser, even now that IO handler is defined for the command. Previously, output was emitted in every situations due to IO handler not defined. See below code snippet from cli.c for a better overview : if (kw->parse && kw->parse(args, payload, appctx, kw->private) != 0) { ret = 1; goto fail; } /* kw->parse could set its own io_handler or io_release handler */ if (!appctx->cli_ctx.io_handler) { ret = 1; goto fail; } appctx->st0 = CLI_ST_CALLBACK; ret = 1; goto end;
2025-05-22 11:07:59 -04:00
}
/* Parse a "add server" command.
*
* Returns 1 to skip I/O handler processing, unless a sub-command is executed.
MEDIUM: server: implement 'add server' cli command Add a new cli command 'add server'. This command is used to create a new server at runtime attached on an existing backend. The syntax is the following one : $ add server <be_name>/<sv_name> [<kws>...] This command is only available through experimental mode for the moment. Currently, no server keywords are supported. They will be activated individually when deemed properly functional and safe. Another limitation is put on the backend load-balancing algorithm. The algorithm must use consistent hashing to guarantee a minimal reallocation of existing connections on the new server insertion.
2021-03-08 11:13:32 -05:00
*/
static int cli_parse_add_server(char **args, char *payload, struct appctx *appctx, void *private)
{
MINOR: server: define CLI I/O handler for "add server" Extend "add server" to support an IO handler function named cli_io_handler_add_server(). A context object is also defined whose usage will depend on IO handler capabilities. IO handler is skipped when "add server" is run in default mode, i.e. on a dynamic server creation. Thus, currently IO handler is unneeded. However, it will become useful to support sub-commands for "add server". Note that return value of "add server" parser has been changed on server creation success. Previously, it was used incorrectly to report if server was inserted or not. In fact, parser return value is used by CLI generic code to detect if command processing has been completed, or should continue to the IO handler. Now, "add server" always returns 1 to signal that CLI processing is completed. This is necessary to preserve CLI output emitted by parser, even now that IO handler is defined for the command. Previously, output was emitted in every situations due to IO handler not defined. See below code snippet from cli.c for a better overview : if (kw->parse && kw->parse(args, payload, appctx, kw->private) != 0) { ret = 1; goto fail; } /* kw->parse could set its own io_handler or io_release handler */ if (!appctx->cli_ctx.io_handler) { ret = 1; goto fail; } appctx->st0 = CLI_ST_CALLBACK; ret = 1; goto end;
2025-05-22 11:07:59 -04:00
struct add_srv_ctx *ctx = applet_reserve_svcctx(appctx, sizeof(*ctx));
MEDIUM: server: implement 'add server' cli command Add a new cli command 'add server'. This command is used to create a new server at runtime attached on an existing backend. The syntax is the following one : $ add server <be_name>/<sv_name> [<kws>...] This command is only available through experimental mode for the moment. Currently, no server keywords are supported. They will be activated individually when deemed properly functional and safe. Another limitation is put on the backend load-balancing algorithm. The algorithm must use consistent hashing to guarantee a minimal reallocation of existing connections on the new server insertion.
2021-03-08 11:13:32 -05:00
struct proxy *be;
struct server *srv;
MINOR: backend: add function to check support for dynamic servers Move backend compatibility checks performed during 'add server' in a dedicated function be_supports_dynamic_srv(). This should simplify addition of future restriction. This function will be reused when implementing backend creation at runtime.
2026-02-06 01:40:59 -05:00
char *be_name, *sv_name, *errmsg;
MEDIUM: server: implement 'add server' cli command Add a new cli command 'add server'. This command is used to create a new server at runtime attached on an existing backend. The syntax is the following one : $ add server <be_name>/<sv_name> [<kws>...] This command is only available through experimental mode for the moment. Currently, no server keywords are supported. They will be activated individually when deemed properly functional and safe. Another limitation is put on the backend load-balancing algorithm. The algorithm must use consistent hashing to guarantee a minimal reallocation of existing connections on the new server insertion.
2021-03-08 11:13:32 -05:00
int errcode, argc;
CLEANUP: server: a separate function for initializing the per_thr field To avoid repeating the same source code, allocating memory and initializing the per_thr field from the server structure is transferred to a separate function.
2021-06-15 09:33:20 -04:00
int next_id;
MEDIUM: server: implement 'add server' cli command Add a new cli command 'add server'. This command is used to create a new server at runtime attached on an existing backend. The syntax is the following one : $ add server <be_name>/<sv_name> [<kws>...] This command is only available through experimental mode for the moment. Currently, no server keywords are supported. They will be activated individually when deemed properly functional and safe. Another limitation is put on the backend load-balancing algorithm. The algorithm must use consistent hashing to guarantee a minimal reallocation of existing connections on the new server insertion.
2021-03-08 11:13:32 -05:00
const int parse_flags = SRV_PARSE_DYNAMIC|SRV_PARSE_PARSE_ADDR;
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
usermsgs_clr("CLI");
MEDIUM: server: implement 'add server' cli command Add a new cli command 'add server'. This command is used to create a new server at runtime attached on an existing backend. The syntax is the following one : $ add server <be_name>/<sv_name> [<kws>...] This command is only available through experimental mode for the moment. Currently, no server keywords are supported. They will be activated individually when deemed properly functional and safe. Another limitation is put on the backend load-balancing algorithm. The algorithm must use consistent hashing to guarantee a minimal reallocation of existing connections on the new server insertion.
2021-03-08 11:13:32 -05:00
if (!cli_has_level(appctx, ACCESS_LVL_ADMIN))
return 1;
++args;
MINOR: server: implement "add server help" Implement "help" as a sub-command for "add server" CLI. The objective is to list all the keywords that are supported for dynamic servers. CLI IO handler and add_srv_ctx are used to support reentrancy on full output buffer. Now that this command is implemented, the outdated keyword list on "add server" from management documentation can be removed.
2025-05-22 11:12:53 -04:00
if (strcmp(args[1], "help") == 0) {
ctx->mode = ADD_SRV_MODE_HELP;
ctx->obj2 = ctx->obj1 = NULL;
return 0;
}
MINOR: server: define CLI I/O handler for "add server" Extend "add server" to support an IO handler function named cli_io_handler_add_server(). A context object is also defined whose usage will depend on IO handler capabilities. IO handler is skipped when "add server" is run in default mode, i.e. on a dynamic server creation. Thus, currently IO handler is unneeded. However, it will become useful to support sub-commands for "add server". Note that return value of "add server" parser has been changed on server creation success. Previously, it was used incorrectly to report if server was inserted or not. In fact, parser return value is used by CLI generic code to detect if command processing has been completed, or should continue to the IO handler. Now, "add server" always returns 1 to signal that CLI processing is completed. This is necessary to preserve CLI output emitted by parser, even now that IO handler is defined for the command. Previously, output was emitted in every situations due to IO handler not defined. See below code snippet from cli.c for a better overview : if (kw->parse && kw->parse(args, payload, appctx, kw->private) != 0) { ret = 1; goto fail; } /* kw->parse could set its own io_handler or io_release handler */ if (!appctx->cli_ctx.io_handler) { ret = 1; goto fail; } appctx->st0 = CLI_ST_CALLBACK; ret = 1; goto end;
2025-05-22 11:07:59 -04:00
ctx->mode = ADD_SRV_MODE_DEF;
MEDIUM: server: implement 'add server' cli command Add a new cli command 'add server'. This command is used to create a new server at runtime attached on an existing backend. The syntax is the following one : $ add server <be_name>/<sv_name> [<kws>...] This command is only available through experimental mode for the moment. Currently, no server keywords are supported. They will be activated individually when deemed properly functional and safe. Another limitation is put on the backend load-balancing algorithm. The algorithm must use consistent hashing to guarantee a minimal reallocation of existing connections on the new server insertion.
2021-03-08 11:13:32 -05:00
sv_name = be_name = args[1];
/* split backend/server arg */
while (*sv_name && *(++sv_name)) {
if (*sv_name == '/') {
*sv_name = '\0';
++sv_name;
break;
}
}
if (!*sv_name)
BUG/MINOR: server/cli: add missing LF at the end of certain notice/error lines Some cli_err(), cli_msg() or even ha_error() etc are missing the trailing LF, which breaks the continuity of the CLI parsing: the extra LF that serves to mark the end of the command is in fact taken as the missing LF and no extra one is added. This patch adds the missing LF on identified messages. It might be worth trying to proceed in a more generic way with this, given the amount of code that is possibly at risk.
2024-02-08 11:43:14 -05:00
return cli_err(appctx, "Require 'backend/server'.\n");
MEDIUM: server: implement 'add server' cli command Add a new cli command 'add server'. This command is used to create a new server at runtime attached on an existing backend. The syntax is the following one : $ add server <be_name>/<sv_name> [<kws>...] This command is only available through experimental mode for the moment. Currently, no server keywords are supported. They will be activated individually when deemed properly functional and safe. Another limitation is put on the backend load-balancing algorithm. The algorithm must use consistent hashing to guarantee a minimal reallocation of existing connections on the new server insertion.
2021-03-08 11:13:32 -05:00
BUG/MEDIUM: server: ensure thread-safety of server runtime creation cli_parse_add_server can be executed in parallel by several CLI instances and so must be thread-safe. The critical points of the function are : - server duplicate detection - insertion of the server in the proxy list The mode of operation has been reversed. The server is first instantiated and parsed. The duplicate check has been moved at the end just before the insertion in the proxy list, under the thread isolation. Thus, the thread safety is guaranteed and server allocation is kept outside of locks/thread isolation.
2021-04-20 11:09:08 -04:00
be = proxy_be_by_name(be_name);
MEDIUM: server: implement 'add server' cli command Add a new cli command 'add server'. This command is used to create a new server at runtime attached on an existing backend. The syntax is the following one : $ add server <be_name>/<sv_name> [<kws>...] This command is only available through experimental mode for the moment. Currently, no server keywords are supported. They will be activated individually when deemed properly functional and safe. Another limitation is put on the backend load-balancing algorithm. The algorithm must use consistent hashing to guarantee a minimal reallocation of existing connections on the new server insertion.
2021-03-08 11:13:32 -05:00
if (!be)
BUG/MINOR: server/cli: add missing LF at the end of certain notice/error lines Some cli_err(), cli_msg() or even ha_error() etc are missing the trailing LF, which breaks the continuity of the CLI parsing: the extra LF that serves to mark the end of the command is in fact taken as the missing LF and no extra one is added. This patch adds the missing LF on identified messages. It might be worth trying to proceed in a more generic way with this, given the amount of code that is possibly at risk.
2024-02-08 11:43:14 -05:00
return cli_err(appctx, "No such backend.\n");
MEDIUM: server: implement 'add server' cli command Add a new cli command 'add server'. This command is used to create a new server at runtime attached on an existing backend. The syntax is the following one : $ add server <be_name>/<sv_name> [<kws>...] This command is only available through experimental mode for the moment. Currently, no server keywords are supported. They will be activated individually when deemed properly functional and safe. Another limitation is put on the backend load-balancing algorithm. The algorithm must use consistent hashing to guarantee a minimal reallocation of existing connections on the new server insertion.
2021-03-08 11:13:32 -05:00
MINOR: backend: add function to check support for dynamic servers Move backend compatibility checks performed during 'add server' in a dedicated function be_supports_dynamic_srv(). This should simplify addition of future restriction. This function will be reused when implementing backend creation at runtime.
2026-02-06 01:40:59 -05:00
errmsg = NULL;
if (!be_supports_dynamic_srv(be, &errmsg)) {
cli_dynerr(appctx, memprintf(&errmsg, "Backend does not support dynamic servers : %s.\n", errmsg));
MAJOR: log: introduce log backends Using "mode log" in a backend section turns the proxy in a log backend which can be used to log-balance logs between multiple log targets (udp or tcp servers) log backends can be used as regular log targets using the log directive with "backend@be_name" prefix, like so: | log backend@mybackend local0 A log backend will distribute log messages to servers according to the log load-balancing algorithm that can be set using the "log-balance" option from the log backend section. For now, only the roundrobin algorithm is supported and set by default.
2023-09-13 05:52:31 -04:00
return 1;
}
BUG/MEDIUM: server: extend thread-isolate over much of CLI 'add server' Some config parsing handlers were designed to be run at startup on a single-thread. When executing at runtime for dynamic servers, thread-safety is not guaranteed. This is the case for example in srv_parse_id which manipulates backend used_ids tree. One solution could be to add locks but it might be tricky to found all affected functions and it can be an easy source of deadlock. The other solution which has been chosen is to use thread-isolation over almost all of the cli_parse_add_server CLI handler. For now this solution is sufficient. If some users make heavy use of the 'add server', hurting the overall performance, it will be necessary to design a much thinner solution. This must be backported up to 2.4.
2021-06-10 09:26:44 -04:00
/* At this point, some operations might not be thread-safe anymore. This
* might be the case for parsing handlers which were designed to run
* only at the starting stage on single-thread mode.
*
* Activate thread isolation to ensure thread-safety.
*/
thread_isolate();
MEDIUM: server: automatically add server to proxy list in new_server() while new_server() takes the parent proxy as argument and even assigns srv->proxy to the parent proxy, it didn't actually inserted the server to the parent proxy server list on success. The result is that sometimes we add the server to the list after new_server() is called, and sometimes we don't. This is really error-prone and because of that hooks such as REGISTER_POST_SERVER_CHECK() which as run for all servers listed in all proxies may not be relied upon for servers which are not actually inserted in their parent proxy server list. Plus it feels very strange to have a server that points to a proxy, but then the proxy doesn't know about it because it cannot find it in its server list. To prevent errors and make proxy->srv list reliable, we move the insertion logic directly under new_server(). This requires to know if we are called during parsing or during runtime to either insert or append the server to the parent proxy list. For that we use PR_FL_CHECKED flag from the parent proxy (if the flag is set, then the proxy was checked so we are past the init phase, thus we assume we are called during runtime) This implies that during startup if new_server() has to be cancelled on error paths we need to call srv_detach() (which is now exposed in server.h) before srv_drop(). The consequence of this commit is that REGISTER_POST_SERVER_CHECK() should not run reliably on all servers created using new_server() (without having to manually loop on global servers_list)
2025-05-09 13:24:55 -04:00
/*
* If a server with the same name is found, reject the new one.
*/
CLEANUP: server: rename server_find_by_name() to server_find() This function doesn't just look at the name but also the ID when the argument starts with a '#'. So the name is not correct and explains why this function is not always used when the name only is needed, and why the list-based findserver() is used instead. So let's just call the function "server_find()", and rename its generation-id based cousin "server_find_unique()".
2025-07-10 04:59:06 -04:00
if (server_find(be, sv_name)) {
MEDIUM: server: automatically add server to proxy list in new_server() while new_server() takes the parent proxy as argument and even assigns srv->proxy to the parent proxy, it didn't actually inserted the server to the parent proxy server list on success. The result is that sometimes we add the server to the list after new_server() is called, and sometimes we don't. This is really error-prone and because of that hooks such as REGISTER_POST_SERVER_CHECK() which as run for all servers listed in all proxies may not be relied upon for servers which are not actually inserted in their parent proxy server list. Plus it feels very strange to have a server that points to a proxy, but then the proxy doesn't know about it because it cannot find it in its server list. To prevent errors and make proxy->srv list reliable, we move the insertion logic directly under new_server(). This requires to know if we are called during parsing or during runtime to either insert or append the server to the parent proxy list. For that we use PR_FL_CHECKED flag from the parent proxy (if the flag is set, then the proxy was checked so we are past the init phase, thus we assume we are called during runtime) This implies that during startup if new_server() has to be cancelled on error paths we need to call srv_detach() (which is now exposed in server.h) before srv_drop(). The consequence of this commit is that REGISTER_POST_SERVER_CHECK() should not run reliably on all servers created using new_server() (without having to manually loop on global servers_list)
2025-05-09 13:24:55 -04:00
thread_release();
cli_err(appctx, "Already exists a server with the same name in backend.\n");
return 1;
}
MEDIUM: server: implement 'add server' cli command Add a new cli command 'add server'. This command is used to create a new server at runtime attached on an existing backend. The syntax is the following one : $ add server <be_name>/<sv_name> [<kws>...] This command is only available through experimental mode for the moment. Currently, no server keywords are supported. They will be activated individually when deemed properly functional and safe. Another limitation is put on the backend load-balancing algorithm. The algorithm must use consistent hashing to guarantee a minimal reallocation of existing connections on the new server insertion.
2021-03-08 11:13:32 -05:00
args[1] = sv_name;
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
errcode = _srv_parse_init(&srv, args, &argc, be, parse_flags);
if (errcode)
MEDIUM: server: implement 'add server' cli command Add a new cli command 'add server'. This command is used to create a new server at runtime attached on an existing backend. The syntax is the following one : $ add server <be_name>/<sv_name> [<kws>...] This command is only available through experimental mode for the moment. Currently, no server keywords are supported. They will be activated individually when deemed properly functional and safe. Another limitation is put on the backend load-balancing algorithm. The algorithm must use consistent hashing to guarantee a minimal reallocation of existing connections on the new server insertion.
2021-03-08 11:13:32 -05:00
goto out;
while (*args[argc]) {
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
errcode = _srv_parse_kw(srv, args, &argc, be, parse_flags);
MEDIUM: server: implement 'add server' cli command Add a new cli command 'add server'. This command is used to create a new server at runtime attached on an existing backend. The syntax is the following one : $ add server <be_name>/<sv_name> [<kws>...] This command is only available through experimental mode for the moment. Currently, no server keywords are supported. They will be activated individually when deemed properly functional and safe. Another limitation is put on the backend load-balancing algorithm. The algorithm must use consistent hashing to guarantee a minimal reallocation of existing connections on the new server insertion.
2021-03-08 11:13:32 -05:00
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
if (errcode)
MEDIUM: server: implement 'add server' cli command Add a new cli command 'add server'. This command is used to create a new server at runtime attached on an existing backend. The syntax is the following one : $ add server <be_name>/<sv_name> [<kws>...] This command is only available through experimental mode for the moment. Currently, no server keywords are supported. They will be activated individually when deemed properly functional and safe. Another limitation is put on the backend load-balancing algorithm. The algorithm must use consistent hashing to guarantee a minimal reallocation of existing connections on the new server insertion.
2021-03-08 11:13:32 -05:00
goto out;
}
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
errcode = _srv_parse_finalize(args, argc, srv, be, parse_flags);
if (errcode)
MEDIUM: server: implement 'add server' cli command Add a new cli command 'add server'. This command is used to create a new server at runtime attached on an existing backend. The syntax is the following one : $ add server <be_name>/<sv_name> [<kws>...] This command is only available through experimental mode for the moment. Currently, no server keywords are supported. They will be activated individually when deemed properly functional and safe. Another limitation is put on the backend load-balancing algorithm. The algorithm must use consistent hashing to guarantee a minimal reallocation of existing connections on the new server insertion.
2021-03-08 11:13:32 -05:00
goto out;
BUG/MINOR: server: explicitly set "none" init-addr for dynamic servers Define srv.init_addr_methods to SRV_IADDR_NONE on 'add server' CLI handler. This explicitly states that no resolution will be made on the server creation. This is not a real bug as the default value (SRV_IADDR_END) has the same effect in practice. However the intent is clearer and prevent to use the default "libc,last" by mistake which cannot execute on runtime (blocking call + file access via gethostbyname/getaddrinfo). The doc is also updated to reflect this limitation. This should be backported up to 2.4.
2021-06-10 11:34:10 -04:00
/* A dynamic server does not currently support resolution.
*
* Initialize it explicitly to the "none" method to ensure no
* resolution will ever be executed.
*/
srv->init_addr_methods = SRV_IADDR_NONE;
MINOR: server: support QUIC for dynamic servers To properly support QUIC for dynamic servers, it is required to extend add server CLI handler : * ensure conformity between server address and proto * automatically set proto to QUIC if not specified * prepare_srv callback must be called to initialize required SSL context Prior to this patch, crashes may occur when trying to use QUIC with dynamic servers. Also, destroy_srv callback must be called when a dynamic server is deallocated. This ensures that there is no memory leak due to SSL context. No need to backport.
2025-07-07 05:42:25 -04:00
if (!srv->mux_proto && srv_is_quic(srv)) {
/* Force QUIC as mux-proto on server with quic addresses.
* Incompatibilities with TCP proxy mode will be catch by the
* next code block.
*/
srv->mux_proto = get_mux_proto(ist("quic"));
}
MINOR: server: support keyword proto in 'add server' cli Allow to specify the mux proto for a dynamic server. It must be compatible with the backend mode to be accepted. The reg-tests has been extended for this error case.
2021-03-12 12:03:27 -05:00
if (srv->mux_proto) {
BUG/MEDIUM: server: "proto" not working for dynamic servers In 304672320e ("MINOR: server: support keyword proto in 'add server' cli") improper use of conn_get_best_mux_entry() function was made: First, server's proxy mode was directly passed as "proto_mode" argument to conn_get_best_mux_entry(), but this is strictly invalid because while there is some relationship between proto modes and proxy modes, they don't use the same storage mechanism and cannot be used interchangeably. Because of this bug, conn_get_best_mux_entry() would not work at all for TCP because PR_MODE_TCP equals 0, where PROTO_MODE_TCP normally equals 1. Then another, less sensitive bug, remains: as its name and description implies, conn_get_best_mux_entry() will try its best to return something to the user, only using keyword (mux_proto) input as an hint to return the most relevant mux within the list of mux that are compatibles with proto_side and proto_mode values. This means that even if mux_proto cannot be found or is not available with current proto_side and proto_mode values, conn_get_best_mux_entry() will most probably fallback to a more generic mux. However in cli_parse_add_server(), we directly check the result of conn_get_best_mux_entry() and consider that it will return NULL if the provided keyword hint for mux_proto cannot be found. This will result in the function not raising errors as expected, because most of the times if the expected proto cannot be found, then we'll silently switch to the fallback one, despite the user providing an explicit proto. To fix that, we store the result of conn_get_best_mux_entry() to compare the returned mux proto name with the one we're expecting to get, as it is originally performed in cfgparse during initial server keyword parsing. This patch depends on - "MINOR: connection: add conn_pr_mode_to_proto_mode() helper func") It must be backported up to 2.6.
2023-10-19 10:15:50 -04:00
int proto_mode = conn_pr_mode_to_proto_mode(be->mode);
const struct mux_proto_list *mux_ent;
mux_ent = conn_get_best_mux_entry(srv->mux_proto->token, PROTO_SIDE_BE, proto_mode);
if (!mux_ent || !isteq(mux_ent->token, srv->mux_proto->token)) {
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
ha_alert("MUX protocol is not usable for server.\n");
MINOR: server: support keyword proto in 'add server' cli Allow to specify the mux proto for a dynamic server. It must be compatible with the backend mode to be accepted. The reg-tests has been extended for this error case.
2021-03-12 12:03:27 -05:00
goto out;
}
MINOR: server: support QUIC for dynamic servers To properly support QUIC for dynamic servers, it is required to extend add server CLI handler : * ensure conformity between server address and proto * automatically set proto to QUIC if not specified * prepare_srv callback must be called to initialize required SSL context Prior to this patch, crashes may occur when trying to use QUIC with dynamic servers. Also, destroy_srv callback must be called when a dynamic server is deallocated. This ensures that there is no memory leak due to SSL context. No need to backport.
2025-07-07 05:42:25 -04:00
else {
if ((mux_ent->mux->flags & MX_FL_FRAMED) && !srv_is_quic(srv)) {
ha_alert("MUX protocol is incompatible with stream transport used by server.\n");
goto out;
}
else if (!(mux_ent->mux->flags & MX_FL_FRAMED) && srv_is_quic(srv)) {
ha_alert("MUX protocol is incompatible with framed transport used by server.\n");
goto out;
}
}
MINOR: server: support keyword proto in 'add server' cli Allow to specify the mux proto for a dynamic server. It must be compatible with the backend mode to be accepted. The reg-tests has been extended for this error case.
2021-03-12 12:03:27 -05:00
}
BUG/MINOR: server/add: ensure minconn/maxconn consistency when adding server When a new server was added through the cli using "server add" command, the maxconn/minconn consistency check historically implemented in check_config_validity() for static servers was missing. As a result, when adding a server with the maxconn parameter without the minconn set, the server was unable to handle any connection because srv_dynamic_maxconn() would always return 0. Consider the following reproducer: | global | stats socket /tmp/ha.sock mode 660 level admin expose-fd listeners | | defaults | timeout client 5s | timeout server 5s | timeout connect 5s | | frontend test | mode http | bind *:8081 | use_backend farm | | listen dummyok | bind localhost:18999 | mode http | http-request return status 200 hdr test "ok" | | backend farm | mode http Start haproxy and perform the following : echo "add server farm/t1 127.0.0.1:18999 maxconn 100" | nc -U /tmp/ha.sock echo "enable server farm/t1" | nc -U /tmp/ha.sock curl localhost:8081 # -> 503 after 5s connect timeout Thanks to ("MINOR: cfgparse/server: move (min/max)conn postparsing logic into dedicated function"), we are now able to perform the consistency check after the new dynamic server has been parsed. This is enough to fix the issue documented here that was reported by Thomas Pedoussaut on the ML. This commit depends on: - ("MINOR: cfgparse/server: move (min/max)conn postparsing logic into dedicated function") It must be backported to 2.6 and 2.7
2023-02-08 05:55:08 -05:00
/* ensure minconn/maxconn consistency */
srv_minmax_conn_apply(srv);
MINOR: server: enable more keywords for ssl checks for dynamic servers Allow to configure ssl support for dynamic server checks independently of the ssl server configuration. This is done via the keyword "check-ssl". Also enable to configure the sni/alpn used for the check via "check-sni/alpn".
2021-09-20 09:15:19 -04:00
if (srv->use_ssl == 1 || (srv->proxy->options & PR_O_TCPCHK_SSL) ||
srv->check.use_ssl == 1) {
MINOR: ssl: support ssl keyword for dynamic servers Activate the 'ssl' keyword for dynamic servers. This is the final step to have ssl dynamic servers feature implemented. If activated, ssl_sock_prepare_srv_ctx will be called at the end of the 'add server' CLI handler. At the same time, update the management doc to list all ssl keywords implemented for dynamic servers.
2021-05-19 03:49:41 -04:00
if (xprt_get(XPRT_SSL) && xprt_get(XPRT_SSL)->prepare_srv) {
if (xprt_get(XPRT_SSL)->prepare_srv(srv))
goto out;
}
MINOR: server: support QUIC for dynamic servers To properly support QUIC for dynamic servers, it is required to extend add server CLI handler : * ensure conformity between server address and proto * automatically set proto to QUIC if not specified * prepare_srv callback must be called to initialize required SSL context Prior to this patch, crashes may occur when trying to use QUIC with dynamic servers. Also, destroy_srv callback must be called when a dynamic server is deallocated. This ensures that there is no memory leak due to SSL context. No need to backport.
2025-07-07 05:42:25 -04:00
else if (xprt_get(XPRT_QUIC) && xprt_get(XPRT_QUIC)->prepare_srv) {
if (xprt_get(XPRT_QUIC)->prepare_srv(srv))
goto out;
}
MINOR: ssl: support ssl keyword for dynamic servers Activate the 'ssl' keyword for dynamic servers. This is the final step to have ssl dynamic servers feature implemented. If activated, ssl_sock_prepare_srv_ctx will be called at the end of the 'add server' CLI handler. At the same time, update the management doc to list all ssl keywords implemented for dynamic servers.
2021-05-19 03:49:41 -04:00
}
BUG/MINOR: server: set auto SNI for dynamic servers Auto SNI configuration is configured during check config validity. However, nothing was implemented for dynamic servers. Fix this by implementing auto SNI configuration during "add server" CLI handler. Auto SNI configuration code is moved in a dedicated function srv_configure_auto_sni() called both for static and dynamic servers. Along with this, allows the keyword "no-sni-auto" on dynamic servers, so that this process can be deactivated if wanted. Note that "sni-auto" remains unavailable as it only makes sense with default-servers which are never used for dynamic server creation. This must be backported up to 3.3.
2026-02-19 10:31:25 -05:00
/* Define default SNI from host header if needed. */
if (srv->proxy->mode == PR_MODE_HTTP && srv->use_ssl == 1 &&
!srv->sni_expr && !(srv->ssl_ctx.options & SRV_SSL_O_NO_AUTO_SNI)) {
if (srv_configure_auto_sni(srv, &errcode, &errmsg)) {
ha_alert("%s.\n", errmsg);
goto out;
}
}
MEDIUM: server: support track keyword for dynamic servers Allow the usage of the 'track' keyword for dynamic servers. On server deletion, the server is properly removed from the tracking chain to prevents NULL pointer dereferencing.
2021-07-13 04:36:03 -04:00
if (srv->trackit) {
if (srv_apply_track(srv, be))
goto out;
}
MEDIUM: server: implement agent check for dynamic servers This commit is the counterpart for agent check of "MEDIUM: server: implement check for dynamic servers". The "agent-check" keyword is enabled for dynamic servers. The agent check must manually be activated via "enable agent" CLI. This can enable the dynamic server if the agent response is "ready" without an explicit "enable server" CLI.
2021-08-04 05:33:14 -04:00
/* Init check/agent if configured. The check is manually disabled
* because a dynamic server is started in a disable state. It must be
* manually activated via a "enable health/agent" command.
MEDIUM: server: implement check for dynamic servers Implement check support for dynamic servers. The "check" keyword is now enabled for dynamic servers. If used, the server check is initialized and the check task started in the "add server" CLI handler. The check is explicitely disabled and must be manually activated via "enable health" CLI handler. The dynamic server refcount is incremented if a check is configured. On "delete server" handler, the check is purged, which decrements the refcount.
2021-07-22 10:04:59 -04:00
*/
if (srv->do_check) {
if (init_srv_check(srv))
goto out;
srv->check.state &= ~CHK_ST_ENABLED;
}
BUG/MEDIUM: server: support both check/agent-check on a dynamic instance A static server is able to support simultaneously both health chech and agent-check. Adjust the dynamic server CLI handlers to also support this configuration. This should not be backported, unless dynamic server checks are backported.
2021-08-10 10:24:36 -04:00
if (srv->do_agent) {
MEDIUM: server: implement agent check for dynamic servers This commit is the counterpart for agent check of "MEDIUM: server: implement check for dynamic servers". The "agent-check" keyword is enabled for dynamic servers. The agent check must manually be activated via "enable agent" CLI. This can enable the dynamic server if the agent response is "ready" without an explicit "enable server" CLI.
2021-08-04 05:33:14 -04:00
if (init_srv_agent_check(srv))
goto out;
srv->agent.state &= ~CHK_ST_ENABLED;
}
MEDIUM: server: implement check for dynamic servers Implement check support for dynamic servers. The "check" keyword is now enabled for dynamic servers. If used, the server check is initialized and the check task started in the "add server" CLI handler. The check is explicitely disabled and must be manually activated via "enable health" CLI handler. The dynamic server refcount is incremented if a check is configured. On "delete server" handler, the check is purged, which decrements the refcount.
2021-07-22 10:04:59 -04:00
MEDIUM: server: split srv_init() in srv_preinit() + srv_postinit() We actually need more granularity to split srv postparsing init tasks: Some of them are required to be run BEFORE the config is checked, and some of them AFTER the config is checked. Thus we push the logic from 368d0136 ("MEDIUM: server: add and use srv_init() function") a little bit further and split the function in two distinct ones, one of them executed under check_config_validity() and the other one using REGISTER_POST_SERVER_CHECK() hook. SRV_F_CHECKED flag was removed because it is no longer needed, srv_preinit() is only called once, and so is srv_postinit().
2025-08-08 06:22:13 -04:00
errcode = srv_preinit(srv);
if (errcode)
goto out;
BUG/MINOR: server: adjust initialization order for dynamic servers It appears that in cli_parse_add_server(), we're calling srv_alloc_lb() and stats_allocate_proxy_counters_internal() before srv_preinit() which allocates the thread groups. LB algos can make use of the per_tgrp part which is initialized by srv_preinit(). Fortunately for now no algo uses both tgrp and ->server_init() so this explains why this remained unnoticed to date. Also, extra counters will soon require per_tgrp to already be initialized. So let's move these between srv_preinit() and srv_postinit(). It's possible that other parts will have to be moved in between. This could be backported to recent versions for the sake of safety but it looks like the current code cannot tell the difference.
2026-02-24 14:28:50 -05:00
if (!srv_alloc_lb(srv, be)) {
ha_alert("Failed to initialize load-balancing data.\n");
goto out;
}
if (!stats_allocate_proxy_counters_internal(&srv->extra_counters,
COUNTERS_SV,
MEDIUM: counters: add a dedicated storage for extra_counters in various structs Servers, proxies, listeners and resolvers all use extra_counters. We'll need to move the storage to per-tgroup for those where it matters. Now we're relying on an external storage, and the data member of the struct was replaced with a pointer to that pointer to data called datap. When the counters are registered, these datap are set to point to relevant locations. In the case of proxies and servers, it points to the first tgrp's storage. For listeners and resolvers, it points to a local storage. The rationale here is that listeners are limited to a single group anyway, and that resolvers have a low enough load so that we do not care about contention there. Nothing should change for the user at this point.
2026-02-24 14:08:49 -05:00
STATS_PX_CAP_SRV,
MINOR: counters: store a tgroup step for extra_counters to access multiple tgroups We'll need to permit any user to update its own tgroup's extra counters instead of the global ones. For this we now store the per-tgroup step between two consecutive data storages, for when they're stored in a tgroup array. When shared (e.g. resolvers or listeners), we just store zero to indicate that it doesn't scale with tgroups. For now only the registration was handled, it's not used yet.
2026-02-25 03:53:13 -05:00
&srv->per_tgrp->extra_counters_storage,
&srv->per_tgrp[1].extra_counters_storage -
&srv->per_tgrp[0].extra_counters_storage)) {
BUG/MINOR: server: adjust initialization order for dynamic servers It appears that in cli_parse_add_server(), we're calling srv_alloc_lb() and stats_allocate_proxy_counters_internal() before srv_preinit() which allocates the thread groups. LB algos can make use of the per_tgrp part which is initialized by srv_preinit(). Fortunately for now no algo uses both tgrp and ->server_init() so this explains why this remained unnoticed to date. Also, extra counters will soon require per_tgrp to already be initialized. So let's move these between srv_preinit() and srv_postinit(). It's possible that other parts will have to be moved in between. This could be backported to recent versions for the sake of safety but it looks like the current code cannot tell the difference.
2026-02-24 14:28:50 -05:00
ha_alert("failed to allocate extra counters for server.\n");
goto out;
}
MEDIUM: server: split srv_init() in srv_preinit() + srv_postinit() We actually need more granularity to split srv postparsing init tasks: Some of them are required to be run BEFORE the config is checked, and some of them AFTER the config is checked. Thus we push the logic from 368d0136 ("MEDIUM: server: add and use srv_init() function") a little bit further and split the function in two distinct ones, one of them executed under check_config_validity() and the other one using REGISTER_POST_SERVER_CHECK() hook. SRV_F_CHECKED flag was removed because it is no longer needed, srv_preinit() is only called once, and so is srv_postinit().
2025-08-08 06:22:13 -04:00
errcode = srv_postinit(srv);
MINOR: server: group postinit server tasks under _srv_postparse() init_srv_requeue() and init_srv_slowstart() functions are called after initial server parsing via REGISTER_POST_SERVER_CHECK() hook, and they are also manually called for dynamic server after the server is initialized. This may conflict with _srv_postparse() which is also registered via REGISTER_POST_SERVER_CHECK() and called during dynamic server creation To ensure functions don't conflict with each other, let's ensure they are executed in proper order by calling init_srv_requeue and init_srv_slowstart() from _srv_postparse() which now becomes the parent function for server related postparsing stuff. No change of behavior is expected.
2025-05-08 13:15:24 -04:00
if (errcode)
MEDIUM: server: allocate a tasklet for asyncronous requeuing This creates a tasklet that only expects to be called when the LB algorithm is under contention when trying to reposition the server in its tree. Indeed, that's one of the operations that usually requires to take a write lock on a highly contended area, often for very little benefits under contention; indeed, under load, if a server keeps its previous position for a few extra microseconds, usually there's no harm. Thus this new tasklet can be woken up by the LB algo to ask the server to later call lbprm.server_requeue(). It does nothing else.
2025-02-11 11:18:36 -05:00
goto out;
BUG/MEDIUM: server: do not forget to generate the dynamic servers ids If no id is specified by the user for a dynamic server, it is necessary to generate a new one. This operation is now done at the end of 'add server' CLI handler. The server is then inserted into the proxy ids tree. Without this, several features may be broken for dynamic servers. Among them, there is the "first" lb algorithm, the persistence using stick-tables or the uniqueness internal check of srv_parse_id. This must be backported up to 2.4.
2021-06-09 03:58:47 -04:00
/* generate the server id if not manually specified */
if (!srv->puid) {
MINOR: server: add server_get_next_id() to find next free server ID This was previously achieved via the generic get_next_id() but we'll soon get rid of generic ID trees so let's have a dedicated server_get_next_id(). As a bonus it reduces the exposure of the tree's root outside of the functions.
2025-08-23 13:26:08 -04:00
next_id = server_get_next_id(be, 1);
BUG/MEDIUM: server: do not forget to generate the dynamic servers ids If no id is specified by the user for a dynamic server, it is necessary to generate a new one. This operation is now done at the end of 'add server' CLI handler. The server is then inserted into the proxy ids tree. Without this, several features may be broken for dynamic servers. Among them, there is the "first" lb algorithm, the persistence using stick-tables or the uniqueness internal check of srv_parse_id. This must be backported up to 2.4.
2021-06-09 03:58:47 -04:00
if (!next_id) {
ha_alert("Cannot attach server : no id left in proxy\n");
goto out;
}
MEDIUM: server: index server ID using compact trees The server ID is currently stored as a 32-bit int using an eb32 tree. It's used essentially to find holes in order to automatically assign IDs, and to detect duplicates. Let's change this to use compact trees instead in order to save 24 bytes in struct server for this node, plus 8 bytes in struct proxy. The server struct is still 3904 bytes large (due to alignment) and the proxy struct is 3072.
2025-08-24 05:21:02 -04:00
srv->puid = next_id;
BUG/MEDIUM: server: do not forget to generate the dynamic servers ids If no id is specified by the user for a dynamic server, it is necessary to generate a new one. This operation is now done at the end of 'add server' CLI handler. The server is then inserted into the proxy ids tree. Without this, several features may be broken for dynamic servers. Among them, there is the "first" lb algorithm, the persistence using stick-tables or the uniqueness internal check of srv_parse_id. This must be backported up to 2.4.
2021-06-09 03:58:47 -04:00
}
/* insert the server in the backend trees */
MINOR: server: add server_index_id() to index a server by its ID This avoids needlessly exposing the tree's root and the mechanics outside of the low-level code.
2025-08-23 13:33:52 -04:00
server_index_id(be, srv);
MEDIUM: server: switch conf.name to cebis_tree This is used to index the server name and it contains a copy of the pointer to the server's name in <id>. Changing that for a ceb_node placed just before <id> saves 32 bytes to the struct server, which remains 3968 bytes large due to alignment. The proxy struct shrinks by 8 bytes to 3144. It's worth noting that the current way duplicate names are handled remains based on the previous mechanism where dups were permitted. Ideally we should now reject them during insertion and use unique key trees instead.
2025-07-07 09:33:40 -04:00
cebis_item_insert(&be->conf.used_server_name, conf.name_node, id, srv);
MEDIUM: server: switch addr_node to cebis_tree This contains the text representation of the server's address, for use with stick-tables with "srvkey addr". Switching them to a compact node saves 24 more bytes from this structure. The key was moved to an external pointer "addr_key" right after the node. The server struct is now 3968 bytes (down from 4032) due to alignment, and the proxy struct shrinks by 8 bytes to 3152.
2025-07-07 09:13:15 -04:00
/* addr_key could be NULL if FQDN resolution is postponed (ie: add server from cli) */
if (srv->addr_key)
cebuis_item_insert(&be->used_server_addr, addr_node, addr_key, srv);
BUG/MEDIUM: server: do not forget to generate the dynamic servers ids If no id is specified by the user for a dynamic server, it is necessary to generate a new one. This operation is now done at the end of 'add server' CLI handler. The server is then inserted into the proxy ids tree. Without this, several features may be broken for dynamic servers. Among them, there is the "first" lb algorithm, the persistence using stick-tables or the uniqueness internal check of srv_parse_id. This must be backported up to 2.4.
2021-06-09 03:58:47 -04:00
MINOR: server: add srv->rid (revision id) value With current design, we could not distinguish between previously existing deleted server and a new server reusing the deleted server name/id. This can cause some confusion when auditing stats/events/logs, because the new server will look similar to the old one. To address this, we're adding a new value in server structure: rid rid (revision id) value is an unsigned 32bits value that is set upon server creation. Value is derived from a global counter that starts at 0 and is incremented each time one or multiple server deletions are followed by a server addition (meaning that old name/id reuse could occur). Thanks to this revision id, it is now easy to tell whether the server we're looking at is the same as before or if it has been deleted and re-added in the meantime. (combining server name/id + server revision id yields a process-wide unique identifier)
2022-11-17 10:10:35 -05:00
/* check if LSB bit (odd bit) is set for reuse_cnt */
if (srv_id_reuse_cnt & 1) {
/* cnt must be increased */
srv_id_reuse_cnt++;
}
/* srv_id_reuse_cnt is always even at this stage, divide by 2 to
* save some space
* (sizeof(srv->rid) is half of sizeof(srv_id_reuse_cnt))
*/
srv->rid = (srv_id_reuse_cnt) ? (srv_id_reuse_cnt / 2) : 0;
BUG/MINOR: server: fix persistence cookie for dynamic servers When adding a server dynamically, we observe that when a backend has a dynamic persistence cookie, the new server has no cookie as we receive the following HTTP header: set-cookie: test-cookie=; Expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/ Whereas we were expecting to receive something like the following, which is what we receive for a server added in the config file: set-cookie: test-cookie=abcdef1234567890; path=/ After investigating code path, srv_set_dyncookie() is never called when adding a server through CLI, it is only called when parsing config file or using "set server bkd1/srv1 addr". To fix this, call srv_set_dyncookie() inside cli_parse_add_server(). This patch must be backported up to 2.4.
2024-03-27 10:34:25 -04:00
/* generate new server's dynamic cookie if enabled on backend */
if (be->ck_opts & PR_CK_DYNAMIC) {
srv_set_dyncookie(srv);
}
MINOR: server/event_hdl: add support for SERVER_ADD and SERVER_DEL events Basic support for ADD and DEL server events are added through this commit: SERVER_ADD is published on dynamic server addition through cli. SERVER_DEL is published on dynamic server deletion through cli. This work depends on: "MINOR: event_hdl: add event handler base api" "MINOR: server: add srv->rid (revision id) value"
2022-11-17 04:37:58 -05:00
/* adding server cannot fail when we reach this:
* publishing EVENT_HDL_SUB_SERVER_ADD
*/
srv_event_hdl_publish(EVENT_HDL_SUB_SERVER_ADD, srv, 1);
MEDIUM: server: implement 'add server' cli command Add a new cli command 'add server'. This command is used to create a new server at runtime attached on an existing backend. The syntax is the following one : $ add server <be_name>/<sv_name> [<kws>...] This command is only available through experimental mode for the moment. Currently, no server keywords are supported. They will be activated individually when deemed properly functional and safe. Another limitation is put on the backend load-balancing algorithm. The algorithm must use consistent hashing to guarantee a minimal reallocation of existing connections on the new server insertion.
2021-03-08 11:13:32 -05:00
thread_release();
MEDIUM: server: implement check for dynamic servers Implement check support for dynamic servers. The "check" keyword is now enabled for dynamic servers. If used, the server check is initialized and the check task started in the "add server" CLI handler. The check is explicitely disabled and must be manually activated via "enable health" CLI handler. The dynamic server refcount is incremented if a check is configured. On "delete server" handler, the check is purged, which decrements the refcount.
2021-07-22 10:04:59 -04:00
/* Start the check task. The server must be fully initialized.
*
* <srvpos> and <nbcheck> parameters are set to 1 as there should be no
* need to randomly spread the task interval for dynamic servers.
*/
if (srv->check.state & CHK_ST_CONFIGURED) {
if (!start_check_task(&srv->check, 0, 1, 1))
BUG/MINOR: server/cli: add missing LF at the end of certain notice/error lines Some cli_err(), cli_msg() or even ha_error() etc are missing the trailing LF, which breaks the continuity of the CLI parsing: the extra LF that serves to mark the end of the command is in fact taken as the missing LF and no extra one is added. This patch adds the missing LF on identified messages. It might be worth trying to proceed in a more generic way with this, given the amount of code that is possibly at risk.
2024-02-08 11:43:14 -05:00
ha_alert("System might be unstable, consider to execute a reload\n");
MEDIUM: server: implement check for dynamic servers Implement check support for dynamic servers. The "check" keyword is now enabled for dynamic servers. If used, the server check is initialized and the check task started in the "add server" CLI handler. The check is explicitely disabled and must be manually activated via "enable health" CLI handler. The dynamic server refcount is incremented if a check is configured. On "delete server" handler, the check is purged, which decrements the refcount.
2021-07-22 10:04:59 -04:00
}
BUG/MEDIUM: server: support both check/agent-check on a dynamic instance A static server is able to support simultaneously both health chech and agent-check. Adjust the dynamic server CLI handlers to also support this configuration. This should not be backported, unless dynamic server checks are backported.
2021-08-10 10:24:36 -04:00
if (srv->agent.state & CHK_ST_CONFIGURED) {
MEDIUM: server: implement agent check for dynamic servers This commit is the counterpart for agent check of "MEDIUM: server: implement check for dynamic servers". The "agent-check" keyword is enabled for dynamic servers. The agent check must manually be activated via "enable agent" CLI. This can enable the dynamic server if the agent response is "ready" without an explicit "enable server" CLI.
2021-08-04 05:33:14 -04:00
if (!start_check_task(&srv->agent, 0, 1, 1))
BUG/MINOR: server/cli: add missing LF at the end of certain notice/error lines Some cli_err(), cli_msg() or even ha_error() etc are missing the trailing LF, which breaks the continuity of the CLI parsing: the extra LF that serves to mark the end of the command is in fact taken as the missing LF and no extra one is added. This patch adds the missing LF on identified messages. It might be worth trying to proceed in a more generic way with this, given the amount of code that is possibly at risk.
2024-02-08 11:43:14 -05:00
ha_alert("System might be unstable, consider to execute a reload\n");
MEDIUM: server: implement agent check for dynamic servers This commit is the counterpart for agent check of "MEDIUM: server: implement check for dynamic servers". The "agent-check" keyword is enabled for dynamic servers. The agent check must manually be activated via "enable agent" CLI. This can enable the dynamic server if the agent response is "ready" without an explicit "enable server" CLI.
2021-08-04 05:33:14 -04:00
}
MEDIUM: server: implement check for dynamic servers Implement check support for dynamic servers. The "check" keyword is now enabled for dynamic servers. If used, the server check is initialized and the check task started in the "add server" CLI handler. The check is explicitely disabled and must be manually activated via "enable health" CLI handler. The dynamic server refcount is incremented if a check is configured. On "delete server" handler, the check is purged, which decrements the refcount.
2021-07-22 10:04:59 -04:00
MINOR: server: allow cookie for dynamic servers This commit allows "cookie" keyword for dynamic servers. After code review, nothing was found which could prevent a dynamic server to use it. An extra warning is added under cli_parse_add_server() if cookie value is ignored due to a non HTTP backend. This patch is not considered a bugfix. However, it may backported if needed as its impact seems minimal.
2024-03-27 05:50:21 -04:00
if (srv->cklen && be->mode != PR_MODE_HTTP)
ha_warning("Ignoring cookie as HTTP mode is disabled.\n");
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
ha_notice("New server registered.\n");
MINOR: server: define CLI I/O handler for "add server" Extend "add server" to support an IO handler function named cli_io_handler_add_server(). A context object is also defined whose usage will depend on IO handler capabilities. IO handler is skipped when "add server" is run in default mode, i.e. on a dynamic server creation. Thus, currently IO handler is unneeded. However, it will become useful to support sub-commands for "add server". Note that return value of "add server" parser has been changed on server creation success. Previously, it was used incorrectly to report if server was inserted or not. In fact, parser return value is used by CLI generic code to detect if command processing has been completed, or should continue to the IO handler. Now, "add server" always returns 1 to signal that CLI processing is completed. This is necessary to preserve CLI output emitted by parser, even now that IO handler is defined for the command. Previously, output was emitted in every situations due to IO handler not defined. See below code snippet from cli.c for a better overview : if (kw->parse && kw->parse(args, payload, appctx, kw->private) != 0) { ret = 1; goto fail; } /* kw->parse could set its own io_handler or io_release handler */ if (!appctx->cli_ctx.io_handler) { ret = 1; goto fail; } appctx->st0 = CLI_ST_CALLBACK; ret = 1; goto end;
2025-05-22 11:07:59 -04:00
return cli_umsg(appctx, LOG_INFO);
MEDIUM: server: implement 'add server' cli command Add a new cli command 'add server'. This command is used to create a new server at runtime attached on an existing backend. The syntax is the following one : $ add server <be_name>/<sv_name> [<kws>...] This command is only available through experimental mode for the moment. Currently, no server keywords are supported. They will be activated individually when deemed properly functional and safe. Another limitation is put on the backend load-balancing algorithm. The algorithm must use consistent hashing to guarantee a minimal reallocation of existing connections on the new server insertion.
2021-03-08 11:13:32 -05:00
out:
BUG/MINOR: server: remove srv from px list on CLI 'add server' error If an error occured during the CLI 'add server' handler, the newly created server must be removed from the proxy list if already inserted. Currently, this can happen on the extremely rare error during server id generation if there is no id left. The removal operation is not thread-safe, it must be conducted before releasing the thread isolation. This can be backported up to 2.4. Please note that dynamic server track is not implemented in 2.4, so the release_server_track invocation must be removed for the backport to prevent a compilation error.
2021-08-04 05:20:05 -04:00
if (srv) {
if (srv->track)
release_server_track(srv);
BUG/MINOR: server: fix dynamic server leak with check on failed init If a dynamic server is added with check or agent-check, its refcount is incremented after server keyword parsing. However, if add server fails at a later stage, refcount is only decremented once, which prevented the server to be fully released. This causes a leak with a server which is detached from most of the lists but still exits in the system. This bug is considered minor as only a few conditions may cause a failure in add server after check/agent-check initialization. This is the case if there is a naming collision or the dynamic ID cannot be generated. To fix this, simply decrement server refcount on add server error path if either check and/or agent-check are flagged as activated. This bug is related to github issue #2733. Thanks to Chris Staite who first found the leak. This must be backported up to 2.6.
2024-10-22 05:02:15 -04:00
if (srv->check.state & CHK_ST_CONFIGURED) {
MEDIUM: server: implement check for dynamic servers Implement check support for dynamic servers. The "check" keyword is now enabled for dynamic servers. If used, the server check is initialized and the check task started in the "add server" CLI handler. The check is explicitely disabled and must be manually activated via "enable health" CLI handler. The dynamic server refcount is incremented if a check is configured. On "delete server" handler, the check is purged, which decrements the refcount.
2021-07-22 10:04:59 -04:00
free_check(&srv->check);
BUG/MINOR: server: fix dynamic server leak with check on failed init If a dynamic server is added with check or agent-check, its refcount is incremented after server keyword parsing. However, if add server fails at a later stage, refcount is only decremented once, which prevented the server to be fully released. This causes a leak with a server which is detached from most of the lists but still exits in the system. This bug is considered minor as only a few conditions may cause a failure in add server after check/agent-check initialization. This is the case if there is a naming collision or the dynamic ID cannot be generated. To fix this, simply decrement server refcount on add server error path if either check and/or agent-check are flagged as activated. This bug is related to github issue #2733. Thanks to Chris Staite who first found the leak. This must be backported up to 2.6.
2024-10-22 05:02:15 -04:00
srv_drop(srv);
}
if (srv->agent.state & CHK_ST_CONFIGURED) {
MEDIUM: server: implement agent check for dynamic servers This commit is the counterpart for agent check of "MEDIUM: server: implement check for dynamic servers". The "agent-check" keyword is enabled for dynamic servers. The agent check must manually be activated via "enable agent" CLI. This can enable the dynamic server if the agent response is "ready" without an explicit "enable server" CLI.
2021-08-04 05:33:14 -04:00
free_check(&srv->agent);
BUG/MINOR: server: fix dynamic server leak with check on failed init If a dynamic server is added with check or agent-check, its refcount is incremented after server keyword parsing. However, if add server fails at a later stage, refcount is only decremented once, which prevented the server to be fully released. This causes a leak with a server which is detached from most of the lists but still exits in the system. This bug is considered minor as only a few conditions may cause a failure in add server after check/agent-check initialization. This is the case if there is a naming collision or the dynamic ID cannot be generated. To fix this, simply decrement server refcount on add server error path if either check and/or agent-check are flagged as activated. This bug is related to github issue #2733. Thanks to Chris Staite who first found the leak. This must be backported up to 2.6.
2024-10-22 05:02:15 -04:00
srv_drop(srv);
}
MEDIUM: server: implement check for dynamic servers Implement check support for dynamic servers. The "check" keyword is now enabled for dynamic servers. If used, the server check is initialized and the check task started in the "add server" CLI handler. The check is explicitely disabled and must be manually activated via "enable health" CLI handler. The dynamic server refcount is incremented if a check is configured. On "delete server" handler, the check is purged, which decrements the refcount.
2021-07-22 10:04:59 -04:00
BUG/MINOR: server: remove srv from px list on CLI 'add server' error If an error occured during the CLI 'add server' handler, the newly created server must be removed from the proxy list if already inserted. Currently, this can happen on the extremely rare error during server id generation if there is no id left. The removal operation is not thread-safe, it must be conducted before releasing the thread isolation. This can be backported up to 2.4. Please note that dynamic server track is not implemented in 2.4, so the release_server_track invocation must be removed for the backport to prevent a compilation error.
2021-08-04 05:20:05 -04:00
/* remove the server from the proxy linked list */
MEDIUM: server: automatically add server to proxy list in new_server() while new_server() takes the parent proxy as argument and even assigns srv->proxy to the parent proxy, it didn't actually inserted the server to the parent proxy server list on success. The result is that sometimes we add the server to the list after new_server() is called, and sometimes we don't. This is really error-prone and because of that hooks such as REGISTER_POST_SERVER_CHECK() which as run for all servers listed in all proxies may not be relied upon for servers which are not actually inserted in their parent proxy server list. Plus it feels very strange to have a server that points to a proxy, but then the proxy doesn't know about it because it cannot find it in its server list. To prevent errors and make proxy->srv list reliable, we move the insertion logic directly under new_server(). This requires to know if we are called during parsing or during runtime to either insert or append the server to the parent proxy list. For that we use PR_FL_CHECKED flag from the parent proxy (if the flag is set, then the proxy was checked so we are past the init phase, thus we assume we are called during runtime) This implies that during startup if new_server() has to be cancelled on error paths we need to call srv_detach() (which is now exposed in server.h) before srv_drop(). The consequence of this commit is that REGISTER_POST_SERVER_CHECK() should not run reliably on all servers created using new_server() (without having to manually loop on global servers_list)
2025-05-09 13:24:55 -04:00
srv_detach(srv);
BUG/MINOR: server: remove srv from px list on CLI 'add server' error If an error occured during the CLI 'add server' handler, the newly created server must be removed from the proxy list if already inserted. Currently, this can happen on the extremely rare error during server id generation if there is no id left. The removal operation is not thread-safe, it must be conducted before releasing the thread isolation. This can be backported up to 2.4. Please note that dynamic server track is not implemented in 2.4, so the release_server_track invocation must be removed for the backport to prevent a compilation error.
2021-08-04 05:20:05 -04:00
}
BUG/MINOR: server: fix race on error path of 'add server' CLI if track If an error occurs during a dynamic server creation with tracking, it must be removed from the tracked list. This operation is not thread-safe and thus must be conducted under the thread isolation. Track support for dynamic servers has been introduced in this release. This does not need to be backported.
2021-07-28 04:06:52 -04:00
BUG/MEDIUM: server: extend thread-isolate over much of CLI 'add server' Some config parsing handlers were designed to be run at startup on a single-thread. When executing at runtime for dynamic servers, thread-safety is not guaranteed. This is the case for example in srv_parse_id which manipulates backend used_ids tree. One solution could be to add locks but it might be tricky to found all affected functions and it can be an easy source of deadlock. The other solution which has been chosen is to use thread-isolation over almost all of the cli_parse_add_server CLI handler. For now this solution is sufficient. If some users make heavy use of the 'add server', hurting the overall performance, it will be necessary to design a much thinner solution. This must be backported up to 2.4.
2021-06-10 09:26:44 -04:00
thread_release();
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
if (!usermsgs_empty())
MINOR: server: clear prefix on stderr logs after add server cli_parse_add_server() is the CLI handler for 'add server' command. This functions uses usermsgs_ctx to retrieve logs messages from internal ha_alert() calls and display it at the end of the handler. At the beginning of the handler, stderr prefix is defined to "CLI" via usermsgs_clr() function. However, this is not resetted at the end. This causes inconsistency for stderr output : 1. each ha_alert() invocation will reuse "CLI" prefix if 'add server' command was executed before, even in non-CLI context 2. usermsgs_ctx is thread local, so this is only true if this runs on the same thread as 'add server' handler. To fix this, ensure that "CLI" prefix is now resetted after cli_parse_add_server(). This is done thanks to the addition to cli_umsg()/cli_umsgerr() functions. This can be backported up to 2.5 if we prefer to ensure output consistency at the risk of changing stderr behaviors in stable versions. In this case, the previous commit should be backported before : MINOR: cli: define usermsgs print context
2022-11-10 09:16:49 -05:00
cli_umsgerr(appctx);
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
BUG/MINOR: server: fix race on error path of 'add server' CLI if track If an error occurs during a dynamic server creation with tracking, it must be removed from the tracked list. This operation is not thread-safe and thus must be conducted under the thread isolation. Track support for dynamic servers has been introduced in this release. This does not need to be backported.
2021-07-28 04:06:52 -04:00
if (srv)
MEDIUM: server: extend refcount for all servers In a future patch, it will be possible to remove at runtime every servers, both static and dynamic. This requires to extend the server refcount for all instances. First, refcount manipulation functions have been renamed to better express the API usage. * srv_refcount_use -> srv_take The refcount is always initialize to 1 on the server creation in new_server. It's also incremented for each check/agent configured on a server instance. * free_server -> srv_drop This decrements the refcount and if null, the server is freed, so code calling it must not use the server reference after it. As a bonus, this function now returns the next server instance. This is useful when calling on the server loop without having to save the next pointer before each invocation. In these functions, remove the checks that prevent refcount on non-dynamic servers. Each reference to "dynamic" in variable/function naming have been eliminated as well.
2021-08-25 09:34:53 -04:00
srv_drop(srv);
MEDIUM: server: support track keyword for dynamic servers Allow the usage of the 'track' keyword for dynamic servers. On server deletion, the server is properly removed from the tracking chain to prevents NULL pointer dereferencing.
2021-07-13 04:36:03 -04:00
MEDIUM: server: implement 'add server' cli command Add a new cli command 'add server'. This command is used to create a new server at runtime attached on an existing backend. The syntax is the following one : $ add server <be_name>/<sv_name> [<kws>...] This command is only available through experimental mode for the moment. Currently, no server keywords are supported. They will be activated individually when deemed properly functional and safe. Another limitation is put on the backend load-balancing algorithm. The algorithm must use consistent hashing to guarantee a minimal reallocation of existing connections on the new server insertion.
2021-03-08 11:13:32 -05:00
return 1;
}
MINOR: server: split the server deletion code in two parts We'll need to be able to verify whether or not a server may be deleted. For now, both the verification and the action are performed in the same function, at once under thread isolation. The goal here is to extract the verification code into a new function that will perform these checks, return a status between success/recoverable/non-recoverable failure, and will also return a message for the caller.
2024-02-09 13:28:13 -05:00
/* Check if the server <bename>/<svname> exists and is ready for being deleted.
CLEANUP: server: make it clear that srv_check_for_deletion() is thread-safe This function was marked as requiring thread isolation because its code was extracted from cli_parse_delete_server() and was running under isolation. But upon closer inspection, and using atomic loads to check a few counters, it is actually safe to run without isolation, so let's reflect that in its description. However, it remains true that cli_parse_delete_server() continues to call it under isolation.
2025-03-18 06:38:56 -04:00
* This means that the server is in maintenance with no streams attached to it,
* no queue and no used idle conns. This is not supposed to change during all
* the maintenance phase (except for force-persist etc, which are not covered).
* Both <bename> and <svname> must be valid strings. If pb/ps are not null,
* upon success, the pointer to the backend and server respectively will be put
* there. If pm is not null, a pointer to an error/success message is returned
* there (possibly NULL if nothing to say). Returned values:
MINOR: server: split the server deletion code in two parts We'll need to be able to verify whether or not a server may be deleted. For now, both the verification and the action are performed in the same function, at once under thread isolation. The goal here is to extract the verification code into a new function that will perform these checks, return a status between success/recoverable/non-recoverable failure, and will also return a message for the caller.
2024-02-09 13:28:13 -05:00
* >0 if OK
* 0 if not yet (should wait if it can)
* <0 if not possible
*/
int srv_check_for_deletion(const char *bename, const char *svname, struct proxy **pb, struct server **ps, const char **pm)
{
struct server *srv = NULL;
struct proxy *be = NULL;
const char *msg = NULL;
int ret;
/* First, unrecoverable errors */
ret = -1;
if (!(be = proxy_be_by_name(bename))) {
msg = "No such backend.";
goto leave;
}
CLEANUP: server: rename server_find_by_name() to server_find() This function doesn't just look at the name but also the ID when the argument starts with a '#'. So the name is not correct and explains why this function is not always used when the name only is needed, and why the list-based findserver() is used instead. So let's just call the function "server_find()", and rename its generation-id based cousin "server_find_unique()".
2025-07-10 04:59:06 -04:00
if (!(srv = server_find(be, svname))) {
MINOR: server: split the server deletion code in two parts We'll need to be able to verify whether or not a server may be deleted. For now, both the verification and the action are performed in the same function, at once under thread isolation. The goal here is to extract the verification code into a new function that will perform these checks, return a status between success/recoverable/non-recoverable failure, and will also return a message for the caller.
2024-02-09 13:28:13 -05:00
msg = "No such server.";
goto leave;
}
if (srv->flags & SRV_F_NON_PURGEABLE) {
msg = "This server cannot be removed at runtime due to other configuration elements pointing to it.";
goto leave;
}
/* Only servers in maintenance can be deleted. This ensures that the
* server is not present anymore in the lb structures (through
* lbprm.set_server_status_down).
*/
if (!(srv->cur_admin & SRV_ADMF_MAINT)) {
msg = "Only servers in maintenance mode can be deleted.";
goto leave;
}
/* Second, conditions that may change over time */
ret = 0;
MAJOR: server: do not remove idle conns in del server Do not remove anymore idle and purgeable connections directly under the "del server" handler. The main objective of this patch is to reduce the amount of work performed under thread isolation. This should improve "del server" scheduling with other haproxy tasks. Another objective is to be able to properly support dynamic servers with QUIC. Indeed, takeover is not yet implemented for this protocol, hence it is not possible to rely on cleanup of idle connections performed by a single thread under "del server" handler. With this change it is not possible anymore to remove a server if there is still idle connections referencing it. To ensure this cannot be performed, srv_check_for_deletion() has been extended to check server counters for idle and idle private connections. Server deletion should still remain a viable procedure, as first it is mandatory to put the targetted server into maintenance. This step forces the cleanup of its existing idle connections. Thanks to a recent change, all finishing connections are also removed immediately instead of becoming idle. In short, this patch transforms idle connections removal from a synchronous to an asynchronous procedure. However, this should remain a steadfast and quick method achievable in less than a second. This patch is considered major as some users may notice this change when removing a server. In particular with the following CLI commands pipeline: "disable server <X>; shutdown sessions server <X>; del server <X>" Server deletion will now probably fail, as idle connections purge cannot be completed immediately. Thus, it is now highly advise to always use a small delay "wait srv-removable" before "del server" to ensure that idle connections purge is executed prior. Along with this change, documentation for "del server" and related "shutdown sessions server" has been refined, in particular to better highlight under what conditions a server can be removed.
2025-08-01 11:51:16 -04:00
/* Ensure that there is no active/pending/idle connection on the server.
* Note that idle conns scheduled for purging are still accounted in idle counter.
*/
CLEANUP: server: make it clear that srv_check_for_deletion() is thread-safe This function was marked as requiring thread isolation because its code was extracted from cli_parse_delete_server() and was running under isolation. But upon closer inspection, and using atomic loads to check a few counters, it is actually safe to run without isolation, so let's reflect that in its description. However, it remains true that cli_parse_delete_server() continues to call it under isolation.
2025-03-18 06:38:56 -04:00
if (_HA_ATOMIC_LOAD(&srv->curr_used_conns) ||
MAJOR: server: do not remove idle conns in del server Do not remove anymore idle and purgeable connections directly under the "del server" handler. The main objective of this patch is to reduce the amount of work performed under thread isolation. This should improve "del server" scheduling with other haproxy tasks. Another objective is to be able to properly support dynamic servers with QUIC. Indeed, takeover is not yet implemented for this protocol, hence it is not possible to rely on cleanup of idle connections performed by a single thread under "del server" handler. With this change it is not possible anymore to remove a server if there is still idle connections referencing it. To ensure this cannot be performed, srv_check_for_deletion() has been extended to check server counters for idle and idle private connections. Server deletion should still remain a viable procedure, as first it is mandatory to put the targetted server into maintenance. This step forces the cleanup of its existing idle connections. Thanks to a recent change, all finishing connections are also removed immediately instead of becoming idle. In short, this patch transforms idle connections removal from a synchronous to an asynchronous procedure. However, this should remain a steadfast and quick method achievable in less than a second. This patch is considered major as some users may notice this change when removing a server. In particular with the following CLI commands pipeline: "disable server <X>; shutdown sessions server <X>; del server <X>" Server deletion will now probably fail, as idle connections purge cannot be completed immediately. Thus, it is now highly advise to always use a small delay "wait srv-removable" before "del server" to ensure that idle connections purge is executed prior. Along with this change, documentation for "del server" and related "shutdown sessions server" has been refined, in particular to better highlight under what conditions a server can be removed.
2025-08-01 11:51:16 -04:00
_HA_ATOMIC_LOAD(&srv->queueslength) || srv_has_streams(srv) ||
_HA_ATOMIC_LOAD(&srv->curr_idle_conns) || _HA_ATOMIC_LOAD(&srv->curr_sess_idle_conns)) {
MINOR: server: split the server deletion code in two parts We'll need to be able to verify whether or not a server may be deleted. For now, both the verification and the action are performed in the same function, at once under thread isolation. The goal here is to extract the verification code into a new function that will perform these checks, return a status between success/recoverable/non-recoverable failure, and will also return a message for the caller.
2024-02-09 13:28:13 -05:00
msg = "Server still has connections attached to it, cannot remove it.";
goto leave;
}
/* OK, let's go */
ret = 1;
leave:
if (pb)
*pb = be;
if (ps)
*ps = srv;
if (pm)
*pm = msg;
return ret;
}
MINOR: server: implement delete server cli command Implement a new CLI command 'del server'. It can be used to removed a dynamically added server. Only servers in maintenance mode can be removed, and without pending/active/idle connection on it. Add a new reg-test for this feature. The scenario of the reg-test need to first add a dynamic server. It is then deleted and a client is used to ensure that the server is non joinable. The management doc is updated with the new command 'del server'.
2021-04-15 08:41:20 -04:00
/* Parse a "del server" command
* Returns 0 if the server has been successfully initialized, 1 on failure.
*/
static int cli_parse_delete_server(char **args, char *payload, struct appctx *appctx, void *private)
{
struct proxy *be;
struct server *srv;
MINOR: proxy: simplify parsing 'backend/server' Several CLI handlers use a server argument specified with the format '<backend>/<server>'. The parsing of this arguement is done in two steps, first splitting the string with '/' delimiter and then use get_backend_server() to retrieve the server instance. Refactor this code sections with the following changes : * splitting is reimplented using ist API * get_backend_server() is removed. Instead use the already existing proxy_be_by_name() then server_find_by_name() which contains duplicated code with the now removed function. No functional change occurs with this commit. However, it will be useful to add new configuration options reusing the same '<backend>/<server>' for reverse connect.
2023-08-07 10:24:24 -04:00
struct ist be_name, sv_name;
BUG/MEDIUM: stats/server: use watcher to track server during stats dump If a server A is deleted while a stats dump is currently on it, deletion is delayed thanks to reference counting. Server A is nonetheless removed from the proxy list. However, this list is a single linked list. If the next server B is deleted and freed immediately, server A would still point to it. This problem has been solved by the prev_deleted list in servers. This model seems correct, but it is difficult to ensure completely its validity. In particular, it implies when stats dump is resumed, server A elements will be accessed despite the server being in a half-deleted state. Thus, it has been decided to completely ditch the refcount mechanism for stats dump. Instead, use the watcher element to register every stats dump currently tracking a server instance. Each time a server is deleted on the CLI, each stats dump element which may points to it are updated to access the next server instance, or NULL if this is the last server. This ensures that a server which was deleted via CLI but not completely freed is never accessed on stats dump resumption. Currently, no race condition related to dynamic servers and stats dump is known. However, as described above, the previous model is deemed too fragile, as such this patch is labelled as bug-fix. It should be backported up to 2.6, after a reasonable period of observation. It relies on the following patch : MINOR: list: define a watcher type
2024-10-23 05:33:34 -04:00
struct watcher *srv_watch;
MINOR: server: split the server deletion code in two parts We'll need to be able to verify whether or not a server may be deleted. For now, both the verification and the action are performed in the same function, at once under thread isolation. The goal here is to extract the verification code into a new function that will perform these checks, return a status between success/recoverable/non-recoverable failure, and will also return a message for the caller.
2024-02-09 13:28:13 -05:00
const char *msg;
MAJOR: server: do not remove idle conns in del server Do not remove anymore idle and purgeable connections directly under the "del server" handler. The main objective of this patch is to reduce the amount of work performed under thread isolation. This should improve "del server" scheduling with other haproxy tasks. Another objective is to be able to properly support dynamic servers with QUIC. Indeed, takeover is not yet implemented for this protocol, hence it is not possible to rely on cleanup of idle connections performed by a single thread under "del server" handler. With this change it is not possible anymore to remove a server if there is still idle connections referencing it. To ensure this cannot be performed, srv_check_for_deletion() has been extended to check server counters for idle and idle private connections. Server deletion should still remain a viable procedure, as first it is mandatory to put the targetted server into maintenance. This step forces the cleanup of its existing idle connections. Thanks to a recent change, all finishing connections are also removed immediately instead of becoming idle. In short, this patch transforms idle connections removal from a synchronous to an asynchronous procedure. However, this should remain a steadfast and quick method achievable in less than a second. This patch is considered major as some users may notice this change when removing a server. In particular with the following CLI commands pipeline: "disable server <X>; shutdown sessions server <X>; del server <X>" Server deletion will now probably fail, as idle connections purge cannot be completed immediately. Thus, it is now highly advise to always use a small delay "wait srv-removable" before "del server" to ensure that idle connections purge is executed prior. Along with this change, documentation for "del server" and related "shutdown sessions server" has been refined, in particular to better highlight under what conditions a server can be removed.
2025-08-01 11:51:16 -04:00
int ret;
MINOR: server: implement delete server cli command Implement a new CLI command 'del server'. It can be used to removed a dynamically added server. Only servers in maintenance mode can be removed, and without pending/active/idle connection on it. Add a new reg-test for this feature. The scenario of the reg-test need to first add a dynamic server. It is then deleted and a client is used to ensure that the server is non joinable. The management doc is updated with the new command 'del server'.
2021-04-15 08:41:20 -04:00
if (!cli_has_level(appctx, ACCESS_LVL_ADMIN))
return 1;
++args;
/* The proxy servers list is currently not protected by a lock so this
MEDIUM: servers: make the server deletion code run under full thread isolation In 2.4, runtime server deletion was brought by commit e558043e1 ("MINOR: server: implement delete server cli command"). A comment remained in the code about a theoretical race between the thread_isolate() call and another thread being in the process of allocating memory before accessing the server via a reference that was grabbed before the memory allocation, since the thread_harmless_now()/thread_harmless_end() pair around mmap() may have the effect of allowing cli_parse_delete_server() to proceed. Now that the full thread isolation is available, let's update the code to rely on this. Now it is guaranteed that competing threads will either be in the poller or queued in front of thread_isolate_full(). This may be backported to 2.4 if any report of breakage suggests the bug really exists, in which case the two following patches will also be needed: MINOR: threads: make thread_release() not wait for other ones to complete MEDIUM: threads: add a stronger thread_isolate_full() call
2021-08-04 08:42:37 -04:00
* requires thread isolation. In addition, any place referencing the
* server about to be deleted would be unsafe after our operation, so
* we must be certain to be alone so that no other thread has even
* started to grab a temporary reference to this server.
MINOR: server: implement delete server cli command Implement a new CLI command 'del server'. It can be used to removed a dynamically added server. Only servers in maintenance mode can be removed, and without pending/active/idle connection on it. Add a new reg-test for this feature. The scenario of the reg-test need to first add a dynamic server. It is then deleted and a client is used to ensure that the server is non joinable. The management doc is updated with the new command 'del server'.
2021-04-15 08:41:20 -04:00
*/
MEDIUM: servers: make the server deletion code run under full thread isolation In 2.4, runtime server deletion was brought by commit e558043e1 ("MINOR: server: implement delete server cli command"). A comment remained in the code about a theoretical race between the thread_isolate() call and another thread being in the process of allocating memory before accessing the server via a reference that was grabbed before the memory allocation, since the thread_harmless_now()/thread_harmless_end() pair around mmap() may have the effect of allowing cli_parse_delete_server() to proceed. Now that the full thread isolation is available, let's update the code to rely on this. Now it is guaranteed that competing threads will either be in the poller or queued in front of thread_isolate_full(). This may be backported to 2.4 if any report of breakage suggests the bug really exists, in which case the two following patches will also be needed: MINOR: threads: make thread_release() not wait for other ones to complete MEDIUM: threads: add a stronger thread_isolate_full() call
2021-08-04 08:42:37 -04:00
thread_isolate_full();
MINOR: server: implement delete server cli command Implement a new CLI command 'del server'. It can be used to removed a dynamically added server. Only servers in maintenance mode can be removed, and without pending/active/idle connection on it. Add a new reg-test for this feature. The scenario of the reg-test need to first add a dynamic server. It is then deleted and a client is used to ensure that the server is non joinable. The management doc is updated with the new command 'del server'.
2021-04-15 08:41:20 -04:00
MINOR: proxy: simplify parsing 'backend/server' Several CLI handlers use a server argument specified with the format '<backend>/<server>'. The parsing of this arguement is done in two steps, first splitting the string with '/' delimiter and then use get_backend_server() to retrieve the server instance. Refactor this code sections with the following changes : * splitting is reimplented using ist API * get_backend_server() is removed. Instead use the already existing proxy_be_by_name() then server_find_by_name() which contains duplicated code with the now removed function. No functional change occurs with this commit. However, it will be useful to add new configuration options reusing the same '<backend>/<server>' for reverse connect.
2023-08-07 10:24:24 -04:00
sv_name = ist(args[1]);
be_name = istsplit(&sv_name, '/');
if (!istlen(sv_name)) {
BUG/MINOR: server/cli: add missing LF at the end of certain notice/error lines Some cli_err(), cli_msg() or even ha_error() etc are missing the trailing LF, which breaks the continuity of the CLI parsing: the extra LF that serves to mark the end of the command is in fact taken as the missing LF and no extra one is added. This patch adds the missing LF on identified messages. It might be worth trying to proceed in a more generic way with this, given the amount of code that is possibly at risk.
2024-02-08 11:43:14 -05:00
cli_err(appctx, "Require 'backend/server'.\n");
MINOR: server: implement delete server cli command Implement a new CLI command 'del server'. It can be used to removed a dynamically added server. Only servers in maintenance mode can be removed, and without pending/active/idle connection on it. Add a new reg-test for this feature. The scenario of the reg-test need to first add a dynamic server. It is then deleted and a client is used to ensure that the server is non joinable. The management doc is updated with the new command 'del server'.
2021-04-15 08:41:20 -04:00
goto out;
}
MINOR: server: split the server deletion code in two parts We'll need to be able to verify whether or not a server may be deleted. For now, both the verification and the action are performed in the same function, at once under thread isolation. The goal here is to extract the verification code into a new function that will perform these checks, return a status between success/recoverable/non-recoverable failure, and will also return a message for the caller.
2024-02-09 13:28:13 -05:00
ret = srv_check_for_deletion(ist0(be_name), ist0(sv_name), &be, &srv, &msg);
if (ret <= 0) {
/* failure (recoverable or not) */
cli_err(appctx, msg);
MINOR: server: implement delete server cli command Implement a new CLI command 'del server'. It can be used to removed a dynamically added server. Only servers in maintenance mode can be removed, and without pending/active/idle connection on it. Add a new reg-test for this feature. The scenario of the reg-test need to first add a dynamic server. It is then deleted and a client is used to ensure that the server is non joinable. The management doc is updated with the new command 'del server'.
2021-04-15 08:41:20 -04:00
goto out;
}
MINOR: server/event_hdl: add support for SERVER_ADD and SERVER_DEL events Basic support for ADD and DEL server events are added through this commit: SERVER_ADD is published on dynamic server addition through cli. SERVER_DEL is published on dynamic server deletion through cli. This work depends on: "MINOR: event_hdl: add event handler base api" "MINOR: server: add srv->rid (revision id) value"
2022-11-17 04:37:58 -05:00
/* removing cannot fail anymore when we reach this:
* publishing EVENT_HDL_SUB_SERVER_DEL
*/
srv_event_hdl_publish(EVENT_HDL_SUB_SERVER_DEL, srv, 1);
MEDIUM: server: support track keyword for dynamic servers Allow the usage of the 'track' keyword for dynamic servers. On server deletion, the server is properly removed from the tracking chain to prevents NULL pointer dereferencing.
2021-07-13 04:36:03 -04:00
/* remove srv from tracking list */
if (srv->track)
release_server_track(srv);
MEDIUM: server: implement check for dynamic servers Implement check support for dynamic servers. The "check" keyword is now enabled for dynamic servers. If used, the server check is initialized and the check task started in the "add server" CLI handler. The check is explicitely disabled and must be manually activated via "enable health" CLI handler. The dynamic server refcount is incremented if a check is configured. On "delete server" handler, the check is purged, which decrements the refcount.
2021-07-22 10:04:59 -04:00
/* stop the check task if running */
if (srv->check.state & CHK_ST_CONFIGURED)
check_purge(&srv->check);
BUG/MEDIUM: server: support both check/agent-check on a dynamic instance A static server is able to support simultaneously both health chech and agent-check. Adjust the dynamic server CLI handlers to also support this configuration. This should not be backported, unless dynamic server checks are backported.
2021-08-10 10:24:36 -04:00
if (srv->agent.state & CHK_ST_CONFIGURED)
MEDIUM: server: implement agent check for dynamic servers This commit is the counterpart for agent check of "MEDIUM: server: implement check for dynamic servers". The "agent-check" keyword is enabled for dynamic servers. The agent check must manually be activated via "enable agent" CLI. This can enable the dynamic server if the agent response is "ready" without an explicit "enable server" CLI.
2021-08-04 05:33:14 -04:00
check_purge(&srv->agent);
MINOR: server: implement delete server cli command Implement a new CLI command 'del server'. It can be used to removed a dynamically added server. Only servers in maintenance mode can be removed, and without pending/active/idle connection on it. Add a new reg-test for this feature. The scenario of the reg-test need to first add a dynamic server. It is then deleted and a client is used to ensure that the server is non joinable. The management doc is updated with the new command 'del server'.
2021-04-15 08:41:20 -04:00
BUG/MINOR: server: perform lbprm deinit for dynamic servers Last commit 7361515 ("BUG/MINOR: server: dont depend on proxy for server cleanup in srv_drop()") introduced a regression because the lbprm server_deinit is not evaluated anymore with dynamic servers, possibly resulting in a memory leak. To fix the issue, in addition to free_proxy(), the server deinit check should be manually performed in cli_parse_delete_server() as well. No backport needed.
2025-05-12 10:27:43 -04:00
if (srv->proxy->lbprm.server_deinit)
srv->proxy->lbprm.server_deinit(srv);
BUG/MEDIUM: stats/server: use watcher to track server during stats dump If a server A is deleted while a stats dump is currently on it, deletion is delayed thanks to reference counting. Server A is nonetheless removed from the proxy list. However, this list is a single linked list. If the next server B is deleted and freed immediately, server A would still point to it. This problem has been solved by the prev_deleted list in servers. This model seems correct, but it is difficult to ensure completely its validity. In particular, it implies when stats dump is resumed, server A elements will be accessed despite the server being in a half-deleted state. Thus, it has been decided to completely ditch the refcount mechanism for stats dump. Instead, use the watcher element to register every stats dump currently tracking a server instance. Each time a server is deleted on the CLI, each stats dump element which may points to it are updated to access the next server instance, or NULL if this is the last server. This ensures that a server which was deleted via CLI but not completely freed is never accessed on stats dump resumption. Currently, no race condition related to dynamic servers and stats dump is known. However, as described above, the previous model is deemed too fragile, as such this patch is labelled as bug-fix. It should be backported up to 2.6, after a reasonable period of observation. It relies on the following patch : MINOR: list: define a watcher type
2024-10-23 05:33:34 -04:00
while (!MT_LIST_ISEMPTY(&srv->watcher_list)) {
srv_watch = MT_LIST_NEXT(&srv->watcher_list, struct watcher *, el);
BUG_ON(srv->next && srv->next->flags & SRV_F_DELETED);
watcher_next(srv_watch, srv->next);
}
MINOR: server: implement delete server cli command Implement a new CLI command 'del server'. It can be used to removed a dynamically added server. Only servers in maintenance mode can be removed, and without pending/active/idle connection on it. Add a new reg-test for this feature. The scenario of the reg-test need to first add a dynamic server. It is then deleted and a client is used to ensure that the server is non joinable. The management doc is updated with the new command 'del server'.
2021-04-15 08:41:20 -04:00
/* detach the server from the proxy linked list
* The proxy servers list is currently not protected by a lock, so this
* requires thread_isolate/release.
*/
MEDIUM: server: automatically add server to proxy list in new_server() while new_server() takes the parent proxy as argument and even assigns srv->proxy to the parent proxy, it didn't actually inserted the server to the parent proxy server list on success. The result is that sometimes we add the server to the list after new_server() is called, and sometimes we don't. This is really error-prone and because of that hooks such as REGISTER_POST_SERVER_CHECK() which as run for all servers listed in all proxies may not be relied upon for servers which are not actually inserted in their parent proxy server list. Plus it feels very strange to have a server that points to a proxy, but then the proxy doesn't know about it because it cannot find it in its server list. To prevent errors and make proxy->srv list reliable, we move the insertion logic directly under new_server(). This requires to know if we are called during parsing or during runtime to either insert or append the server to the parent proxy list. For that we use PR_FL_CHECKED flag from the parent proxy (if the flag is set, then the proxy was checked so we are past the init phase, thus we assume we are called during runtime) This implies that during startup if new_server() has to be cancelled on error paths we need to call srv_detach() (which is now exposed in server.h) before srv_drop(). The consequence of this commit is that REGISTER_POST_SERVER_CHECK() should not run reliably on all servers created using new_server() (without having to manually loop on global servers_list)
2025-05-09 13:24:55 -04:00
srv_detach(srv);
MINOR: server: implement delete server cli command Implement a new CLI command 'del server'. It can be used to removed a dynamically added server. Only servers in maintenance mode can be removed, and without pending/active/idle connection on it. Add a new reg-test for this feature. The scenario of the reg-test need to first add a dynamic server. It is then deleted and a client is used to ensure that the server is non joinable. The management doc is updated with the new command 'del server'.
2021-04-15 08:41:20 -04:00
MINOR: server: take proxy refcount when deleting a server When a server is deleted via "del server", increment refcount of its parent backend. This is necessary as the server is not referenced anymore in the backend, but can still access it via its own <proxy> member. Thus, backend removal must not happen until the complete purge of the server. The proxy refcount is released in srv_drop() if the flag SRV_F_DELETED is set, which indicates that "del server" was used. This operation is performed after the complete release of the server instance to ensure no access will be performed on the proxy via itself. The refcount must not be decremented if a server is freed without "del server" invokation. Another solution could be for servers to always increment the refcount. However, for now in haproxy refcount usage is limited, so the current approach is preferred. It should also ensure that if the refcount is still incremented, it may indicate that some servers are not completely purged themselves. Note that this patch may cause issues if "del backend" are used in parallel with LUA scripts referencing servers. Currently, any servers referenced by LUA must be released by its garbage collector to ensure it can be finally freed. However, it appeas that in some case the gc does not run for several minutes. At least this has been observed with Lua version 5.4.8. In the end, this will result in indefinitely blocking of "del backend" commands.
2026-01-06 10:28:36 -05:00
/* Mark the server as being deleted (ie removed from its proxy list)
* but not yet purged from memory. Any module still referencing this
* server must manipulate it with precaution and are expected to
* release its refcount as soon as possible.
*/
srv->flags |= SRV_F_DELETED;
/* Inc proxy refcount until the server is finally freed. */
proxy_take(srv->proxy);
MINOR: server: implement delete server cli command Implement a new CLI command 'del server'. It can be used to removed a dynamically added server. Only servers in maintenance mode can be removed, and without pending/active/idle connection on it. Add a new reg-test for this feature. The scenario of the reg-test need to first add a dynamic server. It is then deleted and a client is used to ensure that the server is non joinable. The management doc is updated with the new command 'del server'.
2021-04-15 08:41:20 -04:00
/* remove srv from addr_node tree */
MEDIUM: server: index server ID using compact trees The server ID is currently stored as a 32-bit int using an eb32 tree. It's used essentially to find holes in order to automatically assign IDs, and to detect duplicates. Let's change this to use compact trees instead in order to save 24 bytes in struct server for this node, plus 8 bytes in struct proxy. The server struct is still 3904 bytes large (due to alignment) and the proxy struct is 3072.
2025-08-24 05:21:02 -04:00
ceb32_item_delete(&be->conf.used_server_id, conf.puid_node, puid, srv);
MEDIUM: server: switch conf.name to cebis_tree This is used to index the server name and it contains a copy of the pointer to the server's name in <id>. Changing that for a ceb_node placed just before <id> saves 32 bytes to the struct server, which remains 3968 bytes large due to alignment. The proxy struct shrinks by 8 bytes to 3144. It's worth noting that the current way duplicate names are handled remains based on the previous mechanism where dups were permitted. Ideally we should now reject them during insertion and use unique key trees instead.
2025-07-07 09:33:40 -04:00
cebis_item_delete(&be->conf.used_server_name, conf.name_node, id, srv);
MEDIUM: server: switch addr_node to cebis_tree This contains the text representation of the server's address, for use with stick-tables with "srvkey addr". Switching them to a compact node saves 24 more bytes from this structure. The key was moved to an external pointer "addr_key" right after the node. The server struct is now 3968 bytes (down from 4032) due to alignment, and the proxy struct shrinks by 8 bytes to 3152.
2025-07-07 09:13:15 -04:00
cebuis_item_delete(&be->used_server_addr, addr_node, addr_key, srv);
MINOR: server: implement delete server cli command Implement a new CLI command 'del server'. It can be used to removed a dynamically added server. Only servers in maintenance mode can be removed, and without pending/active/idle connection on it. Add a new reg-test for this feature. The scenario of the reg-test need to first add a dynamic server. It is then deleted and a client is used to ensure that the server is non joinable. The management doc is updated with the new command 'del server'.
2021-04-15 08:41:20 -04:00
/* remove srv from idle_node tree for idle conn cleanup */
eb32_delete(&srv->idle_node);
MINOR: server: add srv->rid (revision id) value With current design, we could not distinguish between previously existing deleted server and a new server reusing the deleted server name/id. This can cause some confusion when auditing stats/events/logs, because the new server will look similar to the old one. To address this, we're adding a new value in server structure: rid rid (revision id) value is an unsigned 32bits value that is set upon server creation. Value is derived from a global counter that starts at 0 and is incremented each time one or multiple server deletions are followed by a server addition (meaning that old name/id reuse could occur). Thanks to this revision id, it is now easy to tell whether the server we're looking at is the same as before or if it has been deleted and re-added in the meantime. (combining server name/id + server revision id yields a process-wide unique identifier)
2022-11-17 10:10:35 -05:00
/* set LSB bit (odd bit) for reuse_cnt */
srv_id_reuse_cnt |= 1;
MINOR: server: implement delete server cli command Implement a new CLI command 'del server'. It can be used to removed a dynamically added server. Only servers in maintenance mode can be removed, and without pending/active/idle connection on it. Add a new reg-test for this feature. The scenario of the reg-test need to first add a dynamic server. It is then deleted and a client is used to ensure that the server is non joinable. The management doc is updated with the new command 'del server'.
2021-04-15 08:41:20 -04:00
thread_release();
MINOR: server: use ha_alert in server parsing functions Replace memprintf usage in _srv_parse* functions by ha_alert calls. This has the advantage to simplify the function prototype by removing an extra char** argument. As a consequence, the CLI handler of 'add server' is updated to output the user messages buffers if not empty.
2021-05-28 10:35:05 -04:00
ha_notice("Server deleted.\n");
MEDIUM: server: extend refcount for all servers In a future patch, it will be possible to remove at runtime every servers, both static and dynamic. This requires to extend the server refcount for all instances. First, refcount manipulation functions have been renamed to better express the API usage. * srv_refcount_use -> srv_take The refcount is always initialize to 1 on the server creation in new_server. It's also incremented for each check/agent configured on a server instance. * free_server -> srv_drop This decrements the refcount and if null, the server is freed, so code calling it must not use the server reference after it. As a bonus, this function now returns the next server instance. This is useful when calling on the server loop without having to save the next pointer before each invocation. In these functions, remove the checks that prevent refcount on non-dynamic servers. Each reference to "dynamic" in variable/function naming have been eliminated as well.
2021-08-25 09:34:53 -04:00
srv_drop(srv);
MINOR: server: implement delete server cli command Implement a new CLI command 'del server'. It can be used to removed a dynamically added server. Only servers in maintenance mode can be removed, and without pending/active/idle connection on it. Add a new reg-test for this feature. The scenario of the reg-test need to first add a dynamic server. It is then deleted and a client is used to ensure that the server is non joinable. The management doc is updated with the new command 'del server'.
2021-04-15 08:41:20 -04:00
BUG/MINOR: server/cli: add missing LF at the end of certain notice/error lines Some cli_err(), cli_msg() or even ha_error() etc are missing the trailing LF, which breaks the continuity of the CLI parsing: the extra LF that serves to mark the end of the command is in fact taken as the missing LF and no extra one is added. This patch adds the missing LF on identified messages. It might be worth trying to proceed in a more generic way with this, given the amount of code that is possibly at risk.
2024-02-08 11:43:14 -05:00
cli_msg(appctx, LOG_INFO, "Server deleted.\n");
MINOR: server: implement delete server cli command Implement a new CLI command 'del server'. It can be used to removed a dynamically added server. Only servers in maintenance mode can be removed, and without pending/active/idle connection on it. Add a new reg-test for this feature. The scenario of the reg-test need to first add a dynamic server. It is then deleted and a client is used to ensure that the server is non joinable. The management doc is updated with the new command 'del server'.
2021-04-15 08:41:20 -04:00
return 0;
out:
thread_release();
return 1;
}
REORG: cli: move 'set server' to server.c Move 'set server' CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-18 20:00:33 -05:00
/* register cli keywords */
static struct cli_kw_list cli_kws = {{ },{
MINOR: server: unmark deprecated on enable health/agent cli Remove the "DEPRECATED" marker on "enable/disable health/agent" commands. Their purpose is to toggle the check/agent on a server. These commands are still useful because their purpose is not covered by the "set server" command. Most there was confusion with the commands 'set server health/agent', which in fact serves another goal. Note that the indication "use 'set server' instead" has been added since 2016 on the commit 2c04eda8b58636ad2ae44e42b1f50f3b5a24a642 REORG: cli: move "{enable|disable} health" to server.c and 58d9cb7d22c1b0d8239543443131e3e3658375d0 REORG: cli: move "{enable|disable} agent" to server.c Besides, these commands will become required to enable check/agent on dynamic servers which will be created with check disabled. This should be backported up to 2.4.
2021-08-03 12:05:37 -04:00
{ { "disable", "agent", NULL }, "disable agent : disable agent checks", cli_parse_disable_agent, NULL },
{ { "disable", "health", NULL }, "disable health : disable health checks", cli_parse_disable_health, NULL },
CLEANUP: cli/tree-wide: properly re-align the CLI commands' help messages There were 102 CLI commands whose help were zig-zagging all along the dump making them unreadable. This patch realigns all these messages so that the command now uses up to 40 characters before the delimiting colon. About a third of the commands did not correctly list their arguments which were added after the first version, so they were all updated. Some abuses of the term "id" were fixed to use a more explanatory term. The "set ssl ocsp-response" command was not listed because it lacked a help message, this was fixed as well. The deprecated enable/disable commands for agent/health/server were prominently written as deprecated. Whenever possible, clearer explanations were provided.
2021-05-07 05:38:37 -04:00
{ { "disable", "server", NULL }, "disable server (DEPRECATED) : disable a server for maintenance (use 'set server' instead)", cli_parse_disable_server, NULL },
MINOR: server: unmark deprecated on enable health/agent cli Remove the "DEPRECATED" marker on "enable/disable health/agent" commands. Their purpose is to toggle the check/agent on a server. These commands are still useful because their purpose is not covered by the "set server" command. Most there was confusion with the commands 'set server health/agent', which in fact serves another goal. Note that the indication "use 'set server' instead" has been added since 2016 on the commit 2c04eda8b58636ad2ae44e42b1f50f3b5a24a642 REORG: cli: move "{enable|disable} health" to server.c and 58d9cb7d22c1b0d8239543443131e3e3658375d0 REORG: cli: move "{enable|disable} agent" to server.c Besides, these commands will become required to enable check/agent on dynamic servers which will be created with check disabled. This should be backported up to 2.4.
2021-08-03 12:05:37 -04:00
{ { "enable", "agent", NULL }, "enable agent : enable agent checks", cli_parse_enable_agent, NULL },
{ { "enable", "health", NULL }, "enable health : enable health checks", cli_parse_enable_health, NULL },
CLEANUP: cli/tree-wide: properly re-align the CLI commands' help messages There were 102 CLI commands whose help were zig-zagging all along the dump making them unreadable. This patch realigns all these messages so that the command now uses up to 40 characters before the delimiting colon. About a third of the commands did not correctly list their arguments which were added after the first version, so they were all updated. Some abuses of the term "id" were fixed to use a more explanatory term. The "set ssl ocsp-response" command was not listed because it lacked a help message, this was fixed as well. The deprecated enable/disable commands for agent/health/server were prominently written as deprecated. Whenever possible, clearer explanations were provided.
2021-05-07 05:38:37 -04:00
{ { "enable", "server", NULL }, "enable server (DEPRECATED) : enable a disabled server (use 'set server' instead)", cli_parse_enable_server, NULL },
{ { "set", "maxconn", "server", NULL }, "set maxconn server <bk>/<srv> : change a server's maxconn setting", cli_parse_set_maxconn_server, NULL },
{ { "set", "server", NULL }, "set server <bk>/<srv> [opts] : change a server's state, weight, address or ssl", cli_parse_set_server },
{ { "get", "weight", NULL }, "get weight <bk>/<srv> : report a server's current weight", cli_parse_get_weight },
{ { "set", "weight", NULL }, "set weight <bk>/<srv> (DEPRECATED) : change a server's weight (use 'set server' instead)", cli_parse_set_weight },
MINOR: server: define CLI I/O handler for "add server" Extend "add server" to support an IO handler function named cli_io_handler_add_server(). A context object is also defined whose usage will depend on IO handler capabilities. IO handler is skipped when "add server" is run in default mode, i.e. on a dynamic server creation. Thus, currently IO handler is unneeded. However, it will become useful to support sub-commands for "add server". Note that return value of "add server" parser has been changed on server creation success. Previously, it was used incorrectly to report if server was inserted or not. In fact, parser return value is used by CLI generic code to detect if command processing has been completed, or should continue to the IO handler. Now, "add server" always returns 1 to signal that CLI processing is completed. This is necessary to preserve CLI output emitted by parser, even now that IO handler is defined for the command. Previously, output was emitted in every situations due to IO handler not defined. See below code snippet from cli.c for a better overview : if (kw->parse && kw->parse(args, payload, appctx, kw->private) != 0) { ret = 1; goto fail; } /* kw->parse could set its own io_handler or io_release handler */ if (!appctx->cli_ctx.io_handler) { ret = 1; goto fail; } appctx->st0 = CLI_ST_CALLBACK; ret = 1; goto end;
2025-05-22 11:07:59 -04:00
{ { "add", "server", NULL }, "add server <bk>/<srv> : create a new server", cli_parse_add_server, cli_io_handler_add_server },
MEDIUM: server: remove experimental-mode for dynamic servers Dynamic servers feature is now judged to be stable enough. Remove the experimental-mode requirement for "add/del server" commands. This should facilitate dynamic servers adoption.
2022-03-09 09:07:31 -05:00
{ { "del", "server", NULL }, "del server <bk>/<srv> : remove a dynamically added server", cli_parse_delete_server, NULL },
REORG: cli: move 'set server' to server.c Move 'set server' CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-18 20:00:33 -05:00
{{},}
}};
MEDIUM: init: convert all trivial registration calls to initcalls This switches explicit calls to various trivial registration methods for keywords, muxes or protocols from constructors to INITCALL1 at stage STG_REGISTER. All these calls have in common to consume a single pointer and return void. Doing this removes 26 constructors. The following calls were addressed : - acl_register_keywords - bind_register_keywords - cfg_register_keywords - cli_register_kw - flt_register_keywords - http_req_keywords_register - http_res_keywords_register - protocol_register - register_mux_proto - sample_register_convs - sample_register_fetches - srv_register_keywords - tcp_req_conn_keywords_register - tcp_req_cont_keywords_register - tcp_req_sess_keywords_register - tcp_res_cont_keywords_register - flt_register_keywords
2018-11-25 13:14:37 -05:00
INITCALL1(STG_REGISTER, cli_register_kw, &cli_kws);
REORG: cli: move 'set server' to server.c Move 'set server' CLI functions to server.c and use the cli keyword API to register it on the CLI.
2016-11-18 20:00:33 -05:00
MINOR: srv: extract tracking server config function Extract the post-config tracking setup in a dedicated function srv_apply_track. This will be useful to implement track support for dynamic servers.
2021-07-13 04:35:23 -04:00
/* Prepare a server <srv> to track check status of another one. <srv>.<trackit>
* field is used to retrieve the identifier of the tracked server, either with
* the format "proxy/server" or just "server". <curproxy> must point to the
* backend owning <srv>; if no proxy is specified in <trackit>, it will be used
* to find the tracked server.
*
* Returns 0 if the server track has been activated else non-zero.
*
* Not thread-safe.
*/
int srv_apply_track(struct server *srv, struct proxy *curproxy)
{
struct proxy *px;
struct server *strack, *loop;
char *pname, *sname;
if (!srv->trackit)
return 1;
pname = srv->trackit;
sname = strrchr(pname, '/');
if (sname) {
*sname++ = '\0';
}
else {
sname = pname;
pname = NULL;
}
if (pname) {
px = proxy_be_by_name(pname);
if (!px) {
ha_alert("unable to find required proxy '%s' for tracking.\n",
pname);
return 1;
}
}
else {
px = curproxy;
}
CLEANUP: server: rename findserver() to server_find_by_name() Now it's more logical and matches what is done in the rest of these functions. server_find() now relies on it.
2025-07-10 05:07:51 -04:00
strack = server_find_by_name(px, sname);
MINOR: srv: extract tracking server config function Extract the post-config tracking setup in a dedicated function srv_apply_track. This will be useful to implement track support for dynamic servers.
2021-07-13 04:35:23 -04:00
if (!strack) {
ha_alert("unable to find required server '%s' for tracking.\n",
sname);
return 1;
}
MINOR: srv: do not allow to track a dynamic server Prevents the use of the "track" keyword for a dynamic server. This simplifies the deletion of a dynamic server, without having to worry about servers which might tracked it. A BUG_ON is present in the dynamic server delete function to validate this assertion.
2021-07-13 04:35:50 -04:00
if (strack->flags & SRV_F_DYNAMIC) {
ha_alert("unable to use %s/%s for tracking as it is a dynamic server.\n",
px->id, strack->id);
return 1;
}
MINOR: srv: extract tracking server config function Extract the post-config tracking setup in a dedicated function srv_apply_track. This will be useful to implement track support for dynamic servers.
2021-07-13 04:35:23 -04:00
if (!strack->do_check && !strack->do_agent && !strack->track &&
!strack->trackit) {
ha_alert("unable to use %s/%s for "
"tracking as it does not have any check nor agent enabled.\n",
px->id, strack->id);
return 1;
}
for (loop = strack->track; loop && loop != srv; loop = loop->track)
;
if (srv == strack || loop) {
ha_alert("unable to track %s/%s as it "
"belongs to a tracking chain looping back to %s/%s.\n",
px->id, strack->id, px->id,
srv == strack ? strack->id : loop->id);
return 1;
}
if (curproxy != px &&
(curproxy->options & PR_O_DISABLE404) != (px->options & PR_O_DISABLE404)) {
ha_alert("unable to use %s/%s for"
"tracking: disable-on-404 option inconsistency.\n",
px->id, strack->id);
return 1;
}
srv->track = strack;
srv->tracknext = strack->trackers;
strack->trackers = srv;
MINOR: server: mark referenced servers as non purgeable Mark servers that are referenced by configuration elements as non purgeable. This includes the following list : - tracked servers - servers referenced in a use-server rule - servers referenced in a sample fetch
2021-08-23 08:05:07 -04:00
strack->flags |= SRV_F_NON_PURGEABLE;
MINOR: srv: extract tracking server config function Extract the post-config tracking setup in a dedicated function srv_apply_track. This will be useful to implement track support for dynamic servers.
2021-07-13 04:35:23 -04:00
ha_free(&srv->trackit);
return 0;
}
MINOR: server: propagate server state change to lb through single function Use a dedicated helper function to propagate server state change to lb algorithms, since it is performed at multiple places within srv_update_status() function.
2023-04-17 07:53:56 -04:00
/* This function propagates srv state change to lb algorithms */
static void srv_lb_propagate(struct server *s)
{
struct proxy *px = s->proxy;
if (px->lbprm.update_server_eweight)
px->lbprm.update_server_eweight(s);
else if (srv_willbe_usable(s)) {
if (px->lbprm.set_server_status_up)
px->lbprm.set_server_status_up(s);
}
else {
if (px->lbprm.set_server_status_down)
px->lbprm.set_server_status_down(s);
}
}
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
/* directly update server state based on an operational change
* (compare current and next state to know which transition to apply)
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
*
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
* The function returns the number of requeued sessions (either taken by
* the server or redispatched to others servers) due to the server state
* change.
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
*/
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
static int _srv_update_status_op(struct server *s, enum srv_op_st_chg_cause cause)
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
{
MAJOR: chunks: replace struct chunk with struct buffer Now all the code used to manipulate chunks uses a struct buffer instead. The functions are still called "chunk*", and some of them will progressively move to the generic buffer handling code as they are cleaned up.
2018-07-13 05:56:34 -04:00
struct buffer *tmptrash = NULL;
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
int log_level;
int srv_was_stopping = (s->cur_state == SRV_ST_STOPPING) || (s->cur_admin & SRV_ADMF_DRAIN);
int xferred = 0;
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
if ((s->cur_state != SRV_ST_STOPPED) && (s->next_state == SRV_ST_STOPPED)) {
srv_lb_propagate(s);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
if (s->onmarkeddown & HANA_ONMARKEDDOWN_SHUTDOWNSESSIONS)
srv_shutdown_streams(s, SF_ERR_DOWN);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
MEDIUM: server: Introduce the concept of path parameters Add a new field in struct server, path parameters. It will contain connection informations for the server that are not expected to change. For now, just store the ALPN negociated with the server. Each time an handhskae is done, we'll update it, even though it is not supposed to change. This will be useful when trying to send early data, that way we'll know which mux to use. Each time the server goes down or is disabled, those informations are erased, as we can't be sure those parameters will be the same once the server will be back up.
2025-09-08 16:14:42 -04:00
srv_reset_path_parameters(s);
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
/* we might have streams queued on this server and waiting for
* a connection. Those which are redispatchable will be queued
* to another server or to the proxy itself.
*/
xferred = pendconn_redistribute(s);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
tmptrash = alloc_trash_chunk();
if (tmptrash) {
chunk_printf(tmptrash,
"%sServer %s/%s is DOWN", s->flags & SRV_F_BACKUP ? "Backup " : "",
s->proxy->id, s->id);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
srv_append_op_chg_cause(tmptrash, s, cause);
srv_append_more(tmptrash, s, xferred, 0);
MINOR: server: srv_append_status refacto srv_append_status() has become a swiss-knife function over time. It is used from server code and also from checks code, with various inputs and distincts code paths, making it very hard to guess the actual behavior of the function (resulting string output). To simplify the logic behind it, we're dividing it in multiple contextual functions that take simple inputs and do explicit things, making them more predictable and easier to maintain.
2023-04-14 12:07:09 -04:00
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
ha_warning("%s.\n", tmptrash->area);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
/* we don't send an alert if the server was previously paused */
log_level = srv_was_stopping ? LOG_NOTICE : LOG_ALERT;
send_log(s->proxy, log_level, "%s.\n",
tmptrash->area);
BUG/MINOR: server: memory leak in _srv_update_status_op() on server DOWN When server is transitionning from UP to DOWN, a log message is generated. e.g.: "Server backend_name/server_name is DOWN") However since f71e064 ("MEDIUM: server: split srv_update_status() in two functions"), the allocated buffer tmptrash which is used to prepare the log message is not freed after it has been used, resulting in a small memory leak each time a server goes DOWN because of an operational change. This is a 2.8 specific bug, no backport needed unless the above commit gets backported.
2023-05-15 12:03:35 -04:00
free_trash_chunk(tmptrash);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
}
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
}
else if ((s->cur_state != SRV_ST_STOPPING) && (s->next_state == SRV_ST_STOPPING)) {
srv_lb_propagate(s);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
MEDIUM: server: Introduce the concept of path parameters Add a new field in struct server, path parameters. It will contain connection informations for the server that are not expected to change. For now, just store the ALPN negociated with the server. Each time an handhskae is done, we'll update it, even though it is not supposed to change. This will be useful when trying to send early data, that way we'll know which mux to use. Each time the server goes down or is disabled, those informations are erased, as we can't be sure those parameters will be the same once the server will be back up.
2025-09-08 16:14:42 -04:00
srv_reset_path_parameters(s);
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
/* we might have streams queued on this server and waiting for
* a connection. Those which are redispatchable will be queued
* to another server or to the proxy itself.
*/
xferred = pendconn_redistribute(s);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
tmptrash = alloc_trash_chunk();
if (tmptrash) {
chunk_printf(tmptrash,
"%sServer %s/%s is stopping", s->flags & SRV_F_BACKUP ? "Backup " : "",
s->proxy->id, s->id);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
srv_append_op_chg_cause(tmptrash, s, cause);
srv_append_more(tmptrash, s, xferred, 0);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
ha_warning("%s.\n", tmptrash->area);
send_log(s->proxy, LOG_NOTICE, "%s.\n",
tmptrash->area);
free_trash_chunk(tmptrash);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
}
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
}
else if (((s->cur_state != SRV_ST_RUNNING) && (s->next_state == SRV_ST_RUNNING))
|| ((s->cur_state != SRV_ST_STARTING) && (s->next_state == SRV_ST_STARTING))) {
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
if (s->next_state == SRV_ST_STARTING && s->warmup)
task_schedule(s->warmup, tick_add(now_ms, MS_TO_TICKS(MAX(1000, s->slowstart / 20))));
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
BUG/MEDIUM: server: Also call srv_reset_path_parameters() on srv up Also call srv_reset_path_parameters() when the server changed states, and got up. It is not enough to do it when the server goes down, because there's a small race condition, and a connection could get established just after we did it, and could have set the path parameters. This does not need to be backported.
2025-11-04 12:37:20 -05:00
srv_reset_path_parameters(s);
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
server_recalc_eweight(s, 0);
/* now propagate the status change to any LB algorithms */
srv_lb_propagate(s);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
/* If the server is set with "on-marked-up shutdown-backup-sessions",
* and it's not a backup server and its effective weight is > 0,
* then it can accept new connections, so we shut down all streams
* on all backup servers.
*/
if ((s->onmarkedup & HANA_ONMARKEDUP_SHUTDOWNBACKUPSESSIONS) &&
!(s->flags & SRV_F_BACKUP) && s->next_eweight)
srv_shutdown_backup_streams(s->proxy, SF_ERR_UP);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
BUG/MEDIUM: queues: Do not use pendconn_grab_from_px(). pendconn_grab_from_px() was called when a server was brought back up, to get some streams waiting in the proxy's queue and get them to run on the newly available server. It is very similar to process_srv_queue(), except it only goes through the proxy's queue, which can be a problem, because there is a small race condition that could lead us to add more streams to the server queue just as it's going down. If that happens, the server would just be ignored when back up by new streams, as its queue is not empty, and it would never try to process its queue. The other problem with pendconn_grab_from_px() is that it is very liberal with how it dequeues streams, and it is not very good at enforcing maxconn, it could lead to having 3*maxconn connections. For both those reasons, just get rid of pendconn_grab_from_px(), and just use process_srv_queue(). Both problems are easy to reproduce, especially on a 64 threads machine, set a maxconn to 100, inject in H2 with 1000 concurrent connections containing up to 100 streams each, and after a few seconds/minutes the max number of concurrent output streams will be much higher than maxconn, and eventually the server will stop processing connections. It may be related to github issue #2744. Note that it doesn't totally fix the problem, we can occasionally see a few more connections than maxconn, but the max that have been observed is 4 more connections, we no longer get multiple times maxconn. have more outgoing connections than maxconn, This should be backported up to 2.6.
2024-12-17 09:39:21 -05:00
/* check if we can handle some connections queued.
* We will take as many as we can handle.
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
*/
BUG/MEDIUM: queue: Make process_srv_queue return the number of streams Make process_srv_queue() return the number of streams unqueued, as pendconn_grab_from_px() did, as that number is used by srv_update_status() to generate logs. This should be backported up to 2.6 with 111ea83ed4e13ac3ab028ed5e95201a1b4aa82b8
2024-12-23 09:17:25 -05:00
xferred = process_srv_queue(s);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
tmptrash = alloc_trash_chunk();
if (tmptrash) {
chunk_printf(tmptrash,
"%sServer %s/%s is UP", s->flags & SRV_F_BACKUP ? "Backup " : "",
s->proxy->id, s->id);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
srv_append_op_chg_cause(tmptrash, s, cause);
srv_append_more(tmptrash, s, xferred, 0);
MINOR: server: srv_append_status refacto srv_append_status() has become a swiss-knife function over time. It is used from server code and also from checks code, with various inputs and distincts code paths, making it very hard to guess the actual behavior of the function (resulting string output). To simplify the logic behind it, we're dividing it in multiple contextual functions that take simple inputs and do explicit things, making them more predictable and easier to maintain.
2023-04-14 12:07:09 -04:00
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
ha_warning("%s.\n", tmptrash->area);
send_log(s->proxy, LOG_NOTICE, "%s.\n",
tmptrash->area);
free_trash_chunk(tmptrash);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
}
}
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
else if (s->cur_eweight != s->next_eweight) {
/* now propagate the status change to any LB algorithms */
srv_lb_propagate(s);
}
return xferred;
}
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
/* deduct and update server state from an administrative change
* (use current and next admin to deduct the administrative transition that
* may result in server state update)
*
* The function returns the number of requeued sessions (either taken by
* the server or redispatched to others servers) due to the server state
* change.
*/
static int _srv_update_status_adm(struct server *s, enum srv_adm_st_chg_cause cause)
{
struct buffer *tmptrash = NULL;
int srv_was_stopping = (s->cur_state == SRV_ST_STOPPING) || (s->cur_admin & SRV_ADMF_DRAIN);
int xferred = 0;
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
/* Maintenance must also disable health checks */
if (!(s->cur_admin & SRV_ADMF_MAINT) && (s->next_admin & SRV_ADMF_MAINT)) {
if (s->check.state & CHK_ST_ENABLED) {
s->check.state |= CHK_ST_PAUSED;
CLEANUP: server: remove unused variables in srv_update_status() check and px local variable aliases are not very useful. Let's remove them and use s->check and s->proxy instead.
2023-04-18 06:08:18 -04:00
s->check.health = 0;
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
}
if (s->cur_state == SRV_ST_STOPPED) { /* server was already down */
BUG/MEDIUM: server: Allocate tmptrash before using it. Don't forget to allocate tmptrash before using it, and free it once we're done. [wt: introduced by commit 64cc49cf ("MAJOR: servers: propagate server status changes asynchronously"), no backport needed]
2017-10-24 11:42:47 -04:00
tmptrash = alloc_trash_chunk();
if (tmptrash) {
chunk_printf(tmptrash,
MINOR: server: srv_append_status refacto srv_append_status() has become a swiss-knife function over time. It is used from server code and also from checks code, with various inputs and distincts code paths, making it very hard to guess the actual behavior of the function (resulting string output). To simplify the logic behind it, we're dividing it in multiple contextual functions that take simple inputs and do explicit things, making them more predictable and easier to maintain.
2023-04-14 12:07:09 -04:00
"%sServer %s/%s was DOWN and now enters maintenance",
s->flags & SRV_F_BACKUP ? "Backup " : "", s->proxy->id, s->id);
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
srv_append_adm_chg_cause(tmptrash, s, cause);
MINOR: server: srv_append_status refacto srv_append_status() has become a swiss-knife function over time. It is used from server code and also from checks code, with various inputs and distincts code paths, making it very hard to guess the actual behavior of the function (resulting string output). To simplify the logic behind it, we're dividing it in multiple contextual functions that take simple inputs and do explicit things, making them more predictable and easier to maintain.
2023-04-14 12:07:09 -04:00
srv_append_more(tmptrash, s, -1, (s->next_admin & SRV_ADMF_FMAINT));
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
BUG/MEDIUM: server: Allocate tmptrash before using it. Don't forget to allocate tmptrash before using it, and free it once we're done. [wt: introduced by commit 64cc49cf ("MAJOR: servers: propagate server status changes asynchronously"), no backport needed]
2017-10-24 11:42:47 -04:00
if (!(global.mode & MODE_STARTING)) {
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
ha_warning("%s.\n", tmptrash->area);
send_log(s->proxy, LOG_NOTICE, "%s.\n",
tmptrash->area);
BUG/MEDIUM: server: Allocate tmptrash before using it. Don't forget to allocate tmptrash before using it, and free it once we're done. [wt: introduced by commit 64cc49cf ("MAJOR: servers: propagate server status changes asynchronously"), no backport needed]
2017-10-24 11:42:47 -04:00
}
free_trash_chunk(tmptrash);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
}
MINOR: server: cleanup idle conns for server in maint already stopped When a server goes into maintenance mode, its idle connections are scheduled for an immediate purge. However, this is not the case if the server is already in stopped state, for example due to a health check failure. Adjust _srv_update_status_adm() to ensure that idle connections are always scheduled for purge when going into maintenance in both cases. The main advantage of this patch is to ensure consistent behavior for server maintenance mode. Note that it will also become necessary as server deletion will be adjusted with a future patch. Idle connection closure won't be performed by "del server" handler anymore, so it's important to ensure that a full cleanup is always performed prior to executing it, else the server may not be removable during a certain delay.
2025-08-27 05:27:30 -04:00
/* force connection cleanup on the given server */
srv_cleanup_connections(s);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
}
else { /* server was still running */
CLEANUP: server: remove unused variables in srv_update_status() check and px local variable aliases are not very useful. Let's remove them and use s->check and s->proxy instead.
2023-04-18 06:08:18 -04:00
s->check.health = 0; /* failure */
BUG/MEDIUM: checks: a server passed in maint state was not forced down. Setting a server in maint mode, the required next_state was not set before calling the 'lb_down' function and so the system state was never commited. This patch should be backported in 1.8
2017-12-21 08:42:26 -05:00
s->next_state = SRV_ST_STOPPED;
MINOR: server: propagate lb changes through srv_lb_propagate() Now that we have a generic srv_lb_propagate(s) function, let's use it each time we explicitly wan't to set the status down as well. Indeed, it is tricky to try to handle "down" case explicitly, instead we use srv_lb_propagate() which will call the proper function that will handle the new server state. This will allow some code cleanup and will prevent any logic error. This commit depends on: - "MINOR: server: propagate server state change to lb through single function"
2023-04-18 06:02:48 -04:00
srv_lb_propagate(s);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
MEDIUM: server: Introduce the concept of path parameters Add a new field in struct server, path parameters. It will contain connection informations for the server that are not expected to change. For now, just store the ALPN negociated with the server. Each time an handhskae is done, we'll update it, even though it is not supposed to change. This will be useful when trying to send early data, that way we'll know which mux to use. Each time the server goes down or is disabled, those informations are erased, as we can't be sure those parameters will be the same once the server will be back up.
2025-09-08 16:14:42 -04:00
srv_reset_path_parameters(s);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
if (s->onmarkeddown & HANA_ONMARKEDDOWN_SHUTDOWNSESSIONS)
srv_shutdown_streams(s, SF_ERR_DOWN);
BUG/MEDIUM: connections: force connections cleanup on server changes I've been trying to understand a change of behaviour between v2.2dev5 and v2.2dev6. Indeed our probe is regularly testing to add and remove servers on a given backend such as: # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 263 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 0.0.0.0 0 1 256 256 0 15 3 0 14 0 0 0 - 0 - -> curl on the corresponding frontend: reply from server:31255 # echo "set server be_foo/srv1 addr 10.236.139.34 port 31257" | sudo socat stdio /var/lib/haproxy/stats IP changed from '0.0.0.0' to '10.236.139.34', port changed from '0' to '31257' by 'stats socket command' # echo "set server be_foo/srv1 weight 256" | sudo socat stdio /var/lib/haproxy/stats # echo "set server be_foo/srv1 check-port 8500" | sudo socat stdio /var/lib/haproxy/stats health check port updated. # echo "set server be_foo/srv1 state ready" | sudo socat stdio /var/lib/haproxy/stats # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 105 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 10.236.139.34 2 0 256 256 2319 15 3 2 6 0 0 0 - 31257 - -> curl on the corresponding frontend: reply for server:31257 (notice the difference of weight) # echo "set server be_foo/srv1 state maint" | sudo socat stdio /var/lib/haproxy/stats # echo "set server be_foo/srv1 addr 0.0.0.0 port 0" | sudo socat stdio /var/lib/haproxy/stats IP changed from '10.236.139.34' to '0.0.0.0', port changed from '31257' to '0' by 'stats socket command' # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 263 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 0.0.0.0 0 1 256 256 0 15 3 0 14 0 0 0 - 0 - -> curl on the corresponding frontend: reply from server:31255 # echo "set server be_foo/srv1 addr 10.236.139.34 port 31256" | sudo socat stdio /var/lib/haproxy/stats IP changed from '0.0.0.0' to '10.236.139.34', port changed from '0' to '31256' by 'stats socket command' # echo "set server be_foo/srv1 weight 256" | sudo socat stdio /var/lib/haproxy/stats # echo "set server be_foo/srv1 check-port 8500" | sudo socat stdio /var/lib/haproxy/stats health check port updated. # echo "set server be_foo/srv1 state ready" | sudo socat stdio /var/lib/haproxy/stats # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 105 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 10.236.139.34 2 0 256 256 2319 15 3 2 6 0 0 0 - 31256 - -> curl on the corresponding frontend: reply from server:31257 (!) Here we indeed would expect to get an anver from server:31256. The issue is highly linked to the usage of `pool-purge-delay`, with a value which is higher than the duration of the test, 10s in our case. a git bisect between dev5 and dev6 seems to show commit 079cb9af22da6 ("MEDIUM: connections: Revamp the way idle connections are killed") being the origin of this new behaviour. So if I understand the later correctly, it seems that it was more a matter of chance that we did not saw the issue earlier. My patch proposes to force clean idle connections in the two following cases: - we set a (still running) server to maintenance - we change the ip/port of a server This commit should be backported to 2.1, 2.0, and 1.9. Signed-off-by: William Dauchy <w.dauchy@criteo.com>
2020-05-02 15:52:36 -04:00
/* force connection cleanup on the given server */
srv_cleanup_connections(s);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
/* we might have streams queued on this server and waiting for
* a connection. Those which are redispatchable will be queued
* to another server or to the proxy itself.
*/
xferred = pendconn_redistribute(s);
tmptrash = alloc_trash_chunk();
if (tmptrash) {
chunk_printf(tmptrash,
MINOR: server: srv_append_status refacto srv_append_status() has become a swiss-knife function over time. It is used from server code and also from checks code, with various inputs and distincts code paths, making it very hard to guess the actual behavior of the function (resulting string output). To simplify the logic behind it, we're dividing it in multiple contextual functions that take simple inputs and do explicit things, making them more predictable and easier to maintain.
2023-04-14 12:07:09 -04:00
"%sServer %s/%s is going DOWN for maintenance",
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
s->flags & SRV_F_BACKUP ? "Backup " : "",
MINOR: server: srv_append_status refacto srv_append_status() has become a swiss-knife function over time. It is used from server code and also from checks code, with various inputs and distincts code paths, making it very hard to guess the actual behavior of the function (resulting string output). To simplify the logic behind it, we're dividing it in multiple contextual functions that take simple inputs and do explicit things, making them more predictable and easier to maintain.
2023-04-14 12:07:09 -04:00
s->proxy->id, s->id);
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
srv_append_adm_chg_cause(tmptrash, s, cause);
MINOR: server: srv_append_status refacto srv_append_status() has become a swiss-knife function over time. It is used from server code and also from checks code, with various inputs and distincts code paths, making it very hard to guess the actual behavior of the function (resulting string output). To simplify the logic behind it, we're dividing it in multiple contextual functions that take simple inputs and do explicit things, making them more predictable and easier to maintain.
2023-04-14 12:07:09 -04:00
srv_append_more(tmptrash, s, xferred, (s->next_admin & SRV_ADMF_FMAINT));
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
if (!(global.mode & MODE_STARTING)) {
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
ha_warning("%s.\n", tmptrash->area);
send_log(s->proxy, srv_was_stopping ? LOG_NOTICE : LOG_ALERT, "%s.\n",
tmptrash->area);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
}
free_trash_chunk(tmptrash);
}
}
}
else if ((s->cur_admin & SRV_ADMF_MAINT) && !(s->next_admin & SRV_ADMF_MAINT)) {
/* OK here we're leaving maintenance, we have many things to check,
* because the server might possibly be coming back up depending on
* its state. In practice, leaving maintenance means that we should
* immediately turn to UP (more or less the slowstart) under the
* following conditions :
* - server is neither checked nor tracked
* - server tracks another server which is not checked
* - server tracks another server which is already up
* Which sums up as something simpler :
* "either the tracking server is up or the server's checks are disabled
* or up". Otherwise we only re-enable health checks. There's a special
* case associated to the stopping state which can be inherited. Note
* that the server might still be in drain mode, which is naturally dealt
* with by the lower level functions.
*/
if (s->check.state & CHK_ST_ENABLED) {
s->check.state &= ~CHK_ST_PAUSED;
MEDIUM: server: add init-state Allow the user to set the "initial state" of a server. Context: Servers are always set in an UP status by default. In some cases, further checks are required to determine if the server is ready to receive client traffic. This introduces the "init-state {up|down}" configuration parameter to the server. - when set to 'fully-up', the server is considered immediately available and can turn to the DOWN sate when ALL health checks fail. - when set to 'up' (the default), the server is considered immediately available and will initiate a health check that can turn it to the DOWN state immediately if it fails. - when set to 'down', the server initially is considered unavailable and will initiate a health check that can turn it to the UP state immediately if it succeeds. - when set to 'fully-down', the server is initially considered unavailable and can turn to the UP state when ALL health checks succeed. The server's init-state is considered when the HAProxy instance is (re)started, a new server is detected (for example via service discovery / DNS resolution), a server exits maintenance, etc. Link: https://github.com/haproxy/haproxy/issues/51
2024-09-04 18:27:35 -04:00
if(s->init_state == SRV_INIT_STATE_FULLY_UP) {
s->check.health = s->check.rise + s->check.fall - 1; /* initially UP, when all checks fail to bring server DOWN */
}
else if(s->init_state == SRV_INIT_STATE_DOWN) {
s->check.health = s->check.rise - 1; /* initially DOWN, when one check is successful bring server UP */
}
else if(s->init_state == SRV_INIT_STATE_FULLY_DOWN) {
s->check.health = 0; /* initially DOWN, when all checks are successful bring server UP */
} else {
s->check.health = s->check.rise; /* initially UP, when one check fails check brings server DOWN */
}
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
}
if ((!s->track || s->track->next_state != SRV_ST_STOPPED) &&
(!(s->agent.state & CHK_ST_ENABLED) || (s->agent.health >= s->agent.rise)) &&
(!(s->check.state & CHK_ST_ENABLED) || (s->check.health >= s->check.rise))) {
if (s->track && s->track->next_state == SRV_ST_STOPPING) {
s->next_state = SRV_ST_STOPPING;
}
else {
s->next_state = SRV_ST_STARTING;
BUG/MEDIUM: server: support changing the slowstart value from state-file If the slowstart value in a state file implies the latest state change is within the slowstart period, we end up calling srv_update_status() to reschedule the server's state change but its task is not yet allocated and remains null, causing a crash on startup. Make sure srv_update_status() supports being called with partially initialized servers which do not yet have a task. If the task has to be scheduled, it will necessarily happen after initialization since it will result from a state change. This should be backported wherever server-state is present.
2020-10-22 05:30:59 -04:00
if (s->slowstart > 0) {
if (s->warmup)
task_schedule(s->warmup, tick_add(now_ms, MS_TO_TICKS(MAX(1000, s->slowstart / 20))));
}
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
else
s->next_state = SRV_ST_RUNNING;
}
}
tmptrash = alloc_trash_chunk();
if (tmptrash) {
if (!(s->next_admin & SRV_ADMF_FMAINT) && (s->cur_admin & SRV_ADMF_FMAINT)) {
chunk_printf(tmptrash,
"%sServer %s/%s is %s/%s (leaving forced maintenance)",
s->flags & SRV_F_BACKUP ? "Backup " : "",
s->proxy->id, s->id,
(s->next_state == SRV_ST_STOPPED) ? "DOWN" : "UP",
(s->next_admin & SRV_ADMF_DRAIN) ? "DRAIN" : "READY");
}
if (!(s->next_admin & SRV_ADMF_RMAINT) && (s->cur_admin & SRV_ADMF_RMAINT)) {
chunk_printf(tmptrash,
"%sServer %s/%s ('%s') is %s/%s (resolves again)",
s->flags & SRV_F_BACKUP ? "Backup " : "",
s->proxy->id, s->id, s->hostname,
(s->next_state == SRV_ST_STOPPED) ? "DOWN" : "UP",
(s->next_admin & SRV_ADMF_DRAIN) ? "DRAIN" : "READY");
}
if (!(s->next_admin & SRV_ADMF_IMAINT) && (s->cur_admin & SRV_ADMF_IMAINT)) {
chunk_printf(tmptrash,
"%sServer %s/%s is %s/%s (leaving maintenance)",
s->flags & SRV_F_BACKUP ? "Backup " : "",
s->proxy->id, s->id,
(s->next_state == SRV_ST_STOPPED) ? "DOWN" : "UP",
(s->next_admin & SRV_ADMF_DRAIN) ? "DRAIN" : "READY");
}
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
ha_warning("%s.\n", tmptrash->area);
send_log(s->proxy, LOG_NOTICE, "%s.\n",
tmptrash->area);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
free_trash_chunk(tmptrash);
}
MAJOR: server: make server state changes synchronous again Now we try to synchronously push updates as they come using the new rdv point, so that the call to the server update function from the main poll loop is not needed anymore. It further reduces the apparent latency in the health checks as the response time almost always appears as 0 ms, resulting in a slightly higher check rate of ~1960 conn/s. Despite this, the CPU consumption has slightly dropped again to ~32% for the same test. The only trick is that the checks code is built with a bit of recursivity because srv_update_status() calls server_recalc_eweight(), and the latter needs to signal srv_update_status() in case of updates. Thus we added an extra argument to this function to indicate whether or not it must propagate updates (no if it comes from srv_update_status).
2018-08-02 05:48:52 -04:00
server_recalc_eweight(s, 0);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
/* now propagate the status change to any LB algorithms */
MINOR: server: propagate server state change to lb through single function Use a dedicated helper function to propagate server state change to lb algorithms, since it is performed at multiple places within srv_update_status() function.
2023-04-17 07:53:56 -04:00
srv_lb_propagate(s);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
BUG/MEDIUM: servers: check the queues once enabling a server Commit 64cc49c ("MAJOR: servers: propagate server status changes asynchronously.") heavily changed the way the server states are updated since they became asynchronous. During this change, some code was lost, which is used to shut down some sessions from a backup server and to pick pending connections from a proxy once a server is turned back from maintenance to ready state. The effect is that when temporarily disabling a server, connections stay in the backend's queue, and when re-enabling it, they are not picked and they expire in the backend's queue. Now they're properly picked again. This fix must be backported to 1.8.
2018-08-07 04:14:53 -04:00
/* If the server is set with "on-marked-up shutdown-backup-sessions",
* and it's not a backup server and its effective weight is > 0,
* then it can accept new connections, so we shut down all streams
* on all backup servers.
*/
if ((s->onmarkedup & HANA_ONMARKEDUP_SHUTDOWNBACKUPSESSIONS) &&
!(s->flags & SRV_F_BACKUP) && s->next_eweight)
srv_shutdown_backup_streams(s->proxy, SF_ERR_UP);
BUG/MEDIUM: queues: Do not use pendconn_grab_from_px(). pendconn_grab_from_px() was called when a server was brought back up, to get some streams waiting in the proxy's queue and get them to run on the newly available server. It is very similar to process_srv_queue(), except it only goes through the proxy's queue, which can be a problem, because there is a small race condition that could lead us to add more streams to the server queue just as it's going down. If that happens, the server would just be ignored when back up by new streams, as its queue is not empty, and it would never try to process its queue. The other problem with pendconn_grab_from_px() is that it is very liberal with how it dequeues streams, and it is not very good at enforcing maxconn, it could lead to having 3*maxconn connections. For both those reasons, just get rid of pendconn_grab_from_px(), and just use process_srv_queue(). Both problems are easy to reproduce, especially on a 64 threads machine, set a maxconn to 100, inject in H2 with 1000 concurrent connections containing up to 100 streams each, and after a few seconds/minutes the max number of concurrent output streams will be much higher than maxconn, and eventually the server will stop processing connections. It may be related to github issue #2744. Note that it doesn't totally fix the problem, we can occasionally see a few more connections than maxconn, but the max that have been observed is 4 more connections, we no longer get multiple times maxconn. have more outgoing connections than maxconn, This should be backported up to 2.6.
2024-12-17 09:39:21 -05:00
/* check if we can handle some connections queued.
* We will take as many as we can handle.
BUG/MEDIUM: servers: check the queues once enabling a server Commit 64cc49c ("MAJOR: servers: propagate server status changes asynchronously.") heavily changed the way the server states are updated since they became asynchronous. During this change, some code was lost, which is used to shut down some sessions from a backup server and to pick pending connections from a proxy once a server is turned back from maintenance to ready state. The effect is that when temporarily disabling a server, connections stay in the backend's queue, and when re-enabling it, they are not picked and they expire in the backend's queue. Now they're properly picked again. This fix must be backported to 1.8.
2018-08-07 04:14:53 -04:00
*/
BUG/MEDIUM: queue: Make process_srv_queue return the number of streams Make process_srv_queue() return the number of streams unqueued, as pendconn_grab_from_px() did, as that number is used by srv_update_status() to generate logs. This should be backported up to 2.6 with 111ea83ed4e13ac3ab028ed5e95201a1b4aa82b8
2024-12-23 09:17:25 -05:00
xferred = process_srv_queue(s);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
}
else if (s->next_admin & SRV_ADMF_MAINT) {
/* remaining in maintenance mode, let's inform precisely about the
* situation.
*/
if (!(s->next_admin & SRV_ADMF_FMAINT) && (s->cur_admin & SRV_ADMF_FMAINT)) {
tmptrash = alloc_trash_chunk();
if (tmptrash) {
chunk_printf(tmptrash,
"%sServer %s/%s is leaving forced maintenance but remains in maintenance",
s->flags & SRV_F_BACKUP ? "Backup " : "",
s->proxy->id, s->id);
if (s->track) /* normally it's mandatory here */
chunk_appendf(tmptrash, " via %s/%s",
s->track->proxy->id, s->track->id);
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
ha_warning("%s.\n", tmptrash->area);
send_log(s->proxy, LOG_NOTICE, "%s.\n",
tmptrash->area);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
free_trash_chunk(tmptrash);
}
}
if (!(s->next_admin & SRV_ADMF_RMAINT) && (s->cur_admin & SRV_ADMF_RMAINT)) {
tmptrash = alloc_trash_chunk();
if (tmptrash) {
chunk_printf(tmptrash,
"%sServer %s/%s ('%s') resolves again but remains in maintenance",
s->flags & SRV_F_BACKUP ? "Backup " : "",
s->proxy->id, s->id, s->hostname);
if (s->track) /* normally it's mandatory here */
chunk_appendf(tmptrash, " via %s/%s",
s->track->proxy->id, s->track->id);
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
ha_warning("%s.\n", tmptrash->area);
send_log(s->proxy, LOG_NOTICE, "%s.\n",
tmptrash->area);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
free_trash_chunk(tmptrash);
}
}
else if (!(s->next_admin & SRV_ADMF_IMAINT) && (s->cur_admin & SRV_ADMF_IMAINT)) {
tmptrash = alloc_trash_chunk();
if (tmptrash) {
chunk_printf(tmptrash,
"%sServer %s/%s remains in forced maintenance",
s->flags & SRV_F_BACKUP ? "Backup " : "",
s->proxy->id, s->id);
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
ha_warning("%s.\n", tmptrash->area);
send_log(s->proxy, LOG_NOTICE, "%s.\n",
tmptrash->area);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
free_trash_chunk(tmptrash);
}
}
/* don't report anything when leaving drain mode and remaining in maintenance */
}
if (!(s->next_admin & SRV_ADMF_MAINT)) {
if (!(s->cur_admin & SRV_ADMF_DRAIN) && (s->next_admin & SRV_ADMF_DRAIN)) {
/* drain state is applied only if not yet in maint */
MINOR: server: propagate lb changes through srv_lb_propagate() Now that we have a generic srv_lb_propagate(s) function, let's use it each time we explicitly wan't to set the status down as well. Indeed, it is tricky to try to handle "down" case explicitly, instead we use srv_lb_propagate() which will call the proper function that will handle the new server state. This will allow some code cleanup and will prevent any logic error. This commit depends on: - "MINOR: server: propagate server state change to lb through single function"
2023-04-18 06:02:48 -04:00
srv_lb_propagate(s);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
/* we might have streams queued on this server and waiting for
* a connection. Those which are redispatchable will be queued
* to another server or to the proxy itself.
*/
xferred = pendconn_redistribute(s);
tmptrash = alloc_trash_chunk();
if (tmptrash) {
MINOR: server: srv_append_status refacto srv_append_status() has become a swiss-knife function over time. It is used from server code and also from checks code, with various inputs and distincts code paths, making it very hard to guess the actual behavior of the function (resulting string output). To simplify the logic behind it, we're dividing it in multiple contextual functions that take simple inputs and do explicit things, making them more predictable and easier to maintain.
2023-04-14 12:07:09 -04:00
chunk_printf(tmptrash, "%sServer %s/%s enters drain state",
s->flags & SRV_F_BACKUP ? "Backup " : "", s->proxy->id, s->id);
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
srv_append_adm_chg_cause(tmptrash, s, cause);
MINOR: server: srv_append_status refacto srv_append_status() has become a swiss-knife function over time. It is used from server code and also from checks code, with various inputs and distincts code paths, making it very hard to guess the actual behavior of the function (resulting string output). To simplify the logic behind it, we're dividing it in multiple contextual functions that take simple inputs and do explicit things, making them more predictable and easier to maintain.
2023-04-14 12:07:09 -04:00
srv_append_more(tmptrash, s, xferred, (s->next_admin & SRV_ADMF_FDRAIN));
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
if (!(global.mode & MODE_STARTING)) {
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
ha_warning("%s.\n", tmptrash->area);
send_log(s->proxy, LOG_NOTICE, "%s.\n",
tmptrash->area);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
}
free_trash_chunk(tmptrash);
}
}
else if ((s->cur_admin & SRV_ADMF_DRAIN) && !(s->next_admin & SRV_ADMF_DRAIN)) {
/* OK completely leaving drain mode */
MAJOR: server: make server state changes synchronous again Now we try to synchronously push updates as they come using the new rdv point, so that the call to the server update function from the main poll loop is not needed anymore. It further reduces the apparent latency in the health checks as the response time almost always appears as 0 ms, resulting in a slightly higher check rate of ~1960 conn/s. Despite this, the CPU consumption has slightly dropped again to ~32% for the same test. The only trick is that the checks code is built with a bit of recursivity because srv_update_status() calls server_recalc_eweight(), and the latter needs to signal srv_update_status() in case of updates. Thus we added an extra argument to this function to indicate whether or not it must propagate updates (no if it comes from srv_update_status).
2018-08-02 05:48:52 -04:00
server_recalc_eweight(s, 0);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
tmptrash = alloc_trash_chunk();
if (tmptrash) {
BUG/MINOR: server: incorrect report for tracking servers leaving drain Report message for tracking servers completely leaving drain is wrong: The check for "leaving drain .. via" never evaluates because the condition !(s->next_admin & SRV_ADMF_FDRAIN) is always true in the current block which is guarded by !(s->next_admin & SRV_ADMF_DRAIN). For tracking servers that leave inherited drain mode, this results in the following message being emitted: "Server x/b is UP (leaving forced drain)" Instead of: "Server x/b is UP (leaving drain) via x/a" To this fix: we check if FDRAIN is currently set, else it means that the drain status is inherited from the tracked server (IDRAIN) This regression was introduced with 64cc49cf ("MAJOR: servers: propagate server status changes asynchronously."), thus it may be backported to every stable versions.
2023-03-27 04:17:31 -04:00
if (s->cur_admin & SRV_ADMF_FDRAIN) {
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
chunk_printf(tmptrash,
"%sServer %s/%s is %s (leaving forced drain)",
s->flags & SRV_F_BACKUP ? "Backup " : "",
s->proxy->id, s->id,
(s->next_state == SRV_ST_STOPPED) ? "DOWN" : "UP");
}
else {
chunk_printf(tmptrash,
"%sServer %s/%s is %s (leaving drain)",
s->flags & SRV_F_BACKUP ? "Backup " : "",
s->proxy->id, s->id,
(s->next_state == SRV_ST_STOPPED) ? "DOWN" : "UP");
if (s->track) /* normally it's mandatory here */
chunk_appendf(tmptrash, " via %s/%s",
s->track->proxy->id, s->track->id);
}
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
ha_warning("%s.\n", tmptrash->area);
send_log(s->proxy, LOG_NOTICE, "%s.\n",
tmptrash->area);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
free_trash_chunk(tmptrash);
}
/* now propagate the status change to any LB algorithms */
MINOR: server: propagate server state change to lb through single function Use a dedicated helper function to propagate server state change to lb algorithms, since it is performed at multiple places within srv_update_status() function.
2023-04-17 07:53:56 -04:00
srv_lb_propagate(s);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
}
else if ((s->next_admin & SRV_ADMF_DRAIN)) {
/* remaining in drain mode after removing one of its flags */
tmptrash = alloc_trash_chunk();
if (tmptrash) {
if (!(s->next_admin & SRV_ADMF_FDRAIN)) {
chunk_printf(tmptrash,
MINOR: server: fix message report when IDRAIN is set and MAINT is cleared Remaining in drain mode after removing one of server admins flags leads to this message being generated: "Server name/backend is leaving forced drain but remains in drain mode." However this is not necessarily true: the server might just be leaving MAINT with the IDRAIN flag set, so the report is incorrect in this case. (FDRAIN was not set so it cannot be cleared) To prevent confusion around this message and to comply with the code comment above it: we remove the "leaving forced drain" precision to make the report suitable for multiple transitions.
2023-05-03 04:36:54 -04:00
"%sServer %s/%s remains in drain mode",
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
s->flags & SRV_F_BACKUP ? "Backup " : "",
s->proxy->id, s->id);
if (s->track) /* normally it's mandatory here */
chunk_appendf(tmptrash, " via %s/%s",
s->track->proxy->id, s->track->id);
}
else {
chunk_printf(tmptrash,
"%sServer %s/%s remains in forced drain mode",
s->flags & SRV_F_BACKUP ? "Backup " : "",
s->proxy->id, s->id);
}
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
ha_warning("%s.\n", tmptrash->area);
send_log(s->proxy, LOG_NOTICE, "%s.\n",
tmptrash->area);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
free_trash_chunk(tmptrash);
}
}
}
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
return xferred;
}
/*
* This function applies server's status changes.
*
* Must be called with the server lock held. This may also be called at init
* time as the result of parsing the state file, in which case no lock will be
* held, and the server's warmup task can be null.
* <type> should be 0 for operational and 1 for administrative
* <cause> must be srv_op_st_chg_cause enum for operational and
* srv_adm_st_chg_cause enum for administrative
*/
static void srv_update_status(struct server *s, int type, int cause)
{
int prev_srv_count = s->proxy->srv_bck + s->proxy->srv_act;
enum srv_state srv_prev_state = s->cur_state;
MINOR: server/event_hdl: add SERVER_STATE event Adding a new SERVER event in the event_hdl API. SERVER_STATE is implemented as an advanced server event. It is published each time the server's effective state changes. (when s->cur_state changes) SERVER_STATE data is an event_hdl_cb_data_server_state struct that provides additional info related to the server state change, but can be casted as a regular event_hdl_cb_data_server struct if additional info is not needed.
2023-04-04 15:28:07 -04:00
union {
struct event_hdl_cb_data_server_state state;
MINOR: server/event_hdl: add SERVER_ADMIN event Adding a new SERVER event in the event_hdl API. SERVER_ADMIN is implemented as an advanced server event. It is published each time the administrative state changes. (when s->cur_admin changes) SERVER_ADMIN data is an event_hdl_cb_data_server_admin struct that provides additional info related to the admin state change, but can be casted as a regular event_hdl_cb_data_server struct if additional info is not needed.
2023-04-21 12:06:58 -04:00
struct event_hdl_cb_data_server_admin admin;
MINOR: server/event_hdl: add SERVER_STATE event Adding a new SERVER event in the event_hdl API. SERVER_STATE is implemented as an advanced server event. It is published each time the server's effective state changes. (when s->cur_state changes) SERVER_STATE data is an event_hdl_cb_data_server_state struct that provides additional info related to the server state change, but can be casted as a regular event_hdl_cb_data_server struct if additional info is not needed.
2023-04-04 15:28:07 -04:00
struct event_hdl_cb_data_server common;
} cb_data;
int requeued;
/* prepare common server event data */
_srv_event_hdl_prepare(&cb_data.common, s, 0);
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
MINOR: server/event_hdl: add SERVER_ADMIN event Adding a new SERVER event in the event_hdl API. SERVER_ADMIN is implemented as an advanced server event. It is published each time the administrative state changes. (when s->cur_admin changes) SERVER_ADMIN data is an event_hdl_cb_data_server_admin struct that provides additional info related to the admin state change, but can be casted as a regular event_hdl_cb_data_server struct if additional info is not needed.
2023-04-21 12:06:58 -04:00
if (type) {
cb_data.admin.safe.cause = cause;
cb_data.admin.safe.old_admin = s->cur_admin;
cb_data.admin.safe.new_admin = s->next_admin;
MINOR: server/event_hdl: add SERVER_STATE event Adding a new SERVER event in the event_hdl API. SERVER_STATE is implemented as an advanced server event. It is published each time the server's effective state changes. (when s->cur_state changes) SERVER_STATE data is an event_hdl_cb_data_server_state struct that provides additional info related to the server state change, but can be casted as a regular event_hdl_cb_data_server struct if additional info is not needed.
2023-04-04 15:28:07 -04:00
requeued = _srv_update_status_adm(s, cause);
MINOR: server/event_hdl: add SERVER_ADMIN event Adding a new SERVER event in the event_hdl API. SERVER_ADMIN is implemented as an advanced server event. It is published each time the administrative state changes. (when s->cur_admin changes) SERVER_ADMIN data is an event_hdl_cb_data_server_admin struct that provides additional info related to the admin state change, but can be casted as a regular event_hdl_cb_data_server struct if additional info is not needed.
2023-04-21 12:06:58 -04:00
cb_data.admin.safe.requeued = requeued;
/* publish admin change */
_srv_event_hdl_publish(EVENT_HDL_SUB_SERVER_ADMIN, cb_data.admin, s);
}
MEDIUM: server: split srv_update_status() in two functions Considering that srv_update_status() is now synchronous again since 3ff577e1 ("MAJOR: server: make server state changes synchronous again"), and that we can easily identify if the update is from an operational or administrative context thanks to "MINOR: server: pass adm and op cause to srv_update_status()". And given that administrative and operational updates cannot be cumulated (since srv_update_status() is called synchronously and independently for admin updates and state/operational updates, and the function directly consumes the changes). We split srv_update_status() in 2 distinct parts: Either <type> is 0, meaning the update is an operational update which is handled by directly looking at cur_state and next_state to apply the proper transition. Also, the check to prevent operational state from being applied if MAINT admin flag is set is no longer needed given that the calling functions already ensure this (ie: srv_set_{running,stopping,stopped) Or <type> is 1, meaning the update is an administrative update, where cur_admin and next_admin are evaluated to apply the proper transition and deduct the resulting server state (next_state is updated implicitly). Once this is done, both operations share a common code path in srv_update_status() to update proxy and servers stats if required. Thanks to this change, the function's behavior is much more predictable, it is not an all-in-one function anymore. Either we apply an operational change, else it is an administrative change. That's it, we cannot mix the 2 since both code paths are now properly separated.
2023-04-19 10:19:58 -04:00
else
MINOR: server/event_hdl: add SERVER_STATE event Adding a new SERVER event in the event_hdl API. SERVER_STATE is implemented as an advanced server event. It is published each time the server's effective state changes. (when s->cur_state changes) SERVER_STATE data is an event_hdl_cb_data_server_state struct that provides additional info related to the server state change, but can be casted as a regular event_hdl_cb_data_server struct if additional info is not needed.
2023-04-04 15:28:07 -04:00
requeued = _srv_update_status_op(s, cause);
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
MINOR: server: explicitly commit state change in srv_update_status() As shown in 8f29829 ("BUG/MEDIUM: checks: a down server going to maint remains definitely stucked on down state."), state changes that don't result in explicit lb state change, require us to perform an explicit server state commit to make sure the next state is applied before returning from the function. This is the case for server state changes that don't trigger lb logic and only perform some logging. This is quite error prone, we could easily forget a state change combination that could result in next_state, next_admin or next_eweight not being applied. (cur_state, cur_admin and cur_eweight would be left with unexpected values) To fix this, we explicitly call srv_lb_commit_status() at the end of srv_update_status() to enforce the new values, even if they were already applied. (when a state changes requires lb state update an implicit commit is already performed) Applying the state change multiple times is safe (since the next value always points to the current value). Backport notes: 2.2: Replace struct task *srv_cleanup_toremove_conns(struct task *task, void *context, unsigned int state) by struct task *srv_cleanup_toremove_connections(struct task *task, void *context, unsigned short state)
2023-04-17 11:45:58 -04:00
/* explicitly commit state changes (even if it was already applied implicitly
* by some lb state change function), so we don't miss anything
*/
srv_lb_commit_status(s);
BUG/MINOR: server: don't miss proxy stats update on server state transitions backend "down" stats logic has been duplicated multiple times in srv_update_status(), resulting in the logic now being error-prone. For example, the following bugfix was needed to compensate for a copy-paste introduced bug: d332f139 ("BUG/MINOR: server: update last_change on maint->ready transitions too") While the above patch works great, we actually forgot to update the proxy downtime like it is done for other down->up transitions... This is simply illustrating that the current design is error-prone, it is very easy to miss something in this area. To properly update the proxy downtime stats on the maint->ready transition, to cleanup srv_update_status() and to prevent similar bugs from being introduced in the future, proxy/backend stats update are now automatically performed at the end of the server state change if needed. Thus we can remove existing updates that were performed at various places within the function, this simplifies things a bit. This patch depends on: - "MINOR: server: explicitly commit state change in srv_update_status()" This could be backported to all stable versions. Backport notes: 2.2: Replace struct task *srv_cleanup_toremove_conns(struct task *task, void *context, unsigned int state) by struct task *srv_cleanup_toremove_connections(struct task *task, void *context, unsigned short state)
2023-04-17 09:30:11 -04:00
BUG/MINOR: server: don't miss server stats update on server state transitions s->last_change and s->down_time updates were manually updated for each effective server state change within srv_update_status(). This is rather error-prone, and as a result there were still some state transitions that were not handled properly since at least 1.8. ie: - when transitionning from DRAIN to READY: downtime was updated (which is wrong since a server in DRAIN state should not be considered as DOWN) - when transitionning from MAINT to READY: downtime was not updated (this can be easily seen in the html stats page) To fix these all at once, and prevent similar bugs from being introduced, we centralize the server last_change and down_time stats logic at the end of srv_update_status(): If the server state changed during the call, then it means that last_change must be updated, with a special case when changing from STOPPED state which means the server was previously DOWN and thus downtime should be updated. This patch depends on: - "MINOR: server: explicitly commit state change in srv_update_status()" This could be backported to every stable versions.
2023-04-18 07:52:27 -04:00
/* check if server stats must be updated due the the server state change */
if (srv_prev_state != s->cur_state) {
if (srv_prev_state == SRV_ST_STOPPED) {
/* server was down and no longer is */
MEDIUM: server: add and use a separate last_change variable for internal use last_change server metric is used for 2 separate purposes. First it is used to report last server state change date for stats and other related metrics. But it is also used internally, including in sensitive paths, such as lb related stuff to take decision or perform computations (ie: in srv_dynamic_maxconn()). Due to last_change counter now being split over thread groups since 16eb0fa ("MAJOR: counters: dispatch counters over thread groups"), reading the aggregated value has a cost, and we cannot afford to consult last_change value from srv_dynamic_maxconn() anymore. Moreover, since the value is used to take decision for the current process we don't wan't the variable to be updated by another process in our back. To prevent performance regression and sharing issues, let's instead add a separate srv->last_change value, which is not updated atomically (given how rare the updates are), and only serves for places where the use of the aggregated last_change counter/stats (split over thread groups) is too costly.
2025-06-30 04:57:29 -04:00
if (s->last_change < ns_to_sec(now_ns)) // ignore negative times
s->down_time += ns_to_sec(now_ns) - s->last_change;
OPTIM: server: publish UP/DOWN events from STATE change Reuse cb_data from STATE event to publish UP and DOWN events. This saves some CPU time since the event is only constructed once to publish STATE, STATE+UP or STATE+DOWN depending on the state change.
2023-04-19 16:34:01 -04:00
_srv_event_hdl_publish(EVENT_HDL_SUB_SERVER_UP, cb_data.common, s);
BUG/MINOR: server: don't miss server stats update on server state transitions s->last_change and s->down_time updates were manually updated for each effective server state change within srv_update_status(). This is rather error-prone, and as a result there were still some state transitions that were not handled properly since at least 1.8. ie: - when transitionning from DRAIN to READY: downtime was updated (which is wrong since a server in DRAIN state should not be considered as DOWN) - when transitionning from MAINT to READY: downtime was not updated (this can be easily seen in the html stats page) To fix these all at once, and prevent similar bugs from being introduced, we centralize the server last_change and down_time stats logic at the end of srv_update_status(): If the server state changed during the call, then it means that last_change must be updated, with a special case when changing from STOPPED state which means the server was previously DOWN and thus downtime should be updated. This patch depends on: - "MINOR: server: explicitly commit state change in srv_update_status()" This could be backported to every stable versions.
2023-04-18 07:52:27 -04:00
}
MINOR: server: central update for server counters on state change Based on "BUG/MINOR: server: don't miss server stats update on server state transitions", we're also taking advantage of the new centralized logic to update down_trans server counter directly from there instead of multiple places.
2023-04-19 12:22:21 -04:00
else if (s->cur_state == SRV_ST_STOPPED) {
/* server was up and is currently down */
MEDIUM: counters: mostly revert da813ae4d7cb77137ed Contrarily to what was previously believed, there are corner cases where the counters may not be allocated, and we may want to make them optional at a later date, so we have to check if those counters are there. However, just checking that shared.tg is non-NULL is enough, we can then assume that shared.tg[tgid - 1] has properly been allocated too. Also modify the various COUNTER_SHARED_* macros to make sure they check for that too.
2026-01-14 05:37:49 -05:00
if (s->counters.shared.tg)
HA_ATOMIC_INC(&s->counters.shared.tg[tgid - 1]->down_trans);
OPTIM: server: publish UP/DOWN events from STATE change Reuse cb_data from STATE event to publish UP and DOWN events. This saves some CPU time since the event is only constructed once to publish STATE, STATE+UP or STATE+DOWN depending on the state change.
2023-04-19 16:34:01 -04:00
_srv_event_hdl_publish(EVENT_HDL_SUB_SERVER_DOWN, cb_data.common, s);
MINOR: server: central update for server counters on state change Based on "BUG/MINOR: server: don't miss server stats update on server state transitions", we're also taking advantage of the new centralized logic to update down_trans server counter directly from there instead of multiple places.
2023-04-19 12:22:21 -04:00
}
MEDIUM: queue: Handle the race condition between queue and dequeue differently There is a small race condition, where a server would check if there is something left in the proxy queue, and adding something to the proxy queue. If the server checks just before the stream is added to the queue, and it no longer has any stream to deal with, then nothing will take care of the stream, that may stay in the queue forever. This was worked around with commit 5541d4995d, by checking for that exact condition after adding the stream to the queue, and trying again to get a server assigned if it is detected. That fix lead to multiple infinite loops, that got fixed, but it is not unlikely that it could happen again. So let's fix the initial problem differently : a single server may mark itself as ready, and it removes itself once used. The principle is that when we discover that the just queued stream is alone with no active request anywhere ot dequeue it, instead of rebalancing it, it will be assigned to that current "ready" server that is available to handle it. The extra cost of the atomic ops is negligible since the situation is super rare.
2024-12-05 09:30:06 -05:00
/*
* If the server is no longer running, let's not pretend
* it can handle requests.
*/
BUG/MEDIUM: server: close a race around ready_srv when deleting a server When a server is being disabled or deleted, in case it matches the backend's ready_srv, this one is reset. However it's currently done in a non-atomic way when the server goes down, and that could occasionally reset the entry matching another server, but more importantly if in parallel some requests are dequeued for that server, it may re-appear there after having been removed, leading to a possible crash once it is fully removed, as shown in issue #3177. Let's make sure we reset the pointer when detaching the server from the proxy, and use a CAS in both cases to only reset this server. This fix needs to be backported to 3.2. There, srv_detach() is in server.c instead of server.h. Thanks to Basha Mougamadou for the detailed report and the useful backtraces.
2025-11-06 13:52:10 -05:00
if (s->cur_state != SRV_ST_RUNNING) {
struct server *srv = s;
HA_ATOMIC_CAS(&s->proxy->ready_srv, &srv, NULL);
}
MEDIUM: queue: Handle the race condition between queue and dequeue differently There is a small race condition, where a server would check if there is something left in the proxy queue, and adding something to the proxy queue. If the server checks just before the stream is added to the queue, and it no longer has any stream to deal with, then nothing will take care of the stream, that may stay in the queue forever. This was worked around with commit 5541d4995d, by checking for that exact condition after adding the stream to the queue, and trying again to get a server assigned if it is detected. That fix lead to multiple infinite loops, that got fixed, but it is not unlikely that it could happen again. So let's fix the initial problem differently : a single server may mark itself as ready, and it removes itself once used. The principle is that when we discover that the just queued stream is alone with no active request anywhere ot dequeue it, instead of rebalancing it, it will be assigned to that current "ready" server that is available to handle it. The extra cost of the atomic ops is negligible since the situation is super rare.
2024-12-05 09:30:06 -05:00
MEDIUM: server: add and use a separate last_change variable for internal use last_change server metric is used for 2 separate purposes. First it is used to report last server state change date for stats and other related metrics. But it is also used internally, including in sensitive paths, such as lb related stuff to take decision or perform computations (ie: in srv_dynamic_maxconn()). Due to last_change counter now being split over thread groups since 16eb0fa ("MAJOR: counters: dispatch counters over thread groups"), reading the aggregated value has a cost, and we cannot afford to consult last_change value from srv_dynamic_maxconn() anymore. Moreover, since the value is used to take decision for the current process we don't wan't the variable to be updated by another process in our back. To prevent performance regression and sharing issues, let's instead add a separate srv->last_change value, which is not updated atomically (given how rare the updates are), and only serves for places where the use of the aggregated last_change counter/stats (split over thread groups) is too costly.
2025-06-30 04:57:29 -04:00
s->last_change = ns_to_sec(now_ns);
MEDIUM: counters: mostly revert da813ae4d7cb77137ed Contrarily to what was previously believed, there are corner cases where the counters may not be allocated, and we may want to make them optional at a later date, so we have to check if those counters are there. However, just checking that shared.tg is non-NULL is enough, we can then assume that shared.tg[tgid - 1] has properly been allocated too. Also modify the various COUNTER_SHARED_* macros to make sure they check for that too.
2026-01-14 05:37:49 -05:00
if (s->counters.shared.tg)
HA_ATOMIC_STORE(&s->counters.shared.tg[tgid - 1]->last_state_change, s->last_change);
MINOR: server/event_hdl: add SERVER_STATE event Adding a new SERVER event in the event_hdl API. SERVER_STATE is implemented as an advanced server event. It is published each time the server's effective state changes. (when s->cur_state changes) SERVER_STATE data is an event_hdl_cb_data_server_state struct that provides additional info related to the server state change, but can be casted as a regular event_hdl_cb_data_server struct if additional info is not needed.
2023-04-04 15:28:07 -04:00
/* publish the state change */
_srv_event_hdl_prepare_state(&cb_data.state,
s, type, cause, srv_prev_state, requeued);
_srv_event_hdl_publish(EVENT_HDL_SUB_SERVER_STATE, cb_data.state, s);
BUG/MINOR: server: don't miss server stats update on server state transitions s->last_change and s->down_time updates were manually updated for each effective server state change within srv_update_status(). This is rather error-prone, and as a result there were still some state transitions that were not handled properly since at least 1.8. ie: - when transitionning from DRAIN to READY: downtime was updated (which is wrong since a server in DRAIN state should not be considered as DOWN) - when transitionning from MAINT to READY: downtime was not updated (this can be easily seen in the html stats page) To fix these all at once, and prevent similar bugs from being introduced, we centralize the server last_change and down_time stats logic at the end of srv_update_status(): If the server state changed during the call, then it means that last_change must be updated, with a special case when changing from STOPPED state which means the server was previously DOWN and thus downtime should be updated. This patch depends on: - "MINOR: server: explicitly commit state change in srv_update_status()" This could be backported to every stable versions.
2023-04-18 07:52:27 -04:00
}
BUG/MINOR: server: don't miss proxy stats update on server state transitions backend "down" stats logic has been duplicated multiple times in srv_update_status(), resulting in the logic now being error-prone. For example, the following bugfix was needed to compensate for a copy-paste introduced bug: d332f139 ("BUG/MINOR: server: update last_change on maint->ready transitions too") While the above patch works great, we actually forgot to update the proxy downtime like it is done for other down->up transitions... This is simply illustrating that the current design is error-prone, it is very easy to miss something in this area. To properly update the proxy downtime stats on the maint->ready transition, to cleanup srv_update_status() and to prevent similar bugs from being introduced in the future, proxy/backend stats update are now automatically performed at the end of the server state change if needed. Thus we can remove existing updates that were performed at various places within the function, this simplifies things a bit. This patch depends on: - "MINOR: server: explicitly commit state change in srv_update_status()" This could be backported to all stable versions. Backport notes: 2.2: Replace struct task *srv_cleanup_toremove_conns(struct task *task, void *context, unsigned int state) by struct task *srv_cleanup_toremove_connections(struct task *task, void *context, unsigned short state)
2023-04-17 09:30:11 -04:00
/* check if backend stats must be updated due to the server state change */
if (prev_srv_count && s->proxy->srv_bck == 0 && s->proxy->srv_act == 0)
set_backend_down(s->proxy); /* backend going down */
else if (!prev_srv_count && (s->proxy->srv_bck || s->proxy->srv_act)) {
MEDIUM: proxy: add and use a separate last_change variable for internal use Same motivation as previous commit, proxy last_change is "abused" because it is used for 2 different purposes, one for stats, and the other one for process-local internal use. Let's add a separate proxy-only last_change variable for internal use, and leave the last_change shared (and thread-grouped) counter for statistics.
2025-06-30 09:45:44 -04:00
unsigned long last_change = s->proxy->last_change;
MAJOR: counters: add shared counters base infrastructure Shareable counters are not tagged as shared counters and are dynamically allocated in separate memory area as a prerequisite for being stored in shared memory area. For now, GUID and threads groups are not taken into account, this is only a first step. also we ensure all counters are now manipulated using atomic operations, namely, "last_change" counter is now read from and written to using atomic ops. Despite the numerous changes caused by the counters being moved away from counters struct, no change of behavior should be expected.
2025-04-08 12:16:38 -04:00
BUG/MINOR: server: don't miss proxy stats update on server state transitions backend "down" stats logic has been duplicated multiple times in srv_update_status(), resulting in the logic now being error-prone. For example, the following bugfix was needed to compensate for a copy-paste introduced bug: d332f139 ("BUG/MINOR: server: update last_change on maint->ready transitions too") While the above patch works great, we actually forgot to update the proxy downtime like it is done for other down->up transitions... This is simply illustrating that the current design is error-prone, it is very easy to miss something in this area. To properly update the proxy downtime stats on the maint->ready transition, to cleanup srv_update_status() and to prevent similar bugs from being introduced in the future, proxy/backend stats update are now automatically performed at the end of the server state change if needed. Thus we can remove existing updates that were performed at various places within the function, this simplifies things a bit. This patch depends on: - "MINOR: server: explicitly commit state change in srv_update_status()" This could be backported to all stable versions. Backport notes: 2.2: Replace struct task *srv_cleanup_toremove_conns(struct task *task, void *context, unsigned int state) by struct task *srv_cleanup_toremove_connections(struct task *task, void *context, unsigned short state)
2023-04-17 09:30:11 -04:00
/* backend was down and is back up again:
* no helper function, updating last_change and backend downtime stats
*/
MAJOR: counters: add shared counters base infrastructure Shareable counters are not tagged as shared counters and are dynamically allocated in separate memory area as a prerequisite for being stored in shared memory area. For now, GUID and threads groups are not taken into account, this is only a first step. also we ensure all counters are now manipulated using atomic operations, namely, "last_change" counter is now read from and written to using atomic ops. Despite the numerous changes caused by the counters being moved away from counters struct, no change of behavior should be expected.
2025-04-08 12:16:38 -04:00
if (last_change < ns_to_sec(now_ns)) // ignore negative times
s->proxy->down_time += ns_to_sec(now_ns) - last_change;
MEDIUM: proxy: add and use a separate last_change variable for internal use Same motivation as previous commit, proxy last_change is "abused" because it is used for 2 different purposes, one for stats, and the other one for process-local internal use. Let's add a separate proxy-only last_change variable for internal use, and leave the last_change shared (and thread-grouped) counter for statistics.
2025-06-30 09:45:44 -04:00
s->proxy->last_change = ns_to_sec(now_ns);
MEDIUM: counters: mostly revert da813ae4d7cb77137ed Contrarily to what was previously believed, there are corner cases where the counters may not be allocated, and we may want to make them optional at a later date, so we have to check if those counters are there. However, just checking that shared.tg is non-NULL is enough, we can then assume that shared.tg[tgid - 1] has properly been allocated too. Also modify the various COUNTER_SHARED_* macros to make sure they check for that too.
2026-01-14 05:37:49 -05:00
if (s->proxy->be_counters.shared.tg)
HA_ATOMIC_STORE(&s->proxy->be_counters.shared.tg[tgid - 1]->last_state_change, s->proxy->last_change);
BUG/MINOR: server: don't miss proxy stats update on server state transitions backend "down" stats logic has been duplicated multiple times in srv_update_status(), resulting in the logic now being error-prone. For example, the following bugfix was needed to compensate for a copy-paste introduced bug: d332f139 ("BUG/MINOR: server: update last_change on maint->ready transitions too") While the above patch works great, we actually forgot to update the proxy downtime like it is done for other down->up transitions... This is simply illustrating that the current design is error-prone, it is very easy to miss something in this area. To properly update the proxy downtime stats on the maint->ready transition, to cleanup srv_update_status() and to prevent similar bugs from being introduced in the future, proxy/backend stats update are now automatically performed at the end of the server state change if needed. Thus we can remove existing updates that were performed at various places within the function, this simplifies things a bit. This patch depends on: - "MINOR: server: explicitly commit state change in srv_update_status()" This could be backported to all stable versions. Backport notes: 2.2: Replace struct task *srv_cleanup_toremove_conns(struct task *task, void *context, unsigned int state) by struct task *srv_cleanup_toremove_connections(struct task *task, void *context, unsigned short state)
2023-04-17 09:30:11 -04:00
}
MAJOR: servers: propagate server status changes asynchronously. In order to prepare multi-thread development, code was re-worked to propagate changes asynchronoulsy. Servers with pending status changes are registered in a list and this one is processed and emptied only once 'run poll' loop. Operational status changes are performed before administrative status changes. In a case of multiple operational status change or admin status change in the same 'run poll' loop iteration, those changes are merged to reach only the targeted status.
2017-10-03 08:46:45 -04:00
}
MEDIUM: task: extend the state field to 32 bits It's been too short for quite a while now and is now full. It's still time to extend it to 32-bits since we have room for this without wasting any space, so we now gained 16 new bits for future flags. The values were not reassigned just in case there would be a few hidden u16 or short somewhere in which these flags are placed (as it used to be the case with stream->pending_events). The patch is tagged MEDIUM because this required to update the task's process() prototype to use an int instead of a short, that's quite a bunch of places.
2021-03-02 10:09:26 -05:00
struct task *srv_cleanup_toremove_conns(struct task *task, void *context, unsigned int state)
MEDIUM: servers: Add a way to keep idle connections alive. Add a new keyword for servers, "idle-timeout". If set, unused connections are kept alive until the timeout happens, and will be picked for reuse if no other connection is available.
2018-12-02 08:11:41 -05:00
{
MEDIUM: servers: Reorganize the way idle connections are cleaned. Instead of having one task per thread and per server that does clean the idling connections, have only one global task for every servers. That tasks parses all the servers that currently have idling connections, and remove half of them, to put them in a per-thread list of connections to kill. For each thread that does have connections to kill, wake a task to do so, so that the cleaning will be done in the context of said thread.
2019-02-14 12:29:09 -05:00
struct connection *conn;
MEDIUM: servers: Replace idle-timeout with pool-purge-delay. Instead of the old "idle-timeout" mechanism, add a new option, "pool-purge-delay", that sets the delay before purging idle connections. Each time the delay happens, we destroy half of the idle connections.
2018-12-14 12:15:36 -05:00
MINOR: connection: align toremove_{lock,connections} and cleanup into idle_conns We used to have 3 thread-based arrays for toremove_lock, idle_cleanup, and toremove_connections. The problem is that these items are small, and that this creates false sharing between threads since it's possible to pack up to 8-16 of these values into a single cache line. This can cause real damage where there is contention on the lock. This patch creates a new array of struct "idle_conns" that is aligned on a cache line and which contains all three members above. This way each thread has access to its variables without hindering the other ones. Just doing this increased the HTTP/1 request rate by 5% on a 16-thread machine. The definition was moved to connection.{c,h} since it appeared a more natural evolution of the ongoing changes given that there was already one of them declared in connection.h previously.
2020-06-27 18:19:17 -04:00
while ((conn = MT_LIST_POP(&idle_conns[tid].toremove_conns,
MEDIUM: connection: replace idle conn lists by eb trees The server idle/safe/available connection lists are replaced with ebmb- trees. This is used to store backend connections, with the new field connection hash as the key. The hash is a 8-bytes size field, used to reflect specific connection parameters. This is a preliminary work to be able to reuse connection with SNI, explicit src/dst address or PROXY protocol.
2021-01-06 10:14:12 -05:00
struct connection *, toremove_list)) != NULL) {
MINOR: muxes: Pass the context of the mux to destroy() instead of the connection It is mandatory to handle mux upgrades, because during a mux upgrade, the connection will be reassigned to another multiplexer. So when the old one is destroyed, it does not own the connection anymore. Or in other words, conn->ctx does not point to the old mux's context when its destroy() callback is called. So we now rely on the multiplexer context do destroy it instead of the connection. In addition, h1_release() and h2_release() have also been updated in the same way.
2019-04-08 05:23:22 -04:00
conn->mux->destroy(conn->ctx);
MEDIUM: servers: Reorganize the way idle connections are cleaned. Instead of having one task per thread and per server that does clean the idling connections, have only one global task for every servers. That tasks parses all the servers that currently have idling connections, and remove half of them, to put them in a per-thread list of connections to kill. For each thread that does have connections to kill, wake a task to do so, so that the cleaning will be done in the context of said thread.
2019-02-14 12:29:09 -05:00
}
MEDIUM: servers: Replace idle-timeout with pool-purge-delay. Instead of the old "idle-timeout" mechanism, add a new option, "pool-purge-delay", that sets the delay before purging idle connections. Each time the delay happens, we destroy half of the idle connections.
2018-12-14 12:15:36 -05:00
MEDIUM: servers: Reorganize the way idle connections are cleaned. Instead of having one task per thread and per server that does clean the idling connections, have only one global task for every servers. That tasks parses all the servers that currently have idling connections, and remove half of them, to put them in a per-thread list of connections to kill. For each thread that does have connections to kill, wake a task to do so, so that the cleaning will be done in the context of said thread.
2019-02-14 12:29:09 -05:00
return task;
}
MEDIUM: servers: Add a way to keep idle connections alive. Add a new keyword for servers, "idle-timeout". If set, unused connections are kept alive until the timeout happens, and will be picked for reuse if no other connection is available.
2018-12-02 08:11:41 -05:00
MINOR: server: pass the server and thread to srv_migrate_conns_to_remove() We'll need to have access to the srv_per_thread element soon from this function, and there's no particular reason for passing it list pointers so let's pass the server and the thread so that it is autonomous. It also makes the calling code simpler.
2025-09-12 10:24:16 -04:00
/* Move <toremove_nb> count connections from server <srv> list storage
* ->idle_conn_list to the idle_conns list 'toremove_conns' for thread <thr>.
* -1 means moving all of them.
MAJOR: connection: purge idle conn by last usage Backend idle connections are purged on a recurring occurence during the process lifetime. An estimated number of needed connections is calculated and the excess is removed periodically. Before this patch, purge was done directly using the idle then the safe connection tree of a server instance. This has a major drawback to take no account of a specific ordre and it may removed functional connections while leaving ones which will fail on the next reuse. The problem can be worse when using criteria to differentiate idle connections such as the SSL SNI. In this case, purge may remove connections with a high rate of reusing while leaving connections with criteria never matched once, thus reducing drastically the reuse rate. To improve this, introduce an alternative storage for idle connection used in parallel of the idle/safe trees. Now, each connection inserted in one of this tree is also inserted in the new list at `srv_per_thread.idle_conn_list`. This guarantees that recently used connection is present at the end of the list. During the purge, use this list instead of idle/safe trees. Remove first connection in front of the list which were not reused recently. This will ensure that connection that are frequently reused are not purged and should increase the reuse rate, particularily if distinct idle connection criterias are in used.
2023-08-21 12:32:29 -04:00
*
MEDIUM: connections: Don't use a lock when moving connections to remove. Make it so we don't have to take a lock while moving a connection from the idle list to the toremove_list by taking advantage of the MT_LIST.
2020-06-29 14:15:59 -04:00
* Returns the number of connections moved.
MEDIUM: connection: protect idle conn lists with locks This is a preparation work for connection reuse with sni/proxy protocol/specific src-dst addresses. Protect every access to idle conn lists with a lock. This is currently strictly not needed because the access to the list are made with atomic operations. However, to be able to reuse connection with specific parameters, the list storage will be converted to eb-trees. As this structure does not have atomic operation, it is mandatory to protect it with a lock. For this, the takeover lock is reused. Its role was to protect during connection takeover. As it is now extended to general idle conns usage, it is renamed to idle_conns_lock. A new lock section is also instantiated named IDLE_CONNS_LOCK to isolate its impact on performance.
2021-01-11 03:21:52 -05:00
*
* Must be called with idle_conns_lock held.
MEDIUM: connections: Don't use a lock when moving connections to remove. Make it so we don't have to take a lock while moving a connection from the idle list to the toremove_list by taking advantage of the MT_LIST.
2020-06-29 14:15:59 -04:00
*/
MINOR: server: pass the server and thread to srv_migrate_conns_to_remove() We'll need to have access to the srv_per_thread element soon from this function, and there's no particular reason for passing it list pointers so let's pass the server and the thread so that it is autonomous. It also makes the calling code simpler.
2025-09-12 10:24:16 -04:00
static int srv_migrate_conns_to_remove(struct server *srv, int thr, int toremove_nb)
MEDIUM: connections: Don't use a lock when moving connections to remove. Make it so we don't have to take a lock while moving a connection from the idle list to the toremove_list by taking advantage of the MT_LIST.
2020-06-29 14:15:59 -04:00
{
MAJOR: connection: purge idle conn by last usage Backend idle connections are purged on a recurring occurence during the process lifetime. An estimated number of needed connections is calculated and the excess is removed periodically. Before this patch, purge was done directly using the idle then the safe connection tree of a server instance. This has a major drawback to take no account of a specific ordre and it may removed functional connections while leaving ones which will fail on the next reuse. The problem can be worse when using criteria to differentiate idle connections such as the SSL SNI. In this case, purge may remove connections with a high rate of reusing while leaving connections with criteria never matched once, thus reducing drastically the reuse rate. To improve this, introduce an alternative storage for idle connection used in parallel of the idle/safe trees. Now, each connection inserted in one of this tree is also inserted in the new list at `srv_per_thread.idle_conn_list`. This guarantees that recently used connection is present at the end of the list. During the purge, use this list instead of idle/safe trees. Remove first connection in front of the list which were not reused recently. This will ensure that connection that are frequently reused are not purged and should increase the reuse rate, particularily if distinct idle connection criterias are in used.
2023-08-21 12:32:29 -04:00
struct connection *conn;
MEDIUM: connections: Don't use a lock when moving connections to remove. Make it so we don't have to take a lock while moving a connection from the idle list to the toremove_list by taking advantage of the MT_LIST.
2020-06-29 14:15:59 -04:00
int i = 0;
MINOR: server: pass the server and thread to srv_migrate_conns_to_remove() We'll need to have access to the srv_per_thread element soon from this function, and there's no particular reason for passing it list pointers so let's pass the server and the thread so that it is autonomous. It also makes the calling code simpler.
2025-09-12 10:24:16 -04:00
while (!LIST_ISEMPTY(&srv->per_thr[thr].idle_conn_list)) {
MEDIUM: connections: Don't use a lock when moving connections to remove. Make it so we don't have to take a lock while moving a connection from the idle list to the toremove_list by taking advantage of the MT_LIST.
2020-06-29 14:15:59 -04:00
if (toremove_nb != -1 && i >= toremove_nb)
break;
MEDIUM: connection: replace idle conn lists by eb trees The server idle/safe/available connection lists are replaced with ebmb- trees. This is used to store backend connections, with the new field connection hash as the key. The hash is a 8-bytes size field, used to reflect specific connection parameters. This is a preliminary work to be able to reuse connection with SNI, explicit src/dst address or PROXY protocol.
2021-01-06 10:14:12 -05:00
MINOR: server: pass the server and thread to srv_migrate_conns_to_remove() We'll need to have access to the srv_per_thread element soon from this function, and there's no particular reason for passing it list pointers so let's pass the server and the thread so that it is autonomous. It also makes the calling code simpler.
2025-09-12 10:24:16 -04:00
conn = LIST_ELEM(srv->per_thr[thr].idle_conn_list.n, struct connection *, idle_list);
Revert "BUG/MEDIUM: connections: permit to permanently remove an idle conn" The target patch fixes a rare race condition which happen when a MUX IO handler is working on a connection already moved into the purge list. In this case, the handler will incorrectly moved back the connection into the idle list. To fix this, conn_delete_from_tree() was extended to remove flags along with the connection from the idle list. This was performed when the connection is moved into the purge list. However, it introduces another issue related to the idle server connection accounting. Thus it is necessary to revert it prior to the incoming newer fix. This patch must be backported to every version where the original commit is.
2025-11-12 11:38:08 -05:00
conn_delete_from_tree(conn, thr);
MINOR: server: pass the server and thread to srv_migrate_conns_to_remove() We'll need to have access to the srv_per_thread element soon from this function, and there's no particular reason for passing it list pointers so let's pass the server and the thread so that it is autonomous. It also makes the calling code simpler.
2025-09-12 10:24:16 -04:00
MT_LIST_APPEND(&idle_conns[thr].toremove_conns, &conn->toremove_list);
MEDIUM: connections: Don't use a lock when moving connections to remove. Make it so we don't have to take a lock while moving a connection from the idle list to the toremove_list by taking advantage of the MT_LIST.
2020-06-29 14:15:59 -04:00
i++;
}
MAJOR: connection: purge idle conn by last usage Backend idle connections are purged on a recurring occurence during the process lifetime. An estimated number of needed connections is calculated and the excess is removed periodically. Before this patch, purge was done directly using the idle then the safe connection tree of a server instance. This has a major drawback to take no account of a specific ordre and it may removed functional connections while leaving ones which will fail on the next reuse. The problem can be worse when using criteria to differentiate idle connections such as the SSL SNI. In this case, purge may remove connections with a high rate of reusing while leaving connections with criteria never matched once, thus reducing drastically the reuse rate. To improve this, introduce an alternative storage for idle connection used in parallel of the idle/safe trees. Now, each connection inserted in one of this tree is also inserted in the new list at `srv_per_thread.idle_conn_list`. This guarantees that recently used connection is present at the end of the list. During the purge, use this list instead of idle/safe trees. Remove first connection in front of the list which were not reused recently. This will ensure that connection that are frequently reused are not purged and should increase the reuse rate, particularily if distinct idle connection criterias are in used.
2023-08-21 12:32:29 -04:00
MEDIUM: connections: Don't use a lock when moving connections to remove. Make it so we don't have to take a lock while moving a connection from the idle list to the toremove_list by taking advantage of the MT_LIST.
2020-06-29 14:15:59 -04:00
return i;
}
BUG/MEDIUM: connections: force connections cleanup on server changes I've been trying to understand a change of behaviour between v2.2dev5 and v2.2dev6. Indeed our probe is regularly testing to add and remove servers on a given backend such as: # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 263 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 0.0.0.0 0 1 256 256 0 15 3 0 14 0 0 0 - 0 - -> curl on the corresponding frontend: reply from server:31255 # echo "set server be_foo/srv1 addr 10.236.139.34 port 31257" | sudo socat stdio /var/lib/haproxy/stats IP changed from '0.0.0.0' to '10.236.139.34', port changed from '0' to '31257' by 'stats socket command' # echo "set server be_foo/srv1 weight 256" | sudo socat stdio /var/lib/haproxy/stats # echo "set server be_foo/srv1 check-port 8500" | sudo socat stdio /var/lib/haproxy/stats health check port updated. # echo "set server be_foo/srv1 state ready" | sudo socat stdio /var/lib/haproxy/stats # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 105 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 10.236.139.34 2 0 256 256 2319 15 3 2 6 0 0 0 - 31257 - -> curl on the corresponding frontend: reply for server:31257 (notice the difference of weight) # echo "set server be_foo/srv1 state maint" | sudo socat stdio /var/lib/haproxy/stats # echo "set server be_foo/srv1 addr 0.0.0.0 port 0" | sudo socat stdio /var/lib/haproxy/stats IP changed from '10.236.139.34' to '0.0.0.0', port changed from '31257' to '0' by 'stats socket command' # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 263 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 0.0.0.0 0 1 256 256 0 15 3 0 14 0 0 0 - 0 - -> curl on the corresponding frontend: reply from server:31255 # echo "set server be_foo/srv1 addr 10.236.139.34 port 31256" | sudo socat stdio /var/lib/haproxy/stats IP changed from '0.0.0.0' to '10.236.139.34', port changed from '0' to '31256' by 'stats socket command' # echo "set server be_foo/srv1 weight 256" | sudo socat stdio /var/lib/haproxy/stats # echo "set server be_foo/srv1 check-port 8500" | sudo socat stdio /var/lib/haproxy/stats health check port updated. # echo "set server be_foo/srv1 state ready" | sudo socat stdio /var/lib/haproxy/stats # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 105 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 10.236.139.34 2 0 256 256 2319 15 3 2 6 0 0 0 - 31256 - -> curl on the corresponding frontend: reply from server:31257 (!) Here we indeed would expect to get an anver from server:31256. The issue is highly linked to the usage of `pool-purge-delay`, with a value which is higher than the duration of the test, 10s in our case. a git bisect between dev5 and dev6 seems to show commit 079cb9af22da6 ("MEDIUM: connections: Revamp the way idle connections are killed") being the origin of this new behaviour. So if I understand the later correctly, it seems that it was more a matter of chance that we did not saw the issue earlier. My patch proposes to force clean idle connections in the two following cases: - we set a (still running) server to maintenance - we change the ip/port of a server This commit should be backported to 2.1, 2.0, and 1.9. Signed-off-by: William Dauchy <w.dauchy@criteo.com>
2020-05-02 15:52:36 -04:00
/* cleanup connections for a given server
* might be useful when going on forced maintenance or live changing ip/port
*/
CLEANUP: connections: align function declaration srv_cleanup_connections() is supposed to be static, so mark it as so. This patch should be backported where commit 6318d33ce625 ("BUG/MEDIUM: connections: force connections cleanup on server changes") will be backported, that is to say v1.9 to v2.1. Fixes: 6318d33ce625 ("BUG/MEDIUM: connections: force connections cleanup on server changes") Signed-off-by: William Dauchy <w.dauchy@criteo.com>
2020-05-04 07:52:40 -04:00
static void srv_cleanup_connections(struct server *srv)
BUG/MEDIUM: connections: force connections cleanup on server changes I've been trying to understand a change of behaviour between v2.2dev5 and v2.2dev6. Indeed our probe is regularly testing to add and remove servers on a given backend such as: # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 263 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 0.0.0.0 0 1 256 256 0 15 3 0 14 0 0 0 - 0 - -> curl on the corresponding frontend: reply from server:31255 # echo "set server be_foo/srv1 addr 10.236.139.34 port 31257" | sudo socat stdio /var/lib/haproxy/stats IP changed from '0.0.0.0' to '10.236.139.34', port changed from '0' to '31257' by 'stats socket command' # echo "set server be_foo/srv1 weight 256" | sudo socat stdio /var/lib/haproxy/stats # echo "set server be_foo/srv1 check-port 8500" | sudo socat stdio /var/lib/haproxy/stats health check port updated. # echo "set server be_foo/srv1 state ready" | sudo socat stdio /var/lib/haproxy/stats # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 105 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 10.236.139.34 2 0 256 256 2319 15 3 2 6 0 0 0 - 31257 - -> curl on the corresponding frontend: reply for server:31257 (notice the difference of weight) # echo "set server be_foo/srv1 state maint" | sudo socat stdio /var/lib/haproxy/stats # echo "set server be_foo/srv1 addr 0.0.0.0 port 0" | sudo socat stdio /var/lib/haproxy/stats IP changed from '10.236.139.34' to '0.0.0.0', port changed from '31257' to '0' by 'stats socket command' # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 263 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 0.0.0.0 0 1 256 256 0 15 3 0 14 0 0 0 - 0 - -> curl on the corresponding frontend: reply from server:31255 # echo "set server be_foo/srv1 addr 10.236.139.34 port 31256" | sudo socat stdio /var/lib/haproxy/stats IP changed from '0.0.0.0' to '10.236.139.34', port changed from '0' to '31256' by 'stats socket command' # echo "set server be_foo/srv1 weight 256" | sudo socat stdio /var/lib/haproxy/stats # echo "set server be_foo/srv1 check-port 8500" | sudo socat stdio /var/lib/haproxy/stats health check port updated. # echo "set server be_foo/srv1 state ready" | sudo socat stdio /var/lib/haproxy/stats # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 105 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 10.236.139.34 2 0 256 256 2319 15 3 2 6 0 0 0 - 31256 - -> curl on the corresponding frontend: reply from server:31257 (!) Here we indeed would expect to get an anver from server:31256. The issue is highly linked to the usage of `pool-purge-delay`, with a value which is higher than the duration of the test, 10s in our case. a git bisect between dev5 and dev6 seems to show commit 079cb9af22da6 ("MEDIUM: connections: Revamp the way idle connections are killed") being the origin of this new behaviour. So if I understand the later correctly, it seems that it was more a matter of chance that we did not saw the issue earlier. My patch proposes to force clean idle connections in the two following cases: - we set a (still running) server to maintenance - we change the ip/port of a server This commit should be backported to 2.1, 2.0, and 1.9. Signed-off-by: William Dauchy <w.dauchy@criteo.com>
2020-05-02 15:52:36 -04:00
{
MAJOR: server: implement purging of private idle connections When a server goes into maintenance, or if its IP address is changed, idle connections attached to it are scheduled for deletion via the purge mechanism. Connections are moved from server idle/safe list to the purge list relative to their thread. Connections are freed on their owned thread by the scheduled purge task. This patch extends this procedure to also handle private idle connections stored in sessions instead of servers. This is possible thanks via <sess_conns> list server member. A call to the newly defined-function session_purge_conns() is performed on each list element. This moves private connections from their session to the purge list alongside other server idle connections. This change relies on the serie of previous commits which ensure that access to private idle connections is now thread-safe, with idle_conns lock usage and careful manipulation of private idle conns in input/output handlers. The main benefit of this patch is that now all idle connections targetting a server set in maintenance are removed. Previously, private connections would remain until their attach sessions were closed.
2025-08-08 11:13:43 -04:00
struct sess_priv_conns *sess_conns;
BUG/MEDIUM: connections: force connections cleanup on server changes I've been trying to understand a change of behaviour between v2.2dev5 and v2.2dev6. Indeed our probe is regularly testing to add and remove servers on a given backend such as: # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 263 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 0.0.0.0 0 1 256 256 0 15 3 0 14 0 0 0 - 0 - -> curl on the corresponding frontend: reply from server:31255 # echo "set server be_foo/srv1 addr 10.236.139.34 port 31257" | sudo socat stdio /var/lib/haproxy/stats IP changed from '0.0.0.0' to '10.236.139.34', port changed from '0' to '31257' by 'stats socket command' # echo "set server be_foo/srv1 weight 256" | sudo socat stdio /var/lib/haproxy/stats # echo "set server be_foo/srv1 check-port 8500" | sudo socat stdio /var/lib/haproxy/stats health check port updated. # echo "set server be_foo/srv1 state ready" | sudo socat stdio /var/lib/haproxy/stats # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 105 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 10.236.139.34 2 0 256 256 2319 15 3 2 6 0 0 0 - 31257 - -> curl on the corresponding frontend: reply for server:31257 (notice the difference of weight) # echo "set server be_foo/srv1 state maint" | sudo socat stdio /var/lib/haproxy/stats # echo "set server be_foo/srv1 addr 0.0.0.0 port 0" | sudo socat stdio /var/lib/haproxy/stats IP changed from '10.236.139.34' to '0.0.0.0', port changed from '31257' to '0' by 'stats socket command' # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 263 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 0.0.0.0 0 1 256 256 0 15 3 0 14 0 0 0 - 0 - -> curl on the corresponding frontend: reply from server:31255 # echo "set server be_foo/srv1 addr 10.236.139.34 port 31256" | sudo socat stdio /var/lib/haproxy/stats IP changed from '0.0.0.0' to '10.236.139.34', port changed from '0' to '31256' by 'stats socket command' # echo "set server be_foo/srv1 weight 256" | sudo socat stdio /var/lib/haproxy/stats # echo "set server be_foo/srv1 check-port 8500" | sudo socat stdio /var/lib/haproxy/stats health check port updated. # echo "set server be_foo/srv1 state ready" | sudo socat stdio /var/lib/haproxy/stats # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 105 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 10.236.139.34 2 0 256 256 2319 15 3 2 6 0 0 0 - 31256 - -> curl on the corresponding frontend: reply from server:31257 (!) Here we indeed would expect to get an anver from server:31256. The issue is highly linked to the usage of `pool-purge-delay`, with a value which is higher than the duration of the test, 10s in our case. a git bisect between dev5 and dev6 seems to show commit 079cb9af22da6 ("MEDIUM: connections: Revamp the way idle connections are killed") being the origin of this new behaviour. So if I understand the later correctly, it seems that it was more a matter of chance that we did not saw the issue earlier. My patch proposes to force clean idle connections in the two following cases: - we set a (still running) server to maintenance - we change the ip/port of a server This commit should be backported to 2.1, 2.0, and 1.9. Signed-off-by: William Dauchy <w.dauchy@criteo.com>
2020-05-02 15:52:36 -04:00
int did_remove;
int i;
BUG/MINOR: srv: do not cleanup idle conns if pool max is null If a server is configured to not have any idle conns, returns immediatly from srv_cleanup_connections. This avoids a segfault when a server is configured with pool-max-conn to 0. This should be backported up to 2.2.
2021-01-06 08:28:51 -05:00
/* nothing to do if pool-max-conn is null */
if (!srv->max_idle_conns)
return;
BUG/MINOR: server: start cleaning idle connections from various points There's a minor glitch with the way idle connections start to be evicted. The lookup always goes from thread 0 to thread N-1. This causes depletion of connections on the first threads and abundance on the last ones. This is visible with the takeover() stats below: $ socat - /tmp/sock1 <<< "show activity"|grep ^fd ; \ sleep 10 ; \ socat -/tmp/sock1 <<< "show activity"|grep ^fd fd_takeover: 300144 [ 91887 84029 66254 57974 ] fd_takeover: 359631 [ 111369 99699 79145 69418 ] There are respectively 19k, 15k, 13k and 11k takeovers for only 4 threads, indicating that the first thread needs a foreign FD twice more often than the 4th one. This patch changes this si that all threads are scanned in round robin starting with the current one. The takeovers now happen in a much more distributed way (about 4 times 9k) : fd_takeover: 1420081 [ 359562 359453 346586 354480 ] fd_takeover: 1457044 [ 368779 368429 355990 363846 ] There is no need to backport this, as this happened along a few patches that were merged during 2.2 development.
2020-06-29 08:43:16 -04:00
/* check all threads starting with ours */
for (i = tid;;) {
BUG/MEDIUM: connections: force connections cleanup on server changes I've been trying to understand a change of behaviour between v2.2dev5 and v2.2dev6. Indeed our probe is regularly testing to add and remove servers on a given backend such as: # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 263 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 0.0.0.0 0 1 256 256 0 15 3 0 14 0 0 0 - 0 - -> curl on the corresponding frontend: reply from server:31255 # echo "set server be_foo/srv1 addr 10.236.139.34 port 31257" | sudo socat stdio /var/lib/haproxy/stats IP changed from '0.0.0.0' to '10.236.139.34', port changed from '0' to '31257' by 'stats socket command' # echo "set server be_foo/srv1 weight 256" | sudo socat stdio /var/lib/haproxy/stats # echo "set server be_foo/srv1 check-port 8500" | sudo socat stdio /var/lib/haproxy/stats health check port updated. # echo "set server be_foo/srv1 state ready" | sudo socat stdio /var/lib/haproxy/stats # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 105 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 10.236.139.34 2 0 256 256 2319 15 3 2 6 0 0 0 - 31257 - -> curl on the corresponding frontend: reply for server:31257 (notice the difference of weight) # echo "set server be_foo/srv1 state maint" | sudo socat stdio /var/lib/haproxy/stats # echo "set server be_foo/srv1 addr 0.0.0.0 port 0" | sudo socat stdio /var/lib/haproxy/stats IP changed from '10.236.139.34' to '0.0.0.0', port changed from '31257' to '0' by 'stats socket command' # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 263 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 0.0.0.0 0 1 256 256 0 15 3 0 14 0 0 0 - 0 - -> curl on the corresponding frontend: reply from server:31255 # echo "set server be_foo/srv1 addr 10.236.139.34 port 31256" | sudo socat stdio /var/lib/haproxy/stats IP changed from '0.0.0.0' to '10.236.139.34', port changed from '0' to '31256' by 'stats socket command' # echo "set server be_foo/srv1 weight 256" | sudo socat stdio /var/lib/haproxy/stats # echo "set server be_foo/srv1 check-port 8500" | sudo socat stdio /var/lib/haproxy/stats health check port updated. # echo "set server be_foo/srv1 state ready" | sudo socat stdio /var/lib/haproxy/stats # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 105 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 10.236.139.34 2 0 256 256 2319 15 3 2 6 0 0 0 - 31256 - -> curl on the corresponding frontend: reply from server:31257 (!) Here we indeed would expect to get an anver from server:31256. The issue is highly linked to the usage of `pool-purge-delay`, with a value which is higher than the duration of the test, 10s in our case. a git bisect between dev5 and dev6 seems to show commit 079cb9af22da6 ("MEDIUM: connections: Revamp the way idle connections are killed") being the origin of this new behaviour. So if I understand the later correctly, it seems that it was more a matter of chance that we did not saw the issue earlier. My patch proposes to force clean idle connections in the two following cases: - we set a (still running) server to maintenance - we change the ip/port of a server This commit should be backported to 2.1, 2.0, and 1.9. Signed-off-by: William Dauchy <w.dauchy@criteo.com>
2020-05-02 15:52:36 -04:00
did_remove = 0;
MEDIUM: connection: protect idle conn lists with locks This is a preparation work for connection reuse with sni/proxy protocol/specific src-dst addresses. Protect every access to idle conn lists with a lock. This is currently strictly not needed because the access to the list are made with atomic operations. However, to be able to reuse connection with specific parameters, the list storage will be converted to eb-trees. As this structure does not have atomic operation, it is mandatory to protect it with a lock. For this, the takeover lock is reused. Its role was to protect during connection takeover. As it is now extended to general idle conns usage, it is renamed to idle_conns_lock. A new lock section is also instantiated named IDLE_CONNS_LOCK to isolate its impact on performance.
2021-01-11 03:21:52 -05:00
HA_SPIN_LOCK(IDLE_CONNS_LOCK, &idle_conns[i].idle_conns_lock);
MAJOR: server: implement purging of private idle connections When a server goes into maintenance, or if its IP address is changed, idle connections attached to it are scheduled for deletion via the purge mechanism. Connections are moved from server idle/safe list to the purge list relative to their thread. Connections are freed on their owned thread by the scheduled purge task. This patch extends this procedure to also handle private idle connections stored in sessions instead of servers. This is possible thanks via <sess_conns> list server member. A call to the newly defined-function session_purge_conns() is performed on each list element. This moves private connections from their session to the purge list alongside other server idle connections. This change relies on the serie of previous commits which ensure that access to private idle connections is now thread-safe, with idle_conns lock usage and careful manipulation of private idle conns in input/output handlers. The main benefit of this patch is that now all idle connections targetting a server set in maintenance are removed. Previously, private connections would remain until their attach sessions were closed.
2025-08-08 11:13:43 -04:00
/* idle connections */
MINOR: server: pass the server and thread to srv_migrate_conns_to_remove() We'll need to have access to the srv_per_thread element soon from this function, and there's no particular reason for passing it list pointers so let's pass the server and the thread so that it is autonomous. It also makes the calling code simpler.
2025-09-12 10:24:16 -04:00
if (srv_migrate_conns_to_remove(srv, i, -1) > 0)
BUG/MEDIUM: connections: force connections cleanup on server changes I've been trying to understand a change of behaviour between v2.2dev5 and v2.2dev6. Indeed our probe is regularly testing to add and remove servers on a given backend such as: # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 263 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 0.0.0.0 0 1 256 256 0 15 3 0 14 0 0 0 - 0 - -> curl on the corresponding frontend: reply from server:31255 # echo "set server be_foo/srv1 addr 10.236.139.34 port 31257" | sudo socat stdio /var/lib/haproxy/stats IP changed from '0.0.0.0' to '10.236.139.34', port changed from '0' to '31257' by 'stats socket command' # echo "set server be_foo/srv1 weight 256" | sudo socat stdio /var/lib/haproxy/stats # echo "set server be_foo/srv1 check-port 8500" | sudo socat stdio /var/lib/haproxy/stats health check port updated. # echo "set server be_foo/srv1 state ready" | sudo socat stdio /var/lib/haproxy/stats # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 105 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 10.236.139.34 2 0 256 256 2319 15 3 2 6 0 0 0 - 31257 - -> curl on the corresponding frontend: reply for server:31257 (notice the difference of weight) # echo "set server be_foo/srv1 state maint" | sudo socat stdio /var/lib/haproxy/stats # echo "set server be_foo/srv1 addr 0.0.0.0 port 0" | sudo socat stdio /var/lib/haproxy/stats IP changed from '10.236.139.34' to '0.0.0.0', port changed from '31257' to '0' by 'stats socket command' # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 263 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 0.0.0.0 0 1 256 256 0 15 3 0 14 0 0 0 - 0 - -> curl on the corresponding frontend: reply from server:31255 # echo "set server be_foo/srv1 addr 10.236.139.34 port 31256" | sudo socat stdio /var/lib/haproxy/stats IP changed from '0.0.0.0' to '10.236.139.34', port changed from '0' to '31256' by 'stats socket command' # echo "set server be_foo/srv1 weight 256" | sudo socat stdio /var/lib/haproxy/stats # echo "set server be_foo/srv1 check-port 8500" | sudo socat stdio /var/lib/haproxy/stats health check port updated. # echo "set server be_foo/srv1 state ready" | sudo socat stdio /var/lib/haproxy/stats # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 105 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 10.236.139.34 2 0 256 256 2319 15 3 2 6 0 0 0 - 31256 - -> curl on the corresponding frontend: reply from server:31257 (!) Here we indeed would expect to get an anver from server:31256. The issue is highly linked to the usage of `pool-purge-delay`, with a value which is higher than the duration of the test, 10s in our case. a git bisect between dev5 and dev6 seems to show commit 079cb9af22da6 ("MEDIUM: connections: Revamp the way idle connections are killed") being the origin of this new behaviour. So if I understand the later correctly, it seems that it was more a matter of chance that we did not saw the issue earlier. My patch proposes to force clean idle connections in the two following cases: - we set a (still running) server to maintenance - we change the ip/port of a server This commit should be backported to 2.1, 2.0, and 1.9. Signed-off-by: William Dauchy <w.dauchy@criteo.com>
2020-05-02 15:52:36 -04:00
did_remove = 1;
MAJOR: server: implement purging of private idle connections When a server goes into maintenance, or if its IP address is changed, idle connections attached to it are scheduled for deletion via the purge mechanism. Connections are moved from server idle/safe list to the purge list relative to their thread. Connections are freed on their owned thread by the scheduled purge task. This patch extends this procedure to also handle private idle connections stored in sessions instead of servers. This is possible thanks via <sess_conns> list server member. A call to the newly defined-function session_purge_conns() is performed on each list element. This moves private connections from their session to the purge list alongside other server idle connections. This change relies on the serie of previous commits which ensure that access to private idle connections is now thread-safe, with idle_conns lock usage and careful manipulation of private idle conns in input/output handlers. The main benefit of this patch is that now all idle connections targetting a server set in maintenance are removed. Previously, private connections would remain until their attach sessions were closed.
2025-08-08 11:13:43 -04:00
/* session attached connections */
while ((sess_conns = MT_LIST_POP(&srv->per_thr[i].sess_conns, struct sess_priv_conns *, srv_el))) {
if (sess_conns_cleanup_all_idle(sess_conns)) {
did_remove = 1;
if (LIST_ISEMPTY(&sess_conns->conn_list)) {
LIST_DELETE(&sess_conns->sess_el);
pool_free(pool_head_sess_priv_conns, sess_conns);
}
}
}
MEDIUM: connection: protect idle conn lists with locks This is a preparation work for connection reuse with sni/proxy protocol/specific src-dst addresses. Protect every access to idle conn lists with a lock. This is currently strictly not needed because the access to the list are made with atomic operations. However, to be able to reuse connection with specific parameters, the list storage will be converted to eb-trees. As this structure does not have atomic operation, it is mandatory to protect it with a lock. For this, the takeover lock is reused. Its role was to protect during connection takeover. As it is now extended to general idle conns usage, it is renamed to idle_conns_lock. A new lock section is also instantiated named IDLE_CONNS_LOCK to isolate its impact on performance.
2021-01-11 03:21:52 -05:00
HA_SPIN_UNLOCK(IDLE_CONNS_LOCK, &idle_conns[i].idle_conns_lock);
BUG/MEDIUM: connections: force connections cleanup on server changes I've been trying to understand a change of behaviour between v2.2dev5 and v2.2dev6. Indeed our probe is regularly testing to add and remove servers on a given backend such as: # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 263 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 0.0.0.0 0 1 256 256 0 15 3 0 14 0 0 0 - 0 - -> curl on the corresponding frontend: reply from server:31255 # echo "set server be_foo/srv1 addr 10.236.139.34 port 31257" | sudo socat stdio /var/lib/haproxy/stats IP changed from '0.0.0.0' to '10.236.139.34', port changed from '0' to '31257' by 'stats socket command' # echo "set server be_foo/srv1 weight 256" | sudo socat stdio /var/lib/haproxy/stats # echo "set server be_foo/srv1 check-port 8500" | sudo socat stdio /var/lib/haproxy/stats health check port updated. # echo "set server be_foo/srv1 state ready" | sudo socat stdio /var/lib/haproxy/stats # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 105 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 10.236.139.34 2 0 256 256 2319 15 3 2 6 0 0 0 - 31257 - -> curl on the corresponding frontend: reply for server:31257 (notice the difference of weight) # echo "set server be_foo/srv1 state maint" | sudo socat stdio /var/lib/haproxy/stats # echo "set server be_foo/srv1 addr 0.0.0.0 port 0" | sudo socat stdio /var/lib/haproxy/stats IP changed from '10.236.139.34' to '0.0.0.0', port changed from '31257' to '0' by 'stats socket command' # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 263 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 0.0.0.0 0 1 256 256 0 15 3 0 14 0 0 0 - 0 - -> curl on the corresponding frontend: reply from server:31255 # echo "set server be_foo/srv1 addr 10.236.139.34 port 31256" | sudo socat stdio /var/lib/haproxy/stats IP changed from '0.0.0.0' to '10.236.139.34', port changed from '0' to '31256' by 'stats socket command' # echo "set server be_foo/srv1 weight 256" | sudo socat stdio /var/lib/haproxy/stats # echo "set server be_foo/srv1 check-port 8500" | sudo socat stdio /var/lib/haproxy/stats health check port updated. # echo "set server be_foo/srv1 state ready" | sudo socat stdio /var/lib/haproxy/stats # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 105 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 10.236.139.34 2 0 256 256 2319 15 3 2 6 0 0 0 - 31256 - -> curl on the corresponding frontend: reply from server:31257 (!) Here we indeed would expect to get an anver from server:31256. The issue is highly linked to the usage of `pool-purge-delay`, with a value which is higher than the duration of the test, 10s in our case. a git bisect between dev5 and dev6 seems to show commit 079cb9af22da6 ("MEDIUM: connections: Revamp the way idle connections are killed") being the origin of this new behaviour. So if I understand the later correctly, it seems that it was more a matter of chance that we did not saw the issue earlier. My patch proposes to force clean idle connections in the two following cases: - we set a (still running) server to maintenance - we change the ip/port of a server This commit should be backported to 2.1, 2.0, and 1.9. Signed-off-by: William Dauchy <w.dauchy@criteo.com>
2020-05-02 15:52:36 -04:00
if (did_remove)
MINOR: connection: align toremove_{lock,connections} and cleanup into idle_conns We used to have 3 thread-based arrays for toremove_lock, idle_cleanup, and toremove_connections. The problem is that these items are small, and that this creates false sharing between threads since it's possible to pack up to 8-16 of these values into a single cache line. This can cause real damage where there is contention on the lock. This patch creates a new array of struct "idle_conns" that is aligned on a cache line and which contains all three members above. This way each thread has access to its variables without hindering the other ones. Just doing this increased the HTTP/1 request rate by 5% on a 16-thread machine. The definition was moved to connection.{c,h} since it appeared a more natural evolution of the ongoing changes given that there was already one of them declared in connection.h previously.
2020-06-27 18:19:17 -04:00
task_wakeup(idle_conns[i].cleanup_task, TASK_WOKEN_OTHER);
BUG/MINOR: server: start cleaning idle connections from various points There's a minor glitch with the way idle connections start to be evicted. The lookup always goes from thread 0 to thread N-1. This causes depletion of connections on the first threads and abundance on the last ones. This is visible with the takeover() stats below: $ socat - /tmp/sock1 <<< "show activity"|grep ^fd ; \ sleep 10 ; \ socat -/tmp/sock1 <<< "show activity"|grep ^fd fd_takeover: 300144 [ 91887 84029 66254 57974 ] fd_takeover: 359631 [ 111369 99699 79145 69418 ] There are respectively 19k, 15k, 13k and 11k takeovers for only 4 threads, indicating that the first thread needs a foreign FD twice more often than the 4th one. This patch changes this si that all threads are scanned in round robin starting with the current one. The takeovers now happen in a much more distributed way (about 4 times 9k) : fd_takeover: 1420081 [ 359562 359453 346586 354480 ] fd_takeover: 1457044 [ 368779 368429 355990 363846 ] There is no need to backport this, as this happened along a few patches that were merged during 2.2 development.
2020-06-29 08:43:16 -04:00
if ((i = ((i + 1 == global.nbthread) ? 0 : i + 1)) == tid)
break;
BUG/MEDIUM: connections: force connections cleanup on server changes I've been trying to understand a change of behaviour between v2.2dev5 and v2.2dev6. Indeed our probe is regularly testing to add and remove servers on a given backend such as: # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 263 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 0.0.0.0 0 1 256 256 0 15 3 0 14 0 0 0 - 0 - -> curl on the corresponding frontend: reply from server:31255 # echo "set server be_foo/srv1 addr 10.236.139.34 port 31257" | sudo socat stdio /var/lib/haproxy/stats IP changed from '0.0.0.0' to '10.236.139.34', port changed from '0' to '31257' by 'stats socket command' # echo "set server be_foo/srv1 weight 256" | sudo socat stdio /var/lib/haproxy/stats # echo "set server be_foo/srv1 check-port 8500" | sudo socat stdio /var/lib/haproxy/stats health check port updated. # echo "set server be_foo/srv1 state ready" | sudo socat stdio /var/lib/haproxy/stats # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 105 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 10.236.139.34 2 0 256 256 2319 15 3 2 6 0 0 0 - 31257 - -> curl on the corresponding frontend: reply for server:31257 (notice the difference of weight) # echo "set server be_foo/srv1 state maint" | sudo socat stdio /var/lib/haproxy/stats # echo "set server be_foo/srv1 addr 0.0.0.0 port 0" | sudo socat stdio /var/lib/haproxy/stats IP changed from '10.236.139.34' to '0.0.0.0', port changed from '31257' to '0' by 'stats socket command' # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 263 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 0.0.0.0 0 1 256 256 0 15 3 0 14 0 0 0 - 0 - -> curl on the corresponding frontend: reply from server:31255 # echo "set server be_foo/srv1 addr 10.236.139.34 port 31256" | sudo socat stdio /var/lib/haproxy/stats IP changed from '0.0.0.0' to '10.236.139.34', port changed from '0' to '31256' by 'stats socket command' # echo "set server be_foo/srv1 weight 256" | sudo socat stdio /var/lib/haproxy/stats # echo "set server be_foo/srv1 check-port 8500" | sudo socat stdio /var/lib/haproxy/stats health check port updated. # echo "set server be_foo/srv1 state ready" | sudo socat stdio /var/lib/haproxy/stats # echo "show servers state be_foo" | sudo socat stdio /var/lib/haproxy/stats 113 be_foo 1 srv0 10.236.139.34 2 0 1 1 105 15 3 4 6 0 0 0 - 31255 - 113 be_foo 2 srv1 10.236.139.34 2 0 256 256 2319 15 3 2 6 0 0 0 - 31256 - -> curl on the corresponding frontend: reply from server:31257 (!) Here we indeed would expect to get an anver from server:31256. The issue is highly linked to the usage of `pool-purge-delay`, with a value which is higher than the duration of the test, 10s in our case. a git bisect between dev5 and dev6 seems to show commit 079cb9af22da6 ("MEDIUM: connections: Revamp the way idle connections are killed") being the origin of this new behaviour. So if I understand the later correctly, it seems that it was more a matter of chance that we did not saw the issue earlier. My patch proposes to force clean idle connections in the two following cases: - we set a (still running) server to maintenance - we change the ip/port of a server This commit should be backported to 2.1, 2.0, and 1.9. Signed-off-by: William Dauchy <w.dauchy@criteo.com>
2020-05-02 15:52:36 -04:00
}
}
REORG: server: uninline the idle conns management functions The following functions are quite heavy and have no reason to be kept inlined: srv_release_conn, srv_lookup_conn, srv_lookup_conn_next, srv_add_to_idle_list They were moved to server.c. It's worth noting that they're a bit at the edge between server and connection and that maybe we could create an idle-conn file for these in the near future.
2021-10-06 12:30:04 -04:00
/* removes an idle conn after updating the server idle conns counters */
void srv_release_conn(struct server *srv, struct connection *conn)
{
MEDIUM: session: account on server idle conns attached to session This patch adds a new member <curr_sess_idle_conns> on the server. It serves as a counter of idle connections attached on a session instead of regular idle/safe trees. This is used only for private connections. The objective is to provide a method to detect if there is idle connections still referencing a server. This will be particularly useful to ensure that a server is removable. Currently, this is not yet necessary as idle connections are directly freed via "del server" handler under thread isolation. However, this procedure will be replaced by an asynchronous mechanism outside of thread isolation. Careful: connections attached to a session but not idle will not be accounted by this counter. These connections can still be detected via srv_has_streams() so "del server" will be safe. This counter is maintain during the whole lifetime of a private connection. This is mandatory to guarantee "del server" safety and is conform with other idle server counters. What this means it that decrement is performed only when the connection transitions from idle to in use, or just prior to its deletion. For the first case, this is covered by session_get_conn(). The second case is trickier. It cannot be done via session_unown_conn() as a private connection may still live a little longer after its removal from session, most notably when scheduled for idle purging. Thus, conn_free() has been adjusted to handle the final decrement. Now, conn_backend_deinit() is also called for private connections if CO_FL_SESS_IDLE flag is present. This results in a call to srv_release_conn() which is responsible to decrement server idle counters.
2025-08-08 09:56:47 -04:00
if (conn->flags & CO_FL_SESS_IDLE) {
_HA_ATOMIC_DEC(&srv->curr_sess_idle_conns);
conn->flags &= ~CO_FL_SESS_IDLE;
}
else if (conn->flags & CO_FL_LIST_MASK) {
REORG: server: uninline the idle conns management functions The following functions are quite heavy and have no reason to be kept inlined: srv_release_conn, srv_lookup_conn, srv_lookup_conn_next, srv_add_to_idle_list They were moved to server.c. It's worth noting that they're a bit at the edge between server and connection and that maybe we could create an idle-conn file for these in the near future.
2021-10-06 12:30:04 -04:00
/* The connection is currently in the server's idle list, so tell it
* there's one less connection available in that list.
*/
_HA_ATOMIC_DEC(&srv->curr_idle_conns);
_HA_ATOMIC_DEC(conn->flags & CO_FL_SAFE_LIST ? &srv->curr_safe_nb : &srv->curr_idle_nb);
_HA_ATOMIC_DEC(&srv->curr_idle_thr[tid]);
}
else {
/* The connection is not private and not in any server's idle
* list, so decrement the current number of used connections
*/
_HA_ATOMIC_DEC(&srv->curr_used_conns);
}
/* Remove the connection from any tree (safe, idle or available) */
MEDIUM: connection: reintegrate conn_hash_node into connection Previously the conn_hash_node was placed outside the connection due to the big size of the eb64_node that could have negatively impacted frontend connections. But having it outside also means that one extra allocation is needed for each backend connection, and that one memory indirection is needed for each lookup. With the compact trees, the tree node is smaller (16 bytes vs 40) so the overhead is much lower. By integrating it into the connection, We're also eliminating one pointer from the connection to the hash node and one pointer from the hash node to the connection (in addition to the extra object bookkeeping). This results in saving at least 24 bytes per total backend connection, and only inflates connections by 16 bytes (from 240 to 256), which is a reasonable compromise. Tests on a 64-core EPYC show a 2.4% increase in the request rate (from 2.08 to 2.13 Mrps).
2025-09-12 12:12:18 -04:00
if (ceb_intree(&conn->hash_node.node)) {
MINOR: connection: centralize init/deinit of backend elements A connection contains extra elements which are only used for the backend side. Regroup their allocation and deallocation in two new functions named conn_backend_init() and conn_backend_deinit(). No functional change is introduced with this commit. The new functions are reused in place of manual alloc/dealloc in conn_new() / conn_free(). This patch will be useful for reverse connect support with connection conversion from backend to frontend side and vice-versa.
2023-07-27 09:30:07 -04:00
HA_SPIN_LOCK(IDLE_CONNS_LOCK, &idle_conns[tid].idle_conns_lock);
Revert "BUG/MEDIUM: connections: permit to permanently remove an idle conn" The target patch fixes a rare race condition which happen when a MUX IO handler is working on a connection already moved into the purge list. In this case, the handler will incorrectly moved back the connection into the idle list. To fix this, conn_delete_from_tree() was extended to remove flags along with the connection from the idle list. This was performed when the connection is moved into the purge list. However, it introduces another issue related to the idle server connection accounting. Thus it is necessary to revert it prior to the incoming newer fix. This patch must be backported to every version where the original commit is.
2025-11-12 11:38:08 -05:00
conn_delete_from_tree(conn, tid);
conn->flags &= ~CO_FL_LIST_MASK;
MINOR: connection: centralize init/deinit of backend elements A connection contains extra elements which are only used for the backend side. Regroup their allocation and deallocation in two new functions named conn_backend_init() and conn_backend_deinit(). No functional change is introduced with this commit. The new functions are reused in place of manual alloc/dealloc in conn_new() / conn_free(). This patch will be useful for reverse connect support with connection conversion from backend to frontend side and vice-versa.
2023-07-27 09:30:07 -04:00
HA_SPIN_UNLOCK(IDLE_CONNS_LOCK, &idle_conns[tid].idle_conns_lock);
}
REORG: server: uninline the idle conns management functions The following functions are quite heavy and have no reason to be kept inlined: srv_release_conn, srv_lookup_conn, srv_lookup_conn_next, srv_add_to_idle_list They were moved to server.c. It's worth noting that they're a bit at the edge between server and connection and that maybe we could create an idle-conn file for these in the near future.
2021-10-06 12:30:04 -04:00
}
/* retrieve a connection from its <hash> in <tree>
* returns NULL if no connection found
*/
MEDIUM: connection: move idle connection trees to ceb64 Idle connection trees currently require a 56-byte conn_hash_node per connection, which can be reduced to 32 bytes by moving to ceb64. While ceb64 is theoretically slower, in practice here we're essentially dealing with trees that almost always contain a single key and many duplicates. In this case, ceb64 insert and lookup functions become faster than eb64 ones because all duplicates are a list accessed in O(1) while it's a subtree for eb64. In tests it is impossible to tell the difference between the two, so it's worth reducing the memory usage. This commit brings the following memory savings to conn_hash_node (one per backend connection), and to srv_per_thread (one per thread and per server): struct before after delta conn_hash_nodea 56 32 -24 srv_per_thread 96 72 -24 The delicate part is conn_delete_from_tree(), because we need to know the tree root the connection is attached to. But thanks to recent cleanups, it's now clear enough (i.e. idle/safe/avail vs session are easy to distinguish).
2025-09-12 09:28:33 -04:00
struct connection *srv_lookup_conn(struct ceb_root **tree, uint64_t hash)
REORG: server: uninline the idle conns management functions The following functions are quite heavy and have no reason to be kept inlined: srv_release_conn, srv_lookup_conn, srv_lookup_conn_next, srv_add_to_idle_list They were moved to server.c. It's worth noting that they're a bit at the edge between server and connection and that maybe we could create an idle-conn file for these in the near future.
2021-10-06 12:30:04 -04:00
{
MEDIUM: connection: reintegrate conn_hash_node into connection Previously the conn_hash_node was placed outside the connection due to the big size of the eb64_node that could have negatively impacted frontend connections. But having it outside also means that one extra allocation is needed for each backend connection, and that one memory indirection is needed for each lookup. With the compact trees, the tree node is smaller (16 bytes vs 40) so the overhead is much lower. By integrating it into the connection, We're also eliminating one pointer from the connection to the hash node and one pointer from the hash node to the connection (in addition to the extra object bookkeeping). This results in saving at least 24 bytes per total backend connection, and only inflates connections by 16 bytes (from 240 to 256), which is a reasonable compromise. Tests on a 64-core EPYC show a 2.4% increase in the request rate (from 2.08 to 2.13 Mrps).
2025-09-12 12:12:18 -04:00
return ceb64_item_lookup(tree, hash_node.node, hash_node.key, hash, struct connection);
REORG: server: uninline the idle conns management functions The following functions are quite heavy and have no reason to be kept inlined: srv_release_conn, srv_lookup_conn, srv_lookup_conn_next, srv_add_to_idle_list They were moved to server.c. It's worth noting that they're a bit at the edge between server and connection and that maybe we could create an idle-conn file for these in the near future.
2021-10-06 12:30:04 -04:00
}
/* retrieve the next connection sharing the same hash as <conn>
* returns NULL if no connection found
*/
MEDIUM: connection: move idle connection trees to ceb64 Idle connection trees currently require a 56-byte conn_hash_node per connection, which can be reduced to 32 bytes by moving to ceb64. While ceb64 is theoretically slower, in practice here we're essentially dealing with trees that almost always contain a single key and many duplicates. In this case, ceb64 insert and lookup functions become faster than eb64 ones because all duplicates are a list accessed in O(1) while it's a subtree for eb64. In tests it is impossible to tell the difference between the two, so it's worth reducing the memory usage. This commit brings the following memory savings to conn_hash_node (one per backend connection), and to srv_per_thread (one per thread and per server): struct before after delta conn_hash_nodea 56 32 -24 srv_per_thread 96 72 -24 The delicate part is conn_delete_from_tree(), because we need to know the tree root the connection is attached to. But thanks to recent cleanups, it's now clear enough (i.e. idle/safe/avail vs session are easy to distinguish).
2025-09-12 09:28:33 -04:00
struct connection *srv_lookup_conn_next(struct ceb_root **tree, struct connection *conn)
REORG: server: uninline the idle conns management functions The following functions are quite heavy and have no reason to be kept inlined: srv_release_conn, srv_lookup_conn, srv_lookup_conn_next, srv_add_to_idle_list They were moved to server.c. It's worth noting that they're a bit at the edge between server and connection and that maybe we could create an idle-conn file for these in the near future.
2021-10-06 12:30:04 -04:00
{
MEDIUM: connection: reintegrate conn_hash_node into connection Previously the conn_hash_node was placed outside the connection due to the big size of the eb64_node that could have negatively impacted frontend connections. But having it outside also means that one extra allocation is needed for each backend connection, and that one memory indirection is needed for each lookup. With the compact trees, the tree node is smaller (16 bytes vs 40) so the overhead is much lower. By integrating it into the connection, We're also eliminating one pointer from the connection to the hash node and one pointer from the hash node to the connection (in addition to the extra object bookkeeping). This results in saving at least 24 bytes per total backend connection, and only inflates connections by 16 bytes (from 240 to 256), which is a reasonable compromise. Tests on a 64-core EPYC show a 2.4% increase in the request rate (from 2.08 to 2.13 Mrps).
2025-09-12 12:12:18 -04:00
return ceb64_item_next_dup(tree, hash_node.node, hash_node.key, conn);
REORG: server: uninline the idle conns management functions The following functions are quite heavy and have no reason to be kept inlined: srv_release_conn, srv_lookup_conn, srv_lookup_conn_next, srv_add_to_idle_list They were moved to server.c. It's worth noting that they're a bit at the edge between server and connection and that maybe we could create an idle-conn file for these in the near future.
2021-10-06 12:30:04 -04:00
}
MINOR: server: move idle tree insert in a dedicated function Define a new function _srv_add_idle(). This is a simple wrapper to insert a connection in the server idle tree. This is reserved for simple usage and require to idle_conns lock. In most cases, srv_add_to_idle_list() should be used. This patch does not have any functional change. However, it will help with the next patch as idle connection will be always inserted in a list as secondary storage along with idle/safe trees.
2023-08-25 09:48:39 -04:00
/* Add <conn> in <srv> idle trees. Set <is_safe> if connection is deemed safe
* for reuse.
*
* This function is a simple wrapper for tree insert. It should only be used
* for internal usage or when removing briefly the connection to avoid takeover
* on it before reinserting it with this function. In other context, prefer to
* use the full feature srv_add_to_idle_list().
*
* Must be called with idle_conns_lock.
*/
MINOR: server: move the lock inside srv_add_idle() Almost all callers of _srv_add_idle() lock the list then call the function. It's not the most efficient and it requires some care from the caller to take care of that lock. Let's change this a little bit by having srv_add_idle() that takes the lock and calls _srv_add_idle() that is now inlined. This way callers don't have to handle the lock themselves anymore, and the lock is only taken around the sensitive parts, not the function call+return. Interestingly, perf tests show a small perf increase from 2.28-2.32M RPS to 2.32-2.37M RPS on a 128-thread system.
2025-11-06 07:12:04 -05:00
static inline void _srv_add_idle(struct server *srv, struct connection *conn, int is_safe)
MINOR: server: move idle tree insert in a dedicated function Define a new function _srv_add_idle(). This is a simple wrapper to insert a connection in the server idle tree. This is reserved for simple usage and require to idle_conns lock. In most cases, srv_add_to_idle_list() should be used. This patch does not have any functional change. However, it will help with the next patch as idle connection will be always inserted in a list as secondary storage along with idle/safe trees.
2023-08-25 09:48:39 -04:00
{
MEDIUM: connection: move idle connection trees to ceb64 Idle connection trees currently require a 56-byte conn_hash_node per connection, which can be reduced to 32 bytes by moving to ceb64. While ceb64 is theoretically slower, in practice here we're essentially dealing with trees that almost always contain a single key and many duplicates. In this case, ceb64 insert and lookup functions become faster than eb64 ones because all duplicates are a list accessed in O(1) while it's a subtree for eb64. In tests it is impossible to tell the difference between the two, so it's worth reducing the memory usage. This commit brings the following memory savings to conn_hash_node (one per backend connection), and to srv_per_thread (one per thread and per server): struct before after delta conn_hash_nodea 56 32 -24 srv_per_thread 96 72 -24 The delicate part is conn_delete_from_tree(), because we need to know the tree root the connection is attached to. But thanks to recent cleanups, it's now clear enough (i.e. idle/safe/avail vs session are easy to distinguish).
2025-09-12 09:28:33 -04:00
struct ceb_root **tree = is_safe ? &srv->per_thr[tid].safe_conns :
MINOR: server: move idle tree insert in a dedicated function Define a new function _srv_add_idle(). This is a simple wrapper to insert a connection in the server idle tree. This is reserved for simple usage and require to idle_conns lock. In most cases, srv_add_to_idle_list() should be used. This patch does not have any functional change. However, it will help with the next patch as idle connection will be always inserted in a list as secondary storage along with idle/safe trees.
2023-08-25 09:48:39 -04:00
&srv->per_thr[tid].idle_conns;
MAJOR: connection: purge idle conn by last usage Backend idle connections are purged on a recurring occurence during the process lifetime. An estimated number of needed connections is calculated and the excess is removed periodically. Before this patch, purge was done directly using the idle then the safe connection tree of a server instance. This has a major drawback to take no account of a specific ordre and it may removed functional connections while leaving ones which will fail on the next reuse. The problem can be worse when using criteria to differentiate idle connections such as the SSL SNI. In this case, purge may remove connections with a high rate of reusing while leaving connections with criteria never matched once, thus reducing drastically the reuse rate. To improve this, introduce an alternative storage for idle connection used in parallel of the idle/safe trees. Now, each connection inserted in one of this tree is also inserted in the new list at `srv_per_thread.idle_conn_list`. This guarantees that recently used connection is present at the end of the list. During the purge, use this list instead of idle/safe trees. Remove first connection in front of the list which were not reused recently. This will ensure that connection that are frequently reused are not purged and should increase the reuse rate, particularily if distinct idle connection criterias are in used.
2023-08-21 12:32:29 -04:00
/* first insert in idle or safe tree. */
MEDIUM: connection: reintegrate conn_hash_node into connection Previously the conn_hash_node was placed outside the connection due to the big size of the eb64_node that could have negatively impacted frontend connections. But having it outside also means that one extra allocation is needed for each backend connection, and that one memory indirection is needed for each lookup. With the compact trees, the tree node is smaller (16 bytes vs 40) so the overhead is much lower. By integrating it into the connection, We're also eliminating one pointer from the connection to the hash node and one pointer from the hash node to the connection (in addition to the extra object bookkeeping). This results in saving at least 24 bytes per total backend connection, and only inflates connections by 16 bytes (from 240 to 256), which is a reasonable compromise. Tests on a 64-core EPYC show a 2.4% increase in the request rate (from 2.08 to 2.13 Mrps).
2025-09-12 12:12:18 -04:00
ceb64_item_insert(tree, hash_node.node, hash_node.key, conn);
MAJOR: connection: purge idle conn by last usage Backend idle connections are purged on a recurring occurence during the process lifetime. An estimated number of needed connections is calculated and the excess is removed periodically. Before this patch, purge was done directly using the idle then the safe connection tree of a server instance. This has a major drawback to take no account of a specific ordre and it may removed functional connections while leaving ones which will fail on the next reuse. The problem can be worse when using criteria to differentiate idle connections such as the SSL SNI. In this case, purge may remove connections with a high rate of reusing while leaving connections with criteria never matched once, thus reducing drastically the reuse rate. To improve this, introduce an alternative storage for idle connection used in parallel of the idle/safe trees. Now, each connection inserted in one of this tree is also inserted in the new list at `srv_per_thread.idle_conn_list`. This guarantees that recently used connection is present at the end of the list. During the purge, use this list instead of idle/safe trees. Remove first connection in front of the list which were not reused recently. This will ensure that connection that are frequently reused are not purged and should increase the reuse rate, particularily if distinct idle connection criterias are in used.
2023-08-21 12:32:29 -04:00
DEBUG: servers: add a few checks for stress-testing idle conns The latest idle conns fix 9481cef948 ("BUG/MEDIUM: connection: do not reinsert a purgeable conn in idle list") addresses a very hard-to-hit case which manifests itself with an attempt to reuse a connection fails because conn->mux is NULL: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000655410b8642c in conn_backend_get (reuse_mode=4, srv=srv@entry=0x6554378a7140, sess=sess@entry=0x7cfe140948a0, is_safe=is_safe@entry=0, hash=hash@entry=910818338996668161) at src/backend.c:1390 1390 if (conn->mux->takeover && conn->mux->takeover(conn, i, 0) == 0) { However the condition that leads to this situation can be detected earlier, by the presence of the connection in the toremove_list, whose race window is much larger and easier to detect. This patch adds a few BUG_ON_STRESS() at selected places that an detect this condition. When built with -DDEBUG_STRESS and run under stress with two distinct processes communicating over H2 over SSL, under a stress of 400-500k req/s, the front process usually crashes in the first 10-30s triggering in _srv_add_idle() if the fix above is reverted (and it does not crash with the fix). This is mainly included to serve as an illustration of how to instrument the code for seamless stress testing.
2025-11-14 10:48:16 -05:00
BUG_ON_STRESS(!mt_list_isempty(&conn->toremove_list));
MAJOR: connection: purge idle conn by last usage Backend idle connections are purged on a recurring occurence during the process lifetime. An estimated number of needed connections is calculated and the excess is removed periodically. Before this patch, purge was done directly using the idle then the safe connection tree of a server instance. This has a major drawback to take no account of a specific ordre and it may removed functional connections while leaving ones which will fail on the next reuse. The problem can be worse when using criteria to differentiate idle connections such as the SSL SNI. In this case, purge may remove connections with a high rate of reusing while leaving connections with criteria never matched once, thus reducing drastically the reuse rate. To improve this, introduce an alternative storage for idle connection used in parallel of the idle/safe trees. Now, each connection inserted in one of this tree is also inserted in the new list at `srv_per_thread.idle_conn_list`. This guarantees that recently used connection is present at the end of the list. During the purge, use this list instead of idle/safe trees. Remove first connection in front of the list which were not reused recently. This will ensure that connection that are frequently reused are not purged and should increase the reuse rate, particularily if distinct idle connection criterias are in used.
2023-08-21 12:32:29 -04:00
/* insert in list sorted by connection usage. */
LIST_APPEND(&srv->per_thr[tid].idle_conn_list, &conn->idle_list);
MINOR: server: move idle tree insert in a dedicated function Define a new function _srv_add_idle(). This is a simple wrapper to insert a connection in the server idle tree. This is reserved for simple usage and require to idle_conns lock. In most cases, srv_add_to_idle_list() should be used. This patch does not have any functional change. However, it will help with the next patch as idle connection will be always inserted in a list as secondary storage along with idle/safe trees.
2023-08-25 09:48:39 -04:00
}
MINOR: server: move the lock inside srv_add_idle() Almost all callers of _srv_add_idle() lock the list then call the function. It's not the most efficient and it requires some care from the caller to take care of that lock. Let's change this a little bit by having srv_add_idle() that takes the lock and calls _srv_add_idle() that is now inlined. This way callers don't have to handle the lock themselves anymore, and the lock is only taken around the sensitive parts, not the function call+return. Interestingly, perf tests show a small perf increase from 2.28-2.32M RPS to 2.32-2.37M RPS on a 128-thread system.
2025-11-06 07:12:04 -05:00
/* Add <conn> in <srv> idle trees. Set <is_safe> if connection is deemed safe
* for reuse.
*
* This function is a simple wrapper for tree insert. It should only be used
* for internal usage or when removing briefly the connection to avoid takeover
* on it before reinserting it with this function. In other context, prefer to
* use the full feature srv_add_to_idle_list(). This function takes the idle
* conns lock for the current thread (thus the owner must not already have it).
*/
void srv_add_idle(struct server *srv, struct connection *conn, int is_safe)
{
HA_SPIN_LOCK(IDLE_CONNS_LOCK, &idle_conns[tid].idle_conns_lock);
_srv_add_idle(srv, conn, is_safe);
HA_SPIN_UNLOCK(IDLE_CONNS_LOCK, &idle_conns[tid].idle_conns_lock);
}
REORG: server: uninline the idle conns management functions The following functions are quite heavy and have no reason to be kept inlined: srv_release_conn, srv_lookup_conn, srv_lookup_conn_next, srv_add_to_idle_list They were moved to server.c. It's worth noting that they're a bit at the edge between server and connection and that maybe we could create an idle-conn file for these in the near future.
2021-10-06 12:30:04 -04:00
/* This adds an idle connection to the server's list if the connection is
* reusable, not held by any owner anymore, but still has available streams.
*/
int srv_add_to_idle_list(struct server *srv, struct connection *conn, int is_safe)
{
/* we try to keep the connection in the server's idle list
* if we don't have too many FD in use, and if the number of
* idle+current conns is lower than what was observed before
* last purge, or if we already don't have idle conns for the
* current thread and we don't exceed last count by global.nbthread.
*/
if (!(conn->flags & CO_FL_PRIVATE) &&
srv && srv->pool_purge_delay > 0 &&
MEDIUM: server: close new idle conns if server in maintenance Currently, when a server is set on maintenance mode, its idle connection are scheduled for purge. However, this does not prevent currently used connection to become idle later on, even if the server is still off. Change this behavior : an idle connection is now rejected by the server if it is in maintenance. This is implemented with a new condition in srv_add_to_idle_list() which returns an error value. In this case, muxes stream detach callback will immediately free the connection. A similar change is also performed in each MUX and SSL I/O handlers and in conn_notify_mux(). An idle connection is not reinserted in its idle list if server is in maintenance, but instead it is immediately freed.
2025-08-08 11:17:26 -04:00
!(srv->cur_admin & SRV_ADMF_MAINT) &&
REORG: server: uninline the idle conns management functions The following functions are quite heavy and have no reason to be kept inlined: srv_release_conn, srv_lookup_conn, srv_lookup_conn_next, srv_add_to_idle_list They were moved to server.c. It's worth noting that they're a bit at the edge between server and connection and that maybe we could create an idle-conn file for these in the near future.
2021-10-06 12:30:04 -04:00
((srv->proxy->options & PR_O_REUSE_MASK) != PR_O_REUSE_NEVR) &&
ha_used_fds < global.tune.pool_high_count &&
(srv->max_idle_conns == -1 || srv->max_idle_conns > srv->curr_idle_conns) &&
MEDIUM: connection: move idle connection trees to ceb64 Idle connection trees currently require a 56-byte conn_hash_node per connection, which can be reduced to 32 bytes by moving to ceb64. While ceb64 is theoretically slower, in practice here we're essentially dealing with trees that almost always contain a single key and many duplicates. In this case, ceb64 insert and lookup functions become faster than eb64 ones because all duplicates are a list accessed in O(1) while it's a subtree for eb64. In tests it is impossible to tell the difference between the two, so it's worth reducing the memory usage. This commit brings the following memory savings to conn_hash_node (one per backend connection), and to srv_per_thread (one per thread and per server): struct before after delta conn_hash_nodea 56 32 -24 srv_per_thread 96 72 -24 The delicate part is conn_delete_from_tree(), because we need to know the tree root the connection is attached to. But thanks to recent cleanups, it's now clear enough (i.e. idle/safe/avail vs session are easy to distinguish).
2025-09-12 09:28:33 -04:00
((ceb_isempty(&srv->per_thr[tid].safe_conns) &&
(is_safe || ceb_isempty(&srv->per_thr[tid].idle_conns))) ||
REORG: server: uninline the idle conns management functions The following functions are quite heavy and have no reason to be kept inlined: srv_release_conn, srv_lookup_conn, srv_lookup_conn_next, srv_add_to_idle_list They were moved to server.c. It's worth noting that they're a bit at the edge between server and connection and that maybe we could create an idle-conn file for these in the near future.
2021-10-06 12:30:04 -04:00
(ha_used_fds < global.tune.pool_low_count &&
(srv->curr_used_conns + srv->curr_idle_conns <=
MINOR: server: force add to idle on reverse A backend connection is inserted in server idle list via srv_add_to_idle_list(). This function has several conditions which may cause the connection to be rejected instead. One of this condition is based on the current estimate count of needed connections for the server. If the count of idle connections stored has already reached this estimation, the new connection is rejected. This is in opposition with the purpose of reverse HTTP. On active reverse, haproxy can instantiate several connections to properly serve the future traffic. However, the opposite passive haproxy will have only a low estimate of needed connection and will reject most of them. To fix this, simply check CO_FL_REVERSED connection flag on srv_add_to_idle_list(). If set, the connection is inserted without checking for estimate count. Note that all other conditions are not impacted, so it's still possible to reject a connection, for example if process FD limit is reached. This commit relies on recent patch which change CO_FL_REVERSED flag for connection after passive reverse.
2023-11-16 11:16:00 -05:00
MAX(srv->curr_used_conns, srv->est_need_conns) + srv->low_idle_conns ||
(conn->flags & CO_FL_REVERSED)))) &&
REORG: server: uninline the idle conns management functions The following functions are quite heavy and have no reason to be kept inlined: srv_release_conn, srv_lookup_conn, srv_lookup_conn_next, srv_add_to_idle_list They were moved to server.c. It's worth noting that they're a bit at the edge between server and connection and that maybe we could create an idle-conn file for these in the near future.
2021-10-06 12:30:04 -04:00
!conn->mux->used_streams(conn) && conn->mux->avail_streams(conn)) {
int retadd;
retadd = _HA_ATOMIC_ADD_FETCH(&srv->curr_idle_conns, 1);
if (retadd > srv->max_idle_conns) {
_HA_ATOMIC_DEC(&srv->curr_idle_conns);
return 0;
}
_HA_ATOMIC_DEC(&srv->curr_used_conns);
HA_SPIN_LOCK(IDLE_CONNS_LOCK, &idle_conns[tid].idle_conns_lock);
Revert "BUG/MEDIUM: connections: permit to permanently remove an idle conn" The target patch fixes a rare race condition which happen when a MUX IO handler is working on a connection already moved into the purge list. In this case, the handler will incorrectly moved back the connection into the idle list. To fix this, conn_delete_from_tree() was extended to remove flags along with the connection from the idle list. This was performed when the connection is moved into the purge list. However, it introduces another issue related to the idle server connection accounting. Thus it is necessary to revert it prior to the incoming newer fix. This patch must be backported to every version where the original commit is.
2025-11-12 11:38:08 -05:00
conn_delete_from_tree(conn, tid);
REORG: server: uninline the idle conns management functions The following functions are quite heavy and have no reason to be kept inlined: srv_release_conn, srv_lookup_conn, srv_lookup_conn_next, srv_add_to_idle_list They were moved to server.c. It's worth noting that they're a bit at the edge between server and connection and that maybe we could create an idle-conn file for these in the near future.
2021-10-06 12:30:04 -04:00
if (is_safe) {
conn->flags = (conn->flags & ~CO_FL_LIST_MASK) | CO_FL_SAFE_LIST;
MINOR: server: move idle tree insert in a dedicated function Define a new function _srv_add_idle(). This is a simple wrapper to insert a connection in the server idle tree. This is reserved for simple usage and require to idle_conns lock. In most cases, srv_add_to_idle_list() should be used. This patch does not have any functional change. However, it will help with the next patch as idle connection will be always inserted in a list as secondary storage along with idle/safe trees.
2023-08-25 09:48:39 -04:00
_srv_add_idle(srv, conn, 1);
REORG: server: uninline the idle conns management functions The following functions are quite heavy and have no reason to be kept inlined: srv_release_conn, srv_lookup_conn, srv_lookup_conn_next, srv_add_to_idle_list They were moved to server.c. It's worth noting that they're a bit at the edge between server and connection and that maybe we could create an idle-conn file for these in the near future.
2021-10-06 12:30:04 -04:00
_HA_ATOMIC_INC(&srv->curr_safe_nb);
} else {
conn->flags = (conn->flags & ~CO_FL_LIST_MASK) | CO_FL_IDLE_LIST;
MINOR: server: move idle tree insert in a dedicated function Define a new function _srv_add_idle(). This is a simple wrapper to insert a connection in the server idle tree. This is reserved for simple usage and require to idle_conns lock. In most cases, srv_add_to_idle_list() should be used. This patch does not have any functional change. However, it will help with the next patch as idle connection will be always inserted in a list as secondary storage along with idle/safe trees.
2023-08-25 09:48:39 -04:00
_srv_add_idle(srv, conn, 0);
REORG: server: uninline the idle conns management functions The following functions are quite heavy and have no reason to be kept inlined: srv_release_conn, srv_lookup_conn, srv_lookup_conn_next, srv_add_to_idle_list They were moved to server.c. It's worth noting that they're a bit at the edge between server and connection and that maybe we could create an idle-conn file for these in the near future.
2021-10-06 12:30:04 -04:00
_HA_ATOMIC_INC(&srv->curr_idle_nb);
}
DEBUG: servers: add a few checks for stress-testing idle conns The latest idle conns fix 9481cef948 ("BUG/MEDIUM: connection: do not reinsert a purgeable conn in idle list") addresses a very hard-to-hit case which manifests itself with an attempt to reuse a connection fails because conn->mux is NULL: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000655410b8642c in conn_backend_get (reuse_mode=4, srv=srv@entry=0x6554378a7140, sess=sess@entry=0x7cfe140948a0, is_safe=is_safe@entry=0, hash=hash@entry=910818338996668161) at src/backend.c:1390 1390 if (conn->mux->takeover && conn->mux->takeover(conn, i, 0) == 0) { However the condition that leads to this situation can be detected earlier, by the presence of the connection in the toremove_list, whose race window is much larger and easier to detect. This patch adds a few BUG_ON_STRESS() at selected places that an detect this condition. When built with -DDEBUG_STRESS and run under stress with two distinct processes communicating over H2 over SSL, under a stress of 400-500k req/s, the front process usually crashes in the first 10-30s triggering in _srv_add_idle() if the fix above is reverted (and it does not crash with the fix). This is mainly included to serve as an illustration of how to instrument the code for seamless stress testing.
2025-11-14 10:48:16 -05:00
BUG_ON_STRESS(!mt_list_isempty(&conn->toremove_list));
REORG: server: uninline the idle conns management functions The following functions are quite heavy and have no reason to be kept inlined: srv_release_conn, srv_lookup_conn, srv_lookup_conn_next, srv_add_to_idle_list They were moved to server.c. It's worth noting that they're a bit at the edge between server and connection and that maybe we could create an idle-conn file for these in the near future.
2021-10-06 12:30:04 -04:00
HA_SPIN_UNLOCK(IDLE_CONNS_LOCK, &idle_conns[tid].idle_conns_lock);
_HA_ATOMIC_INC(&srv->curr_idle_thr[tid]);
OPTIM: server: get rid of the last use of _ha_barrier_full() The code in srv_add_to_idle_list() has its roots in 2.0 with commit 9ea5d361ae ("MEDIUM: servers: Reorganize the way idle connections are cleaned."). At this era we didn't yet have the current set of atomic load/store operations and we used to perform loads using volatile casts after a barrier. It turns out that this function has kept this schema over the years, resulting in a big mfence stalling all the pipeline in the function: | static __inline void | __ha_barrier_full(void) | { | __asm __volatile("mfence" ::: "memory"); 27.08 | mfence | if ((volatile void *)srv->idle_node.node.leaf_p == NULL) { 0.84 | cmpq $0x0,0x158(%r15) 0.74 | je 35f | return 1; Switching these for a pair of atomic loads got rid of this and brought 0.5 to 3% extra performance depending on the tests due to variations elsewhere, but it has never been below 0.5%. Note that the second load doesn't need to be atomic since it's protected by the lock, but it's cleaner from an API and code review perspective. That's also why it's relaxed. This was the last user of _ha_barrier_full(), let's try not to reintroduce it now!
2026-01-28 10:59:40 -05:00
if (HA_ATOMIC_LOAD(&srv->idle_node.node.leaf_p) == NULL) {
REORG: server: uninline the idle conns management functions The following functions are quite heavy and have no reason to be kept inlined: srv_release_conn, srv_lookup_conn, srv_lookup_conn_next, srv_add_to_idle_list They were moved to server.c. It's worth noting that they're a bit at the edge between server and connection and that maybe we could create an idle-conn file for these in the near future.
2021-10-06 12:30:04 -04:00
HA_SPIN_LOCK(OTHER_LOCK, &idle_conn_srv_lock);
OPTIM: server: get rid of the last use of _ha_barrier_full() The code in srv_add_to_idle_list() has its roots in 2.0 with commit 9ea5d361ae ("MEDIUM: servers: Reorganize the way idle connections are cleaned."). At this era we didn't yet have the current set of atomic load/store operations and we used to perform loads using volatile casts after a barrier. It turns out that this function has kept this schema over the years, resulting in a big mfence stalling all the pipeline in the function: | static __inline void | __ha_barrier_full(void) | { | __asm __volatile("mfence" ::: "memory"); 27.08 | mfence | if ((volatile void *)srv->idle_node.node.leaf_p == NULL) { 0.84 | cmpq $0x0,0x158(%r15) 0.74 | je 35f | return 1; Switching these for a pair of atomic loads got rid of this and brought 0.5 to 3% extra performance depending on the tests due to variations elsewhere, but it has never been below 0.5%. Note that the second load doesn't need to be atomic since it's protected by the lock, but it's cleaner from an API and code review perspective. That's also why it's relaxed. This was the last user of _ha_barrier_full(), let's try not to reintroduce it now!
2026-01-28 10:59:40 -05:00
if (_HA_ATOMIC_LOAD(&srv->idle_node.node.leaf_p) == NULL) {
REORG: server: uninline the idle conns management functions The following functions are quite heavy and have no reason to be kept inlined: srv_release_conn, srv_lookup_conn, srv_lookup_conn_next, srv_add_to_idle_list They were moved to server.c. It's worth noting that they're a bit at the edge between server and connection and that maybe we could create an idle-conn file for these in the near future.
2021-10-06 12:30:04 -04:00
srv->idle_node.key = tick_add(srv->pool_purge_delay,
now_ms);
eb32_insert(&idle_conn_srv, &srv->idle_node);
if (!task_in_wq(idle_conn_task) && !
task_in_rq(idle_conn_task)) {
task_schedule(idle_conn_task,
srv->idle_node.key);
}
DEBUG: servers: add a few checks for stress-testing idle conns The latest idle conns fix 9481cef948 ("BUG/MEDIUM: connection: do not reinsert a purgeable conn in idle list") addresses a very hard-to-hit case which manifests itself with an attempt to reuse a connection fails because conn->mux is NULL: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000655410b8642c in conn_backend_get (reuse_mode=4, srv=srv@entry=0x6554378a7140, sess=sess@entry=0x7cfe140948a0, is_safe=is_safe@entry=0, hash=hash@entry=910818338996668161) at src/backend.c:1390 1390 if (conn->mux->takeover && conn->mux->takeover(conn, i, 0) == 0) { However the condition that leads to this situation can be detected earlier, by the presence of the connection in the toremove_list, whose race window is much larger and easier to detect. This patch adds a few BUG_ON_STRESS() at selected places that an detect this condition. When built with -DDEBUG_STRESS and run under stress with two distinct processes communicating over H2 over SSL, under a stress of 400-500k req/s, the front process usually crashes in the first 10-30s triggering in _srv_add_idle() if the fix above is reverted (and it does not crash with the fix). This is mainly included to serve as an illustration of how to instrument the code for seamless stress testing.
2025-11-14 10:48:16 -05:00
BUG_ON_STRESS(!mt_list_isempty(&conn->toremove_list));
REORG: server: uninline the idle conns management functions The following functions are quite heavy and have no reason to be kept inlined: srv_release_conn, srv_lookup_conn, srv_lookup_conn_next, srv_add_to_idle_list They were moved to server.c. It's worth noting that they're a bit at the edge between server and connection and that maybe we could create an idle-conn file for these in the near future.
2021-10-06 12:30:04 -04:00
}
HA_SPIN_UNLOCK(OTHER_LOCK, &idle_conn_srv_lock);
}
return 1;
}
return 0;
}
MINOR: backend: refactor insertion in avail conns tree Define a new function srv_add_to_avail_list(). This function is used to centralize connection insertion in available tree. It reuses a BUG_ON() statement to ensure the connection is not present in the idle list.
2023-10-25 04:10:14 -04:00
/* Insert <conn> connection in <srv> server available list. This is reserved
* for backend connection currently in used with usable streams left.
*/
void srv_add_to_avail_list(struct server *srv, struct connection *conn)
{
/* connection cannot be in idle list if used as an avail idle conn. */
BUG_ON(LIST_INLIST(&conn->idle_list));
DEBUG: servers: add a few checks for stress-testing idle conns The latest idle conns fix 9481cef948 ("BUG/MEDIUM: connection: do not reinsert a purgeable conn in idle list") addresses a very hard-to-hit case which manifests itself with an attempt to reuse a connection fails because conn->mux is NULL: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000655410b8642c in conn_backend_get (reuse_mode=4, srv=srv@entry=0x6554378a7140, sess=sess@entry=0x7cfe140948a0, is_safe=is_safe@entry=0, hash=hash@entry=910818338996668161) at src/backend.c:1390 1390 if (conn->mux->takeover && conn->mux->takeover(conn, i, 0) == 0) { However the condition that leads to this situation can be detected earlier, by the presence of the connection in the toremove_list, whose race window is much larger and easier to detect. This patch adds a few BUG_ON_STRESS() at selected places that an detect this condition. When built with -DDEBUG_STRESS and run under stress with two distinct processes communicating over H2 over SSL, under a stress of 400-500k req/s, the front process usually crashes in the first 10-30s triggering in _srv_add_idle() if the fix above is reverted (and it does not crash with the fix). This is mainly included to serve as an illustration of how to instrument the code for seamless stress testing.
2025-11-14 10:48:16 -05:00
BUG_ON_STRESS(!mt_list_isempty(&conn->toremove_list));
MEDIUM: connection: reintegrate conn_hash_node into connection Previously the conn_hash_node was placed outside the connection due to the big size of the eb64_node that could have negatively impacted frontend connections. But having it outside also means that one extra allocation is needed for each backend connection, and that one memory indirection is needed for each lookup. With the compact trees, the tree node is smaller (16 bytes vs 40) so the overhead is much lower. By integrating it into the connection, We're also eliminating one pointer from the connection to the hash node and one pointer from the hash node to the connection (in addition to the extra object bookkeeping). This results in saving at least 24 bytes per total backend connection, and only inflates connections by 16 bytes (from 240 to 256), which is a reasonable compromise. Tests on a 64-core EPYC show a 2.4% increase in the request rate (from 2.08 to 2.13 Mrps).
2025-09-12 12:12:18 -04:00
ceb64_item_insert(&srv->per_thr[tid].avail_conns, hash_node.node, hash_node.key, conn);
MINOR: backend: refactor insertion in avail conns tree Define a new function srv_add_to_avail_list(). This function is used to centralize connection insertion in available tree. It reuses a BUG_ON() statement to ensure the connection is not present in the idle list.
2023-10-25 04:10:14 -04:00
}
MEDIUM: task: extend the state field to 32 bits It's been too short for quite a while now and is now full. It's still time to extend it to 32-bits since we have room for this without wasting any space, so we now gained 16 new bits for future flags. The values were not reassigned just in case there would be a few hidden u16 or short somewhere in which these flags are placed (as it used to be the case with stream->pending_events). The patch is tagged MEDIUM because this required to update the task's process() prototype to use an int instead of a short, that's quite a bunch of places.
2021-03-02 10:09:26 -05:00
struct task *srv_cleanup_idle_conns(struct task *task, void *context, unsigned int state)
MEDIUM: servers: Reorganize the way idle connections are cleaned. Instead of having one task per thread and per server that does clean the idling connections, have only one global task for every servers. That tasks parses all the servers that currently have idling connections, and remove half of them, to put them in a per-thread list of connections to kill. For each thread that does have connections to kill, wake a task to do so, so that the cleaning will be done in the context of said thread.
2019-02-14 12:29:09 -05:00
{
struct server *srv;
struct eb32_node *eb;
int i;
unsigned int next_wakeup;
BUG/MEDIUM: server: make it possible to kill last idle connections In issue #933, @jaroslawr provided a report indicating that when using many threads and many servers, it's very difficult to terminate the last idle connections on each server. The issue has two causes in fact. The first one is that during the calculation of the estimate of needed connections, we round the computation up while in previous round it was already rounded up, so we end up adding 1 to 1 which once divided by 2 remains 1. The second issue is that servers are not woken up anymore for purging their connections if they don't have activity. The only reason that was there to wake them up again was in case insufficient connections were purged. And even then the purge task itself was not woken up. But that is not enough for getting rid of the long tail of old connections nor updating est_need_conns. This patch makes sure to properly wake up as long as at least one idle connection remains, and not to round up the needed connections anymore. Prior to this patch, a test involving many connections which suddenly stopped would keep many idle connections, now they're effectively halved every pool-purge-delay. This needs to be backported to 2.2.
2020-11-05 03:12:20 -05:00
next_wakeup = TICK_ETERNITY;
MEDIUM: servers: Reorganize the way idle connections are cleaned. Instead of having one task per thread and per server that does clean the idling connections, have only one global task for every servers. That tasks parses all the servers that currently have idling connections, and remove half of them, to put them in a per-thread list of connections to kill. For each thread that does have connections to kill, wake a task to do so, so that the cleaning will be done in the context of said thread.
2019-02-14 12:29:09 -05:00
HA_SPIN_LOCK(OTHER_LOCK, &idle_conn_srv_lock);
while (1) {
MEDIUM: connections: Revamp the way idle connections are killed The original algorithm always killed half the idle connections. This doesn't take into account the way the load can change. Instead, we now kill half of the exceeding connections (exceeding connection being the number of used + idle connections past the last maximum used connections reached). That way if we reach a peak, we will kill much less, and it'll slowly go back down when there's less usage.
2020-03-29 18:23:57 -04:00
int exceed_conns;
int to_kill;
int curr_idle;
MEDIUM: servers: Reorganize the way idle connections are cleaned. Instead of having one task per thread and per server that does clean the idling connections, have only one global task for every servers. That tasks parses all the servers that currently have idling connections, and remove half of them, to put them in a per-thread list of connections to kill. For each thread that does have connections to kill, wake a task to do so, so that the cleaning will be done in the context of said thread.
2019-02-14 12:29:09 -05:00
eb = eb32_lookup_ge(&idle_conn_srv, now_ms - TIMER_LOOK_BACK);
if (!eb) {
/* we might have reached the end of the tree, typically because
* <now_ms> is in the first half and we're first scanning the last
* half. Let's loop back to the beginning of the tree now.
*/
eb = eb32_first(&idle_conn_srv);
if (likely(!eb))
break;
}
if (tick_is_lt(now_ms, eb->key)) {
/* timer not expired yet, revisit it later */
next_wakeup = eb->key;
MEDIUM: servers: Add a way to keep idle connections alive. Add a new keyword for servers, "idle-timeout". If set, unused connections are kept alive until the timeout happens, and will be picked for reuse if no other connection is available.
2018-12-02 08:11:41 -05:00
break;
MEDIUM: servers: Reorganize the way idle connections are cleaned. Instead of having one task per thread and per server that does clean the idling connections, have only one global task for every servers. That tasks parses all the servers that currently have idling connections, and remove half of them, to put them in a per-thread list of connections to kill. For each thread that does have connections to kill, wake a task to do so, so that the cleaning will be done in the context of said thread.
2019-02-14 12:29:09 -05:00
}
srv = eb32_entry(eb, struct server, idle_node);
MEDIUM: connections: Revamp the way idle connections are killed The original algorithm always killed half the idle connections. This doesn't take into account the way the load can change. Instead, we now kill half of the exceeding connections (exceeding connection being the number of used + idle connections past the last maximum used connections reached). That way if we reach a peak, we will kill much less, and it'll slowly go back down when there's less usage.
2020-03-29 18:23:57 -04:00
/* Calculate how many idle connections we want to kill :
* we want to remove half the difference between the total
* of established connections (used or idle) and the max
* number of used connections.
*/
curr_idle = srv->curr_idle_conns;
if (curr_idle == 0)
goto remove;
MEDIUM: server: improve estimate of the need for idle connections Starting with commit 079cb9a ("MEDIUM: connections: Revamp the way idle connections are killed") we started to improve the way to compute the need for idle connections. But the condition to keep a connection idle or drop it when releasing it was not updated. This often results in storms of close when certain thresholds are met, and long series of takeover() when there aren't enough connections left for a thread on a server. This patch tries to improve the situation this way: - it keeps an estimate of the number of connections needed for a server. This estimate is a copy of the max over previous purge period, or is a max of what is seen over current period; it differs from max_used_conns in that this one is a counter that's reset on each purge period ; - when releasing, if the number of current idle+used connections is lower than this last estimate, then we'll keep the connection; - when releasing, if the current thread's idle conns head is empty, and we don't exceed the estimate by the number of threads, then we'll keep the connection. - when cleaning up connections, we consider the max of the last two periods to avoid killing too many idle conns when facing bursty traffic. Thanks to this we can better converge towards a situation where, provided there are enough FDs, each active server keeps at least one idle connection per thread all the time, with a total number close to what was needed over the previous measurement period (as defined by pool-purge-delay). On tests with large numbers of concurrent connections (30k) and many servers (200), this has quite smoothed the CPU usage pattern, increased the reuse rate and roughly halved the takeover rate.
2020-06-29 09:56:35 -04:00
exceed_conns = srv->curr_used_conns + curr_idle - MAX(srv->max_used_conns, srv->est_need_conns);
MEDIUM: connections: Revamp the way idle connections are killed The original algorithm always killed half the idle connections. This doesn't take into account the way the load can change. Instead, we now kill half of the exceeding connections (exceeding connection being the number of used + idle connections past the last maximum used connections reached). That way if we reach a peak, we will kill much less, and it'll slowly go back down when there's less usage.
2020-03-29 18:23:57 -04:00
exceed_conns = to_kill = exceed_conns / 2 + (exceed_conns & 1);
MEDIUM: server: improve estimate of the need for idle connections Starting with commit 079cb9a ("MEDIUM: connections: Revamp the way idle connections are killed") we started to improve the way to compute the need for idle connections. But the condition to keep a connection idle or drop it when releasing it was not updated. This often results in storms of close when certain thresholds are met, and long series of takeover() when there aren't enough connections left for a thread on a server. This patch tries to improve the situation this way: - it keeps an estimate of the number of connections needed for a server. This estimate is a copy of the max over previous purge period, or is a max of what is seen over current period; it differs from max_used_conns in that this one is a counter that's reset on each purge period ; - when releasing, if the number of current idle+used connections is lower than this last estimate, then we'll keep the connection; - when releasing, if the current thread's idle conns head is empty, and we don't exceed the estimate by the number of threads, then we'll keep the connection. - when cleaning up connections, we consider the max of the last two periods to avoid killing too many idle conns when facing bursty traffic. Thanks to this we can better converge towards a situation where, provided there are enough FDs, each active server keeps at least one idle connection per thread all the time, with a total number close to what was needed over the previous measurement period (as defined by pool-purge-delay). On tests with large numbers of concurrent connections (30k) and many servers (200), this has quite smoothed the CPU usage pattern, increased the reuse rate and roughly halved the takeover rate.
2020-06-29 09:56:35 -04:00
BUG/MEDIUM: server: make it possible to kill last idle connections In issue #933, @jaroslawr provided a report indicating that when using many threads and many servers, it's very difficult to terminate the last idle connections on each server. The issue has two causes in fact. The first one is that during the calculation of the estimate of needed connections, we round the computation up while in previous round it was already rounded up, so we end up adding 1 to 1 which once divided by 2 remains 1. The second issue is that servers are not woken up anymore for purging their connections if they don't have activity. The only reason that was there to wake them up again was in case insufficient connections were purged. And even then the purge task itself was not woken up. But that is not enough for getting rid of the long tail of old connections nor updating est_need_conns. This patch makes sure to properly wake up as long as at least one idle connection remains, and not to round up the needed connections anymore. Prior to this patch, a test involving many connections which suddenly stopped would keep many idle connections, now they're effectively halved every pool-purge-delay. This needs to be backported to 2.2.
2020-11-05 03:12:20 -05:00
srv->est_need_conns = (srv->est_need_conns + srv->max_used_conns) / 2;
MEDIUM: server: improve estimate of the need for idle connections Starting with commit 079cb9a ("MEDIUM: connections: Revamp the way idle connections are killed") we started to improve the way to compute the need for idle connections. But the condition to keep a connection idle or drop it when releasing it was not updated. This often results in storms of close when certain thresholds are met, and long series of takeover() when there aren't enough connections left for a thread on a server. This patch tries to improve the situation this way: - it keeps an estimate of the number of connections needed for a server. This estimate is a copy of the max over previous purge period, or is a max of what is seen over current period; it differs from max_used_conns in that this one is a counter that's reset on each purge period ; - when releasing, if the number of current idle+used connections is lower than this last estimate, then we'll keep the connection; - when releasing, if the current thread's idle conns head is empty, and we don't exceed the estimate by the number of threads, then we'll keep the connection. - when cleaning up connections, we consider the max of the last two periods to avoid killing too many idle conns when facing bursty traffic. Thanks to this we can better converge towards a situation where, provided there are enough FDs, each active server keeps at least one idle connection per thread all the time, with a total number close to what was needed over the previous measurement period (as defined by pool-purge-delay). On tests with large numbers of concurrent connections (30k) and many servers (200), this has quite smoothed the CPU usage pattern, increased the reuse rate and roughly halved the takeover rate.
2020-06-29 09:56:35 -04:00
if (srv->est_need_conns < srv->max_used_conns)
srv->est_need_conns = srv->max_used_conns;
BUG/MINOR: server/idle: at least use atomic stores when updating max_used_conns In 2.2, some idle conns usage metrics were added by commit cf612a045 ("MINOR: servers: Add a counter for the number of currently used connections."), which mentioned that the operation doesn't need to be atomic since we're not seeking exact values. This is true but at least we should use atomic stores to make sure not to cause invalid values to appear on archs that wouldn't guarantee atomicity when writing an int, such as writing two 16-bit words. This is pretty unlikely on our targets but better keep the code safe against this. This may be backported as far as 2.2.
2022-11-21 08:32:33 -05:00
HA_ATOMIC_STORE(&srv->max_used_conns, srv->curr_used_conns);
MEDIUM: connections: Revamp the way idle connections are killed The original algorithm always killed half the idle connections. This doesn't take into account the way the load can change. Instead, we now kill half of the exceeding connections (exceeding connection being the number of used + idle connections past the last maximum used connections reached). That way if we reach a peak, we will kill much less, and it'll slowly go back down when there's less usage.
2020-03-29 18:23:57 -04:00
BUG/MEDIUM: server: don't kill all idle conns when there are not enough In srv_cleanup_idle_connections(), we compute how many idle connections are in excess compared to the average need. But we may actually be missing some, for example if a certain number were recently closed and the average of used connections didn't change much since previous period. In this case exceed_conn can become negative. There was no special case for this in the code, and calculating the per-thread share of connections to kill based on this value resulted in special value -1 to be passed to srv_migrate_conns_to_remove(), which for this function means "kill all of them", as used in srv_cleanup_connections() for example. This causes large variations of idle connections counts on servers and CPU spikes at the moment the cleanup task passes. These were quite more visible with SSL as it costs CPU to close and re-establish these connections, and it also takes time, reducing the reuse ratio, hence increasing the amount of connections during reconnection. In this patch we simply skip the killing loop when this condition is met. No backport is needed, this is purely 2.2.
2020-07-02 13:05:30 -04:00
if (exceed_conns <= 0)
goto remove;
BUG/MINOR: server: start cleaning idle connections from various points There's a minor glitch with the way idle connections start to be evicted. The lookup always goes from thread 0 to thread N-1. This causes depletion of connections on the first threads and abundance on the last ones. This is visible with the takeover() stats below: $ socat - /tmp/sock1 <<< "show activity"|grep ^fd ; \ sleep 10 ; \ socat -/tmp/sock1 <<< "show activity"|grep ^fd fd_takeover: 300144 [ 91887 84029 66254 57974 ] fd_takeover: 359631 [ 111369 99699 79145 69418 ] There are respectively 19k, 15k, 13k and 11k takeovers for only 4 threads, indicating that the first thread needs a foreign FD twice more often than the 4th one. This patch changes this si that all threads are scanned in round robin starting with the current one. The takeovers now happen in a much more distributed way (about 4 times 9k) : fd_takeover: 1420081 [ 359562 359453 346586 354480 ] fd_takeover: 1457044 [ 368779 368429 355990 363846 ] There is no need to backport this, as this happened along a few patches that were merged during 2.2 development.
2020-06-29 08:43:16 -04:00
/* check all threads starting with ours */
for (i = tid;;) {
MEDIUM: connections: Revamp the way idle connections are killed The original algorithm always killed half the idle connections. This doesn't take into account the way the load can change. Instead, we now kill half of the exceeding connections (exceeding connection being the number of used + idle connections past the last maximum used connections reached). That way if we reach a peak, we will kill much less, and it'll slowly go back down when there's less usage.
2020-03-29 18:23:57 -04:00
int max_conn;
CLEANUP: backend: use a single variable for removed in srv_cleanup_idle_conns() Probably due to older code, there's a boolean variable used to set another one which is then checked. Also the first check is made under the lock, which is unnecessary. Let's simplify this and use a single variable. This only makes the code clearer, it doesn't change the output code.
2025-09-12 10:28:58 -04:00
int removed;
MEDIUM: servers: Reorganize the way idle connections are cleaned. Instead of having one task per thread and per server that does clean the idling connections, have only one global task for every servers. That tasks parses all the servers that currently have idling connections, and remove half of them, to put them in a per-thread list of connections to kill. For each thread that does have connections to kill, wake a task to do so, so that the cleaning will be done in the context of said thread.
2019-02-14 12:29:09 -05:00
MEDIUM: connections: Revamp the way idle connections are killed The original algorithm always killed half the idle connections. This doesn't take into account the way the load can change. Instead, we now kill half of the exceeding connections (exceeding connection being the number of used + idle connections past the last maximum used connections reached). That way if we reach a peak, we will kill much less, and it'll slowly go back down when there's less usage.
2020-03-29 18:23:57 -04:00
max_conn = (exceed_conns * srv->curr_idle_thr[i]) /
curr_idle + 1;
MEDIUM: connections: Don't use a lock when moving connections to remove. Make it so we don't have to take a lock while moving a connection from the idle list to the toremove_list by taking advantage of the MT_LIST.
2020-06-29 14:15:59 -04:00
MEDIUM: connection: protect idle conn lists with locks This is a preparation work for connection reuse with sni/proxy protocol/specific src-dst addresses. Protect every access to idle conn lists with a lock. This is currently strictly not needed because the access to the list are made with atomic operations. However, to be able to reuse connection with specific parameters, the list storage will be converted to eb-trees. As this structure does not have atomic operation, it is mandatory to protect it with a lock. For this, the takeover lock is reused. Its role was to protect during connection takeover. As it is now extended to general idle conns usage, it is renamed to idle_conns_lock. A new lock section is also instantiated named IDLE_CONNS_LOCK to isolate its impact on performance.
2021-01-11 03:21:52 -05:00
HA_SPIN_LOCK(IDLE_CONNS_LOCK, &idle_conns[i].idle_conns_lock);
CLEANUP: backend: use a single variable for removed in srv_cleanup_idle_conns() Probably due to older code, there's a boolean variable used to set another one which is then checked. Also the first check is made under the lock, which is unnecessary. Let's simplify this and use a single variable. This only makes the code clearer, it doesn't change the output code.
2025-09-12 10:28:58 -04:00
removed = srv_migrate_conns_to_remove(srv, i, max_conn);
MEDIUM: connection: protect idle conn lists with locks This is a preparation work for connection reuse with sni/proxy protocol/specific src-dst addresses. Protect every access to idle conn lists with a lock. This is currently strictly not needed because the access to the list are made with atomic operations. However, to be able to reuse connection with specific parameters, the list storage will be converted to eb-trees. As this structure does not have atomic operation, it is mandatory to protect it with a lock. For this, the takeover lock is reused. Its role was to protect during connection takeover. As it is now extended to general idle conns usage, it is renamed to idle_conns_lock. A new lock section is also instantiated named IDLE_CONNS_LOCK to isolate its impact on performance.
2021-01-11 03:21:52 -05:00
HA_SPIN_UNLOCK(IDLE_CONNS_LOCK, &idle_conns[i].idle_conns_lock);
MEDIUM: connections: Don't use a lock when moving connections to remove. Make it so we don't have to take a lock while moving a connection from the idle list to the toremove_list by taking advantage of the MT_LIST.
2020-06-29 14:15:59 -04:00
CLEANUP: backend: use a single variable for removed in srv_cleanup_idle_conns() Probably due to older code, there's a boolean variable used to set another one which is then checked. Also the first check is made under the lock, which is unnecessary. Let's simplify this and use a single variable. This only makes the code clearer, it doesn't change the output code.
2025-09-12 10:28:58 -04:00
if (removed)
MINOR: connection: align toremove_{lock,connections} and cleanup into idle_conns We used to have 3 thread-based arrays for toremove_lock, idle_cleanup, and toremove_connections. The problem is that these items are small, and that this creates false sharing between threads since it's possible to pack up to 8-16 of these values into a single cache line. This can cause real damage where there is contention on the lock. This patch creates a new array of struct "idle_conns" that is aligned on a cache line and which contains all three members above. This way each thread has access to its variables without hindering the other ones. Just doing this increased the HTTP/1 request rate by 5% on a 16-thread machine. The definition was moved to connection.{c,h} since it appeared a more natural evolution of the ongoing changes given that there was already one of them declared in connection.h previously.
2020-06-27 18:19:17 -04:00
task_wakeup(idle_conns[i].cleanup_task, TASK_WOKEN_OTHER);
BUG/MINOR: server: start cleaning idle connections from various points There's a minor glitch with the way idle connections start to be evicted. The lookup always goes from thread 0 to thread N-1. This causes depletion of connections on the first threads and abundance on the last ones. This is visible with the takeover() stats below: $ socat - /tmp/sock1 <<< "show activity"|grep ^fd ; \ sleep 10 ; \ socat -/tmp/sock1 <<< "show activity"|grep ^fd fd_takeover: 300144 [ 91887 84029 66254 57974 ] fd_takeover: 359631 [ 111369 99699 79145 69418 ] There are respectively 19k, 15k, 13k and 11k takeovers for only 4 threads, indicating that the first thread needs a foreign FD twice more often than the 4th one. This patch changes this si that all threads are scanned in round robin starting with the current one. The takeovers now happen in a much more distributed way (about 4 times 9k) : fd_takeover: 1420081 [ 359562 359453 346586 354480 ] fd_takeover: 1457044 [ 368779 368429 355990 363846 ] There is no need to backport this, as this happened along a few patches that were merged during 2.2 development.
2020-06-29 08:43:16 -04:00
if ((i = ((i + 1 == global.nbthread) ? 0 : i + 1)) == tid)
break;
MEDIUM: servers: Reorganize the way idle connections are cleaned. Instead of having one task per thread and per server that does clean the idling connections, have only one global task for every servers. That tasks parses all the servers that currently have idling connections, and remove half of them, to put them in a per-thread list of connections to kill. For each thread that does have connections to kill, wake a task to do so, so that the cleaning will be done in the context of said thread.
2019-02-14 12:29:09 -05:00
}
MEDIUM: connections: Revamp the way idle connections are killed The original algorithm always killed half the idle connections. This doesn't take into account the way the load can change. Instead, we now kill half of the exceeding connections (exceeding connection being the number of used + idle connections past the last maximum used connections reached). That way if we reach a peak, we will kill much less, and it'll slowly go back down when there's less usage.
2020-03-29 18:23:57 -04:00
remove:
MEDIUM: servers: Reorganize the way idle connections are cleaned. Instead of having one task per thread and per server that does clean the idling connections, have only one global task for every servers. That tasks parses all the servers that currently have idling connections, and remove half of them, to put them in a per-thread list of connections to kill. For each thread that does have connections to kill, wake a task to do so, so that the cleaning will be done in the context of said thread.
2019-02-14 12:29:09 -05:00
eb32_delete(&srv->idle_node);
BUG/MEDIUM: server: make it possible to kill last idle connections In issue #933, @jaroslawr provided a report indicating that when using many threads and many servers, it's very difficult to terminate the last idle connections on each server. The issue has two causes in fact. The first one is that during the calculation of the estimate of needed connections, we round the computation up while in previous round it was already rounded up, so we end up adding 1 to 1 which once divided by 2 remains 1. The second issue is that servers are not woken up anymore for purging their connections if they don't have activity. The only reason that was there to wake them up again was in case insufficient connections were purged. And even then the purge task itself was not woken up. But that is not enough for getting rid of the long tail of old connections nor updating est_need_conns. This patch makes sure to properly wake up as long as at least one idle connection remains, and not to round up the needed connections anymore. Prior to this patch, a test involving many connections which suddenly stopped would keep many idle connections, now they're effectively halved every pool-purge-delay. This needs to be backported to 2.2.
2020-11-05 03:12:20 -05:00
if (srv->curr_idle_conns) {
MEDIUM: servers: Reorganize the way idle connections are cleaned. Instead of having one task per thread and per server that does clean the idling connections, have only one global task for every servers. That tasks parses all the servers that currently have idling connections, and remove half of them, to put them in a per-thread list of connections to kill. For each thread that does have connections to kill, wake a task to do so, so that the cleaning will be done in the context of said thread.
2019-02-14 12:29:09 -05:00
/* There are still more idle connections, add the
* server back in the tree.
*/
BUG/MEDIUM: server: make it possible to kill last idle connections In issue #933, @jaroslawr provided a report indicating that when using many threads and many servers, it's very difficult to terminate the last idle connections on each server. The issue has two causes in fact. The first one is that during the calculation of the estimate of needed connections, we round the computation up while in previous round it was already rounded up, so we end up adding 1 to 1 which once divided by 2 remains 1. The second issue is that servers are not woken up anymore for purging their connections if they don't have activity. The only reason that was there to wake them up again was in case insufficient connections were purged. And even then the purge task itself was not woken up. But that is not enough for getting rid of the long tail of old connections nor updating est_need_conns. This patch makes sure to properly wake up as long as at least one idle connection remains, and not to round up the needed connections anymore. Prior to this patch, a test involving many connections which suddenly stopped would keep many idle connections, now they're effectively halved every pool-purge-delay. This needs to be backported to 2.2.
2020-11-05 03:12:20 -05:00
srv->idle_node.key = tick_add(srv->pool_purge_delay, now_ms);
MEDIUM: servers: Reorganize the way idle connections are cleaned. Instead of having one task per thread and per server that does clean the idling connections, have only one global task for every servers. That tasks parses all the servers that currently have idling connections, and remove half of them, to put them in a per-thread list of connections to kill. For each thread that does have connections to kill, wake a task to do so, so that the cleaning will be done in the context of said thread.
2019-02-14 12:29:09 -05:00
eb32_insert(&idle_conn_srv, &srv->idle_node);
BUG/MEDIUM: server: make it possible to kill last idle connections In issue #933, @jaroslawr provided a report indicating that when using many threads and many servers, it's very difficult to terminate the last idle connections on each server. The issue has two causes in fact. The first one is that during the calculation of the estimate of needed connections, we round the computation up while in previous round it was already rounded up, so we end up adding 1 to 1 which once divided by 2 remains 1. The second issue is that servers are not woken up anymore for purging their connections if they don't have activity. The only reason that was there to wake them up again was in case insufficient connections were purged. And even then the purge task itself was not woken up. But that is not enough for getting rid of the long tail of old connections nor updating est_need_conns. This patch makes sure to properly wake up as long as at least one idle connection remains, and not to round up the needed connections anymore. Prior to this patch, a test involving many connections which suddenly stopped would keep many idle connections, now they're effectively halved every pool-purge-delay. This needs to be backported to 2.2.
2020-11-05 03:12:20 -05:00
next_wakeup = tick_first(next_wakeup, srv->idle_node.key);
MEDIUM: servers: Reorganize the way idle connections are cleaned. Instead of having one task per thread and per server that does clean the idling connections, have only one global task for every servers. That tasks parses all the servers that currently have idling connections, and remove half of them, to put them in a per-thread list of connections to kill. For each thread that does have connections to kill, wake a task to do so, so that the cleaning will be done in the context of said thread.
2019-02-14 12:29:09 -05:00
}
MEDIUM: servers: Add a way to keep idle connections alive. Add a new keyword for servers, "idle-timeout". If set, unused connections are kept alive until the timeout happens, and will be picked for reuse if no other connection is available.
2018-12-02 08:11:41 -05:00
}
MEDIUM: servers: Reorganize the way idle connections are cleaned. Instead of having one task per thread and per server that does clean the idling connections, have only one global task for every servers. That tasks parses all the servers that currently have idling connections, and remove half of them, to put them in a per-thread list of connections to kill. For each thread that does have connections to kill, wake a task to do so, so that the cleaning will be done in the context of said thread.
2019-02-14 12:29:09 -05:00
HA_SPIN_UNLOCK(OTHER_LOCK, &idle_conn_srv_lock);
BUG/MEDIUM: server: make it possible to kill last idle connections In issue #933, @jaroslawr provided a report indicating that when using many threads and many servers, it's very difficult to terminate the last idle connections on each server. The issue has two causes in fact. The first one is that during the calculation of the estimate of needed connections, we round the computation up while in previous round it was already rounded up, so we end up adding 1 to 1 which once divided by 2 remains 1. The second issue is that servers are not woken up anymore for purging their connections if they don't have activity. The only reason that was there to wake them up again was in case insufficient connections were purged. And even then the purge task itself was not woken up. But that is not enough for getting rid of the long tail of old connections nor updating est_need_conns. This patch makes sure to properly wake up as long as at least one idle connection remains, and not to round up the needed connections anymore. Prior to this patch, a test involving many connections which suddenly stopped would keep many idle connections, now they're effectively halved every pool-purge-delay. This needs to be backported to 2.2.
2020-11-05 03:12:20 -05:00
task->expire = next_wakeup;
MEDIUM: servers: Add a way to keep idle connections alive. Add a new keyword for servers, "idle-timeout". If set, unused connections are kept alive until the timeout happens, and will be picked for reuse if no other connection is available.
2018-12-02 08:11:41 -05:00
return task;
}
MEDIUM: connections: Add a way to control the number of idling connections. As by default we add all keepalive connections to the idle pool, if we run into a pathological case, where all client don't do keepalive, but the server does, and haproxy is configured to only reuse "safe" connections, we will soon find ourself having lots of idling, unusable for new sessions, connections, while we won't have any file descriptors available to create new connections. To fix this, add 2 new global settings, "pool_low_ratio" and "pool_high_ratio". pool-low-fd-ratio is the % of fds we're allowed to use (against the maximum number of fds available to haproxy) before we stop adding connections to the idle pool, and destroy them instead. The default is 20. pool-high-fd-ratio is the % of fds we're allowed to use (against the maximum number of fds available to haproxy) before we start killing idling connection in the event we have to create a new outgoing connection, and no reuse is possible. The default is 25.
2019-04-16 13:07:22 -04:00
MINOR: srv: close all idle connections on shutdown Implement a function to close all server idle connections. This function is called via a global deinit server handler. The main objective is to prevents from leaving sockets in TIME_WAIT state. To limit the set of operations on shutdown and prevents tasks rescheduling, only the ctrl stack closing is done.
2021-04-29 11:30:05 -04:00
/* Close remaining idle connections. This functions is designed to be run on
* process shutdown. This guarantees a proper socket shutdown to avoid
* TIME_WAIT state. For a quick operation, only ctrl is closed, xprt stack is
* bypassed.
*
* This function is not thread-safe so it must only be called via a global
* deinit function.
*/
static void srv_close_idle_conns(struct server *srv)
{
MEDIUM: connection: move idle connection trees to ceb64 Idle connection trees currently require a 56-byte conn_hash_node per connection, which can be reduced to 32 bytes by moving to ceb64. While ceb64 is theoretically slower, in practice here we're essentially dealing with trees that almost always contain a single key and many duplicates. In this case, ceb64 insert and lookup functions become faster than eb64 ones because all duplicates are a list accessed in O(1) while it's a subtree for eb64. In tests it is impossible to tell the difference between the two, so it's worth reducing the memory usage. This commit brings the following memory savings to conn_hash_node (one per backend connection), and to srv_per_thread (one per thread and per server): struct before after delta conn_hash_nodea 56 32 -24 srv_per_thread 96 72 -24 The delicate part is conn_delete_from_tree(), because we need to know the tree root the connection is attached to. But thanks to recent cleanups, it's now clear enough (i.e. idle/safe/avail vs session are easy to distinguish).
2025-09-12 09:28:33 -04:00
struct ceb_root ***cleaned_tree;
MEDIUM: connection: reintegrate conn_hash_node into connection Previously the conn_hash_node was placed outside the connection due to the big size of the eb64_node that could have negatively impacted frontend connections. But having it outside also means that one extra allocation is needed for each backend connection, and that one memory indirection is needed for each lookup. With the compact trees, the tree node is smaller (16 bytes vs 40) so the overhead is much lower. By integrating it into the connection, We're also eliminating one pointer from the connection to the hash node and one pointer from the hash node to the connection (in addition to the extra object bookkeeping). This results in saving at least 24 bytes per total backend connection, and only inflates connections by 16 bytes (from 240 to 256), which is a reasonable compromise. Tests on a 64-core EPYC show a 2.4% increase in the request rate (from 2.08 to 2.13 Mrps).
2025-09-12 12:12:18 -04:00
struct connection *conn;
MINOR: srv: close all idle connections on shutdown Implement a function to close all server idle connections. This function is called via a global deinit server handler. The main objective is to prevents from leaving sockets in TIME_WAIT state. To limit the set of operations on shutdown and prevents tasks rescheduling, only the ctrl stack closing is done.
2021-04-29 11:30:05 -04:00
int i;
for (i = 0; i < global.nbthread; ++i) {
MEDIUM: connection: move idle connection trees to ceb64 Idle connection trees currently require a 56-byte conn_hash_node per connection, which can be reduced to 32 bytes by moving to ceb64. While ceb64 is theoretically slower, in practice here we're essentially dealing with trees that almost always contain a single key and many duplicates. In this case, ceb64 insert and lookup functions become faster than eb64 ones because all duplicates are a list accessed in O(1) while it's a subtree for eb64. In tests it is impossible to tell the difference between the two, so it's worth reducing the memory usage. This commit brings the following memory savings to conn_hash_node (one per backend connection), and to srv_per_thread (one per thread and per server): struct before after delta conn_hash_nodea 56 32 -24 srv_per_thread 96 72 -24 The delicate part is conn_delete_from_tree(), because we need to know the tree root the connection is attached to. But thanks to recent cleanups, it's now clear enough (i.e. idle/safe/avail vs session are easy to distinguish).
2025-09-12 09:28:33 -04:00
struct ceb_root **conn_trees[] = {
MINOR: srv: close all idle connections on shutdown Implement a function to close all server idle connections. This function is called via a global deinit server handler. The main objective is to prevents from leaving sockets in TIME_WAIT state. To limit the set of operations on shutdown and prevents tasks rescheduling, only the ctrl stack closing is done.
2021-04-29 11:30:05 -04:00
&srv->per_thr[i].idle_conns,
&srv->per_thr[i].safe_conns,
&srv->per_thr[i].avail_conns,
NULL
};
for (cleaned_tree = conn_trees; *cleaned_tree; ++cleaned_tree) {
MEDIUM: connection: reintegrate conn_hash_node into connection Previously the conn_hash_node was placed outside the connection due to the big size of the eb64_node that could have negatively impacted frontend connections. But having it outside also means that one extra allocation is needed for each backend connection, and that one memory indirection is needed for each lookup. With the compact trees, the tree node is smaller (16 bytes vs 40) so the overhead is much lower. By integrating it into the connection, We're also eliminating one pointer from the connection to the hash node and one pointer from the hash node to the connection (in addition to the extra object bookkeeping). This results in saving at least 24 bytes per total backend connection, and only inflates connections by 16 bytes (from 240 to 256), which is a reasonable compromise. Tests on a 64-core EPYC show a 2.4% increase in the request rate (from 2.08 to 2.13 Mrps).
2025-09-12 12:12:18 -04:00
while ((conn = ceb64_item_first(*cleaned_tree, hash_node.node,
hash_node.key, struct connection))) {
MINOR: srv: close all idle connections on shutdown Implement a function to close all server idle connections. This function is called via a global deinit server handler. The main objective is to prevents from leaving sockets in TIME_WAIT state. To limit the set of operations on shutdown and prevents tasks rescheduling, only the ctrl stack closing is done.
2021-04-29 11:30:05 -04:00
if (conn->ctrl->ctrl_close)
conn->ctrl->ctrl_close(conn);
Revert "BUG/MEDIUM: connections: permit to permanently remove an idle conn" The target patch fixes a rare race condition which happen when a MUX IO handler is working on a connection already moved into the purge list. In this case, the handler will incorrectly moved back the connection into the idle list. To fix this, conn_delete_from_tree() was extended to remove flags along with the connection from the idle list. This was performed when the connection is moved into the purge list. However, it introduces another issue related to the idle server connection accounting. Thus it is necessary to revert it prior to the incoming newer fix. This patch must be backported to every version where the original commit is.
2025-11-12 11:38:08 -05:00
conn_delete_from_tree(conn, i);
MINOR: srv: close all idle connections on shutdown Implement a function to close all server idle connections. This function is called via a global deinit server handler. The main objective is to prevents from leaving sockets in TIME_WAIT state. To limit the set of operations on shutdown and prevents tasks rescheduling, only the ctrl stack closing is done.
2021-04-29 11:30:05 -04:00
}
}
}
}
REGISTER_SERVER_DEINIT(srv_close_idle_conns);
MINOR: config: add a new tune.idle-pool.shared global setting. Enables ('on') or disables ('off') sharing of idle connection pools between threads for a same server. The default is to share them between threads in order to minimize the number of persistent connections to a server, and to optimize the connection reuse rate. But to help with debugging or when suspecting a bug in HAProxy around connection reuse, it can be convenient to forcefully disable this idle pool sharing between multiple threads, and force this option to "off". The default is on. This could have been nice to have during the idle connections debugging, but it's not too late to add it!
2020-07-01 12:49:24 -04:00
/* config parser for global "tune.idle-pool.shared", accepts "on" or "off" */
static int cfg_parse_idle_pool_shared(char **args, int section_type, struct proxy *curpx,
CLEANUP: config: make the cfg_keyword parsers take a const for the defproxy The default proxy was passed as a variable to all parsers instead of a const, which is not without risk, especially when some timeout parsers used to make some int pointers point to the default values for comparisons. We want to be certain that none of these parsers will modify the defaults sections by accident, so it's important to mark this proxy as const. This patch touches all occurrences found (89).
2021-03-09 03:53:46 -05:00
const struct proxy *defpx, const char *file, int line,
MINOR: config: add a new tune.idle-pool.shared global setting. Enables ('on') or disables ('off') sharing of idle connection pools between threads for a same server. The default is to share them between threads in order to minimize the number of persistent connections to a server, and to optimize the connection reuse rate. But to help with debugging or when suspecting a bug in HAProxy around connection reuse, it can be convenient to forcefully disable this idle pool sharing between multiple threads, and force this option to "off". The default is on. This could have been nice to have during the idle connections debugging, but it's not too late to add it!
2020-07-01 12:49:24 -04:00
char **err)
{
if (too_many_args(1, args, err, NULL))
return -1;
if (strcmp(args[1], "on") == 0)
global.tune.options |= GTUNE_IDLE_POOL_SHARED;
else if (strcmp(args[1], "off") == 0)
global.tune.options &= ~GTUNE_IDLE_POOL_SHARED;
else {
memprintf(err, "'%s' expects either 'on' or 'off' but got '%s'.", args[0], args[1]);
return -1;
}
return 0;
}
MEDIUM: connections: Add a way to control the number of idling connections. As by default we add all keepalive connections to the idle pool, if we run into a pathological case, where all client don't do keepalive, but the server does, and haproxy is configured to only reuse "safe" connections, we will soon find ourself having lots of idling, unusable for new sessions, connections, while we won't have any file descriptors available to create new connections. To fix this, add 2 new global settings, "pool_low_ratio" and "pool_high_ratio". pool-low-fd-ratio is the % of fds we're allowed to use (against the maximum number of fds available to haproxy) before we stop adding connections to the idle pool, and destroy them instead. The default is 20. pool-high-fd-ratio is the % of fds we're allowed to use (against the maximum number of fds available to haproxy) before we start killing idling connection in the event we have to create a new outgoing connection, and no reuse is possible. The default is 25.
2019-04-16 13:07:22 -04:00
/* config parser for global "tune.pool-{low,high}-fd-ratio" */
static int cfg_parse_pool_fd_ratio(char **args, int section_type, struct proxy *curpx,
CLEANUP: config: make the cfg_keyword parsers take a const for the defproxy The default proxy was passed as a variable to all parsers instead of a const, which is not without risk, especially when some timeout parsers used to make some int pointers point to the default values for comparisons. We want to be certain that none of these parsers will modify the defaults sections by accident, so it's important to mark this proxy as const. This patch touches all occurrences found (89).
2021-03-09 03:53:46 -05:00
const struct proxy *defpx, const char *file, int line,
MEDIUM: connections: Add a way to control the number of idling connections. As by default we add all keepalive connections to the idle pool, if we run into a pathological case, where all client don't do keepalive, but the server does, and haproxy is configured to only reuse "safe" connections, we will soon find ourself having lots of idling, unusable for new sessions, connections, while we won't have any file descriptors available to create new connections. To fix this, add 2 new global settings, "pool_low_ratio" and "pool_high_ratio". pool-low-fd-ratio is the % of fds we're allowed to use (against the maximum number of fds available to haproxy) before we stop adding connections to the idle pool, and destroy them instead. The default is 20. pool-high-fd-ratio is the % of fds we're allowed to use (against the maximum number of fds available to haproxy) before we start killing idling connection in the event we have to create a new outgoing connection, and no reuse is possible. The default is 25.
2019-04-16 13:07:22 -04:00
char **err)
{
int arg = -1;
if (too_many_args(1, args, err, NULL))
return -1;
if (*(args[1]) != 0)
arg = atoi(args[1]);
if (arg < 0 || arg > 100) {
memprintf(err, "'%s' expects an integer argument between 0 and 100.", args[0]);
return -1;
}
if (args[0][10] == 'h')
global.tune.pool_high_ratio = arg;
else
global.tune.pool_low_ratio = arg;
return 0;
}
/* config keyword parsers */
static struct cfg_kw_list cfg_kws = {ILH, {
MINOR: config: add a new tune.idle-pool.shared global setting. Enables ('on') or disables ('off') sharing of idle connection pools between threads for a same server. The default is to share them between threads in order to minimize the number of persistent connections to a server, and to optimize the connection reuse rate. But to help with debugging or when suspecting a bug in HAProxy around connection reuse, it can be convenient to forcefully disable this idle pool sharing between multiple threads, and force this option to "off". The default is on. This could have been nice to have during the idle connections debugging, but it's not too late to add it!
2020-07-01 12:49:24 -04:00
{ CFG_GLOBAL, "tune.idle-pool.shared", cfg_parse_idle_pool_shared },
MEDIUM: connections: Add a way to control the number of idling connections. As by default we add all keepalive connections to the idle pool, if we run into a pathological case, where all client don't do keepalive, but the server does, and haproxy is configured to only reuse "safe" connections, we will soon find ourself having lots of idling, unusable for new sessions, connections, while we won't have any file descriptors available to create new connections. To fix this, add 2 new global settings, "pool_low_ratio" and "pool_high_ratio". pool-low-fd-ratio is the % of fds we're allowed to use (against the maximum number of fds available to haproxy) before we stop adding connections to the idle pool, and destroy them instead. The default is 20. pool-high-fd-ratio is the % of fds we're allowed to use (against the maximum number of fds available to haproxy) before we start killing idling connection in the event we have to create a new outgoing connection, and no reuse is possible. The default is 25.
2019-04-16 13:07:22 -04:00
{ CFG_GLOBAL, "tune.pool-high-fd-ratio", cfg_parse_pool_fd_ratio },
{ CFG_GLOBAL, "tune.pool-low-fd-ratio", cfg_parse_pool_fd_ratio },
{ 0, NULL, NULL }
}};
INITCALL1(STG_REGISTER, cfg_register_keywords, &cfg_kws);
[BIGMOVE] exploded the monolithic haproxy.c file into multiple files. The files are now stored under : - include/haproxy for the generic includes - include/types.h for the structures needed within prototypes - include/proto.h for function prototypes and inline functions - src/*.c for the C files Most include files are now covered by LGPL. A last move still needs to be done to put inline functions under GPL and not LGPL. Version has been set to 1.3.0 in the code but some control still needs to be done before releasing.
2006-06-25 20:48:02 -04:00
/*
* Local variables:
* c-indent-level: 8
* c-basic-offset: 8
* End:
*/
Reference in a new issue Copy permalink