3

I have a CentOS 7.4 installation with haproxy which I updated to 1.8. Haproxy fails to start, even sudo systemctl start haproxy doesn't show any output.

sudo systemctl status haproxy displays this:

● haproxy.service - HAProxy Load Balancer
   Loaded: loaded (/usr/lib/systemd/system/haproxy.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Wed 2018-01-31 15:17:37 CET; 2s ago
  Process: 2807 ExecStart=/usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid $OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 2807 (code=exited, status=0/SUCCESS)

Jan 31 15:17:36 foo systemd[1]: Started HAProxy Load Balancer.
Jan 31 15:17:36 foo systemd[1]: Starting HAProxy Load Balancer...
Jan 31 15:17:37 foo haproxy-systemd-wrapper[2807]: haproxy-systemd-wrapper: executing /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -d -Ds
Jan 31 15:17:37 foo haproxy-systemd-wrapper[2807]: haproxy-systemd-wrapper: exit, haproxy RC=0

The logs don't yield much helpful information:

Jan 31 15:19:43 foo systemd[1]: Started HAProxy Load Balancer.
-- Subject: Unit haproxy.service has finished start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit haproxy.service has finished starting up.
--
-- The start-up result is done.
Jan 31 15:19:43 awisot3 systemd[1]: Starting HAProxy Load Balancer...
-- Subject: Unit haproxy.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit haproxy.service has begun starting up.

When I try to simulate what systemd does and execute a sudo -u haproxy usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -d -Ds I get this error message:

[WARNING] 030/152521 (3031) : [/usr/sbin/haproxy.main()] Cannot raise FD limit to 8015, limit is 4096.
[ALERT] 030/152521 (3031) : [/usr/sbin/haproxy.main()] Cannot create pidfile /run/haproxy.pid

How do I properly set up access to haproxy.pid and /run ? Bonus question: why doesn't journalctl disclose this information too ?

Marged
  • 691
  • 2
  • 10
  • 21
  • `sudo -u` expects a username, which you don't supply? However `haproxy` is started as root, and drops to the user specified in `haproxy.cfg` after opening all relevant files and sockets. – wurtel Jan 31 '18 at 15:19
  • I just became a victim of copy & paste, the user `haproxy` was specified when running `sudo`. It looks like that user is unable to access the file (`-rw-r--r-- 1 root root 5 Jan 31 16:25 haproxy.pid`) or directory (`drwxr-xr-x 40 root root 1280 Jan 31 15:25 run`) – Marged Jan 31 '18 at 15:23
  • @Marged As for your bonus question, I expect `journalctl -u haproxy` would show the messages. `systemctl status` probably isn't showing the messages because there's neither a running, nor failed instance (not failed because it exited with success code '0', which means the service doesn't send good return codes) – Centimane Jan 31 '18 at 15:34
  • Don't use sudo to start haproxy, it *needs* to be started as root and will change to the user specified in the config after opening files and such, as I already commented. – wurtel Jan 31 '18 at 15:36
  • @wurtel I just used sudo to simulate running AS the user haproxy because when systemd did this I saw no errors at all – Marged Jan 31 '18 at 15:51
  • Yes, and THAT is why haproxy then can't create the pidfile. Run it as root! – wurtel Feb 01 '18 at 07:31
  • @wurtel OK, now I understand. SystemD initially runs haproxy as root, because of this the pid file is created. After that the process itself is "switched" to the haproxy user. So my attempt to simulate systemd using sudo was false and only showed a different problem. But what remains: systemd is unable to bring up haproxy and even the suggestion of centimane does yield no information why haproxy fails to start when run by systemd. – Marged Feb 01 '18 at 07:51
  • @Centimane Unfortunately the process still doesn't run and journalctl still shows nothing meaningful – Marged Feb 01 '18 at 07:51

0 Answers0