It is totally normal that systemd kills the new process as the main one which was the first has exited. This is the expected behaviour.
I'm currently patching haproxy to fully support systemd, I'll probably submit my patches by tomorrow (It's fully functionnal here, only needs a little cleaning) On 7 February 2013 16:31, Eugene Istomin <[email protected]> wrote: > ** > > I think the main problem is in systemd: > > > > - from commandline -sf working as expected > > - from sysvinit -sf working as expected > > - from systemd -sf only stop process. > > > > I try both init.d & systemd scripts in systemd-based linux - all results > are the same: > > > > Loaded: loaded (/lib/systemd/system/haproxy.service; disabled) > > Active: failed (Result: signal) since Thu, 07 Feb 2013 17:18:43 +0200; > 12s ago > > Process: 28125 ExecReload=/usr/sbin/haproxy -D -f > /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -sf $MAINPID (code=exited, > status=0/SUCCESS) > > Process: 28118 ExecStart=/usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg > -p /var/run/haproxy.pid (code=exited, status=0/SUCCESS) > > Process: 28115 ExecStartPre=/usr/sbin/haproxy -c -q -f > /etc/haproxy/haproxy.cfg (code=exited, status=0/SUCCESS) > > Main PID: 28126 (code=killed, signal=KILL) > > CGroup: name=systemd:/system/haproxy.service > > > > > > systemd script: > > [Unit] > > Description=HAProxy For TCP And HTTP Based Applications > > After=network.target > > > > [Service] > > Type=forking > > PIDFile=/var/run/haproxy.pid > > ExecStartPre=/usr/sbin/haproxy -c -q -f /etc/haproxy/haproxy.cfg > > ExecStart=/usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p > /var/run/haproxy.pid > > ExecReload=/usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p > /var/run/haproxy.pid -sf $MAINPID > > > > [Install] > > WantedBy=multi-user.target > > > > -- > > Best regards, > > Eugene Istomin > > > > > On Thursday 07 February 2013 14:07:44 Baptiste wrote: > > > You should have a new HAProxy process started using the new > > > configuration and binding the ports... > > > > > > cheers > > > > > > On 2/7/13, Eugene Istomin <[email protected]> wrote: > > > > Thanks for the answer, > > > > > > > > as written in > > > > http://www.mgoff.in/2010/04/18/haproxy-reloading-your-config-with- > > > > minimal-service-impact/ > > > > "The end-result is a reload of the configuration file which is not > visible > > > > by > > > > the customer" > > > > > > > > But in our case it leads to unbinding from all ports and finishing > haproxy > > > > process. > > > > Can this issue related to rpm build options? RPM build log is > > > > > https://build.opensuse.org/package/rawlog?arch=x86_64&package=haproxy-1.5&; > > > > project=server%3Ahttp&repository=openSUSE_12.2 > > > > > > > > > > > > -- > > > > Best regards, > > > > Eugene Istomin > > > > > > > > On Thursday 07 February 2013 07:28:17 Willy Tarreau wrote: > > > >> Hello Eugene, > > > >> > > > >> On Wed, Feb 06, 2013 at 08:29:33PM +0200, Eugene Istomin wrote: > > > >> > Hello, > > > >> > > > > >> > We have problem with reload/HUP: > > > >> > if i run #/usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p > > > >> > /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid) - haproxy > process > > > >> > is > > > >> > shutting down and exit > > > >> > > > >> This is the intended behaviour, it unbinds from its ports so that the > new > > > >> process can bind, then waits for all existing connections to terminate > > > >> and leaves. Isn't it what you're observing ? What would you have > expected > > > >> instead ? > > > >> > > > >> Willy >
