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. Regards, Olivier
