4

I have a requirement to run a couple of instances of haproxy and I need to update the haproxy.service file to add the second command / instance. Google lead me to adding the second command on the same ExecStart= option, separated by a semicolon, this didn't work.

The following made me think that I could add a second ExecStart= with the extra command, this also didn't work. http://www.freedesktop.org/software/systemd/man/systemd.service.html

How do I go about getting two instances of haproxy to run via a systemd service?

Original command

ExecStart=/usr/local/sbin/haproxy-systemd-wrapper -f /etc/haproxy.conf -p /var/run/haproxy.pid

New command

ExecStart=/usr/local/sbin/haproxy-systemd-wrapper -f /etc/haproxy.conf -p /var/run/haproxy.pid; ExecStart=/usr/local/sbin/haproxy-systemd-wrapper -f /etc/haproxy2.conf -p /var/run/haproxy2.pid

Second attempt

ExecStart=/usr/local/sbin/haproxy-systemd-wrapper -f /etc/haproxy.conf -p /var/run/haproxy.pid
ExecStart=/usr/local/sbin/haproxy-systemd-wrapper -f /etc/haproxy2.conf -p /var/run/haproxy2.pid

Update: This is what I get from service haproxy status:

[root@lb01 ~]# service haproxy status
Redirecting to /bin/systemctl status  haproxy.service
haproxy.service - HAProxy Load Balancer
   Loaded: loaded (/usr/lib/systemd/system/haproxy.service; enabled)
   Active: inactive (dead) since Fri 2015-10-30 16:35:44 GMT; 6s ago
  Process: 3221 ExecStart=/usr/local/sbin/haproxy-systemd-wrapper -f /etc/haproxy.conf -p /var/run/haproxy.pid; /usr/local/sbin/haproxy-systemd-wrapper -f /etc/haproxy2.conf -p /var/run/haproxy2.pid (code=exited, status=0/SUCCESS)
 Main PID: 3221 (code=exited, status=0/SUCCESS)
Oct 30 16:48:01 lb01 systemd: Started HAProxy Load Balancer.
Oct 30 16:48:01 lb01 haproxy-systemd-wrapper: Usage : haproxy [-f <cfgfile>]* [ -vdVD ] [ -n <maxconn> ] [ -N <maxpconn> ]
Oct 30 16:48:01 lb01 haproxy-systemd-wrapper: [ -p <pidfile> ] [ -m <max megs> ] [ -C <dir> ]

Looks like haproxy is maybe reading in the semicolon and the extra command as parameters?

Improve this question
  • What do you mean by "didn't work"? How do you know? Anything you see? Logfiles? Error messages? What you don't see that you shoud? More info helps. – RobertL Oct 30 '15 at 16:28
  • I've updated the question, hope that helps. /var/log/messages, simply has the same errors as the status check. – Aftab Oct 30 '15 at 16:44
  • Are the instances related? Or could you start and stop them independently? – Bram Oct 30 '15 at 19:29
  • They can be started independently, once instance is for exchange layer 7 config load balancing and the other is for nothing more that Exchange http redirect method for autodiscover. – Aftab Oct 31 '15 at 2:57
4

If the different haproxy instances are not related the simplest solution by far is to use the existing unit as is and simply create a second one for the additional service you need.

Copy the unit file and edit the ExecStart option to point to the second config file.

If you foresee starting many more of these services you might want to use the template function of systemd.

Create a /etc/systemd/system/haproxy@.service unit as a copy of the existing unit and use the %i specifiers to point to the relevant config files

Something like (incomplete because I don't know haproxy:

[Unit]
Description=haproxy %i

[Service]
ExecStart=/usr/local/sbin/haproxy-systemd-wrapper -f /etc/haproxy%i.conf -p /var/run/haproxy%i.pid

Then you can enable any haproxy instance with

systemctl enable haproxy@X

Where X is the number of the instance (and matching config file).

And if the instances are related you can look at my question and answer: How to start and stop a listener service together with a custom service

Improve this answer
  • I was hoping to avoid this option, the simple reason is that if someone else comes along to manage the system, its something that could be easily forgotten, a colleague recommended sticking a message in motd. These are the only two instances needed, so templating won't be needed, but cool to know. – Aftab Oct 30 '15 at 21:11
  • In my opinion the only way to prevent this from being forgotten is to ensure you have good documentation. You wrote that both services are independent so making them dependent is likely going to cause problems at some point. Or even just confusion. You could do it with the method I described in the question I linked to but I'd recommend against it in this case. Maybe it's even better to create two copies of the original haproxy unit and give them clearly descriptive names. – Bram Oct 31 '15 at 9:54
  • I've used a second unit file, I think its certainly the simplest option, agree documentation is critical. – Aftab Nov 1 '15 at 16:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.