On 10/04/2017 11:48 μμ, Olivier Houchard wrote: > On Mon, Apr 10, 2017 at 10:49:21PM +0200, Pavlos Parissis wrote: >> 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, >> > > > > Hi Pavlos, > > Yeah I see what you mean, it is certainly doable, though -x is a bit special, > because you don't use it the first time you run haproxy, only for reloading, > so that would mean the wrapper has special knowledge about it, and remove it > from the user-supplied command line the first time it's called. I'm a bit > uneasy about that, but if it's felt the best way to do it, I'll go ahead. >
I see, I forgot that the -x argument has only a meaning for the reload phase and ExecReload uses haproxy and not the haproxy-systemd-wrapper. So, it makes sense to pass the environment variable and let haproxy-systemd-wrapper do its thing only on the reload. Please ignore what I wrote above for EXTRAOPTS, sorry for the confusion. Cheers, Pavlos
signature.asc
Description: OpenPGP digital signature
