On 07/04/2017 11:17 μμ, Olivier Houchard wrote: > On Fri, Apr 07, 2017 at 09:58:57PM +0200, Pavlos Parissis wrote: >> On 06/04/2017 04:57 ????, Olivier Houchard wrote: >>> On Thu, Apr 06, 2017 at 04:56:47PM +0200, Pavlos Parissis wrote: >>>> On 06/04/2017 04:25 ????, Olivier Houchard wrote: >>>>> Hi, >>>>> >>>>> The attached patchset is the first cut at an attempt to work around the >>>>> linux issues with SOREUSEPORT that makes haproxy refuse a few new >>>>> connections >>>>> under heavy load. >>>>> This works by transferring the existing sockets to the new process via the >>>>> stats socket. A new command-line flag has been added, -x, that takes the >>>>> path to the unix socket as an argument, and if set, will attempt to >>>>> retrieve >>>>> all the listening sockets; >>>>> Right now, any error, either while connecting to the socket, or retrieving >>>>> the file descriptors, is fatal, but maybe it'd be better to just fall back >>>>> to the previous behavior instead of opening any missing socket ? I'm still >>>>> undecided about that. >>>>> >>>>> Any testing, comments, etc would be greatly appreciated. >>>>> >>>> >>>> Does this patch set support HAProxy in multiprocess mode (nbproc > 1) ? >>>> >>> >>> Hi Pavlos, >>> >>> If it does not, it's a bug :) >>> In my few tests, it seemed to work. >>> >>> Olivier >>> >> >> >> I run systems with systemd and I can't see how I can test the seamless reload >> functionality ( thanks for that) without a proper support for the UNIX socket >> file argument (-x) in the haproxy-systemd-wrapper. >> >> I believe you need to modify the wrapper to accept -x argument for a single >> UNIX socket file or -X for a directory path with multiple UNIX socket files, >> when HAProxy runs in multi-process mode. >> >> What do you think? >> >> Cheers, >> Pavlos >> >> >> > > > Hi Pavlos, > > I didn't consider systemd, so it may be I have to investigate there. > You don't need to talk to all the processes to get the sockets, in the new > world order, each process does have all the sockets, although it will accept > connections only for those for which it is configured to do so (I plan to add > a configuration option to restore the old behavior, for those who don't need > that, and want to save file descriptors). > Reading the haproxy-systemd-wrapper code, it should be trivial. > I just need to figure out how to properly provide the socket path to the > wrapper. > I see that you already made use of a few environment variables in > haproxy.service. Would that be reasonnable to add a new one, that could > be set in haproxy.service.d/overwrite.conf ? I'm not super-used to systemd, > and I'm not sure of how people are doing that kind of things. >
I believe you are referring to $CONFIG and PIDFILE environment variables. Those two variables are passed to the two arguments, which were present but impossible to adjust their input, switching to variables allowed people to overwrite their input. In this case, we are talking about a new functionality I guess the best approach would be to have ExecStart using EXTRAOPTS: ExecStart=/usr/sbin/haproxy-systemd-wrapper -f $CONFIG -p $PIDFILE $EXTRAOPTS This will allow users to set a value to the new argument and any other argument they want cat /etc/systemd/system/haproxy.service.d/overwrite.conf [Service] Environment="CONFIG=/etc/haproxy/haproxy.cfg" "PIDFILE=/run/haproxy.pid" "EXTRAOPTS=-x /foobar" or using default configuration file /etc/default/haproxy [Service] Environment="CONFIG=/etc/haproxy/haproxy.cfg" "PIDFILE=/run/haproxy.pid" EnvironmentFile=-/etc/default/haproxy ExecStart=/usr/sbin/haproxy-systemd-wrapper -f $CONFIG -p $PIDFILE $EXTRAOPTS cat /etc/default/haproxy EXTRAOPTS="-x /foobar" I hope it helps, Cheers,
signature.asc
Description: OpenPGP digital signature
