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.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to