Hi,

Le 26/03/2015 15:16, jeff saremi a écrit :
checking once more to see if anyone has the answer as to why i get two
haproxy processes launched?
what would happen with the second one considering that the first one's
already using the listening sockets?
How can this be fixed?thanks

Please consider being far less impatient. Sending "UP"-like messages won't help. Users on this list may be busy and can't answer as soon as you ask a question.

For some details, you can refer to this thread, where the -Ds option was introduced :
http://comments.gmane.org/gmane.comp.web.haproxy/10874

And here for a switch to the systemd "mixed" KillMode :
http://comments.gmane.org/gmane.comp.web.haproxy/18639

By reading them, you'll see why there are 2 processes when using the systemd wrapper.





------------------------------------------------------------------------
From: jeffsar...@hotmail.com
To: haproxy@formilux.org
Subject: RE: Which signal causes HAProxy to reload its config
Date: Wed, 25 Mar 2015 10:39:06 -0400



------------------------------------------------------------------------
From: jeffsar...@hotmail.com
To: haproxy@formilux.org
Subject: RE: Which signal causes HAProxy to reload its config
Date: Wed, 25 Mar 2015 10:20:57 -0400

 > From: marc-anto...@perennou.com
 > Date: Wed, 25 Mar 2015 12:42:21 +0100
 > Subject: Re: Which signal causes HAProxy to reload its config
 > To: jeffsar...@hotmail.com
 > CC: haproxy@formilux.org
 >
 > On 25 March 2015 at 12:25, jeff saremi <jeffsar...@hotmail.com> wrote:
 > > I have to do manually what "-sf" is supposed to be doing since it's
either not working or not supported and removed.
 > > I know what that does is send a signal to the pid stored by the
haproxy process. I'd like to do that myself.
 > > Just need to know the signal name.
 > > thanks
 > > jeff
 >
 > Haproxy doesn't reload its config.
 > -sf is there so that the new haproxy you're spawning tells the old one
 > to stop accepting new connections and exit once the current one are
 > closed.
 > You do not send a signal to the running haproxy process (well, you do,
 > but not only), you *replace* it.
 >
 > What you may be looking for, though, is haproxy-systemd-wrapper, which
 > does all this automatically when it receives SIGUSR2 or SIGHUP.
 >
 > Regards,
 > Marc-Antoine

one problem leads to another
This is what i get when I run haproxy-systemd-wrapper on a linux command
line.
I could be wrong but the problem may be the option "-Ds" ? instead of
just "D"?

server:/haproxy-1.5.8 $ ./haproxy-systemd-wrapper -p /tmp/haproxy_pid.pid
<7>haproxy-systemd-wrapper: executing /haproxy-1.5.8/haproxy -p
/tmp/haproxy_pid.pid -Ds
HA-Proxy version 1.5.8 2014/10/31
Copyright 2000-2014 Willy Tarreau <w...@1wt.eu>

Usage : haproxy [-f <cfgfile>]* [ -vdVD ] [ -n <maxconn> ] [ -N <maxpconn> ]
         [ -p <pidfile> ] [ -m <max megs> ] [ -C <dir> ]
         -v displays version ; -vv shows known build options.
         -d enters debug mode ; -db only disables background mode.
         -dM[<byte>] poisons memory with <byte> (defaults to 0x50)
         -V enters verbose mode (disables quiet mode)
         -D goes daemon ; -C changes to <dir> before loading files.
         -q quiet mode : don't display messages
         -c check mode : only check config files and exit
         -n sets the maximum total # of connections (2000)
         -m limits the usable amount of memory (in MB)
         -N sets the default, per-proxy maximum # of connections (2000)
         -L set local peer name (default to hostname)
         -p writes pids of all children to this file
         -de disables epoll() usage even when available
         -dp disables poll() usage even when available
         -dV disables SSL verify on servers side
         -sf/-st [pid ]* finishes/terminates old pids. Must be last
arguments.


ok that one was because it was missing the -f config

however this is what happens after a successful run:

for each haproxy-systemd-wrapper process i get 2 harproxy processes running.
So i send
kill -1 haproxy-systemd-wrapper
then i get 4 haproxy processes.
and so on until the older processes exit
Could someone explain the rationale behind two haproxy processes? or ami
doing something wrong?

thanks
Jeff




--
Cyril Bonté

Reply via email to