Hi Sander, On Wed, Dec 04, 2024 at 06:39:31PM +0000, Sander Klein wrote: > Hi William, > > ofcourse, please see below. The line causing it not to start is the > ExecStartPre line. But like I said, I don't know where this unit file came > from. Either a collegue or I created this override, can't remember. > > --- > [Unit] > Description=HAProxy Load Balancer > Documentation=man:haproxy(1) > Documentation=file:/usr/share/doc/haproxy/configuration.txt.gz > After=network-online.target rsyslog.service > Wants=network-online.target > > [Service] > EnvironmentFile=-/etc/default/haproxy > EnvironmentFile=-/etc/sysconfig/haproxy > Environment="CONFIG=/etc/haproxy/haproxy.cfg" "PIDFILE=/run/haproxy.pid" > "EXTRAOPTS=-S /run/haproxy-master.sock" > ExecStartPre=/usr/sbin/haproxy -f $CONFIG -c -q $EXTRAOPTS > ExecStart=/usr/sbin/haproxy -Ws -f $CONFIG -p $PIDFILE $EXTRAOPTS > ExecReload=/usr/sbin/haproxy -f $CONFIG -c -q $EXTRAOPTS > ExecReload=/bin/kill -USR2 $MAINPID > KillMode=mixed > Restart=always > SuccessExitStatus=143 > Type=notify > > # The following lines leverage SystemD's sandboxing options to provide > # defense in depth protection at the expense of restricting some flexibility > # in your setup (e.g. placement of your configuration files) or possibly > # reduced performance. See systemd.service(5) and systemd.exec(5) for further > # information. > > # NoNewPrivileges=true > # ProtectHome=true > # If you want to use 'ProtectSystem=strict' you should whitelist the PIDFILE, > # any state files and any other files written using 'ReadWritePaths' or > # 'RuntimeDirectory'. > # ProtectSystem=true > # ProtectKernelTunables=true > # ProtectKernelModules=true > # ProtectControlGroups=true > # If your SystemD version supports them, you can add: @reboot, @swap, @sync > # SystemCallFilter=~@cpu-emulation @keyring @module @obsolete @raw-io > > [Install] > WantedBy=multi-user.target > ---
Thanks. FWIW there was an issue with "-c" combined with -D or "daemon" in the config, which were resolved yesterday in 3.2-dev. We're going to backport that to 3.1 ASAP. In short, the fork() was unconditional and would possibly make the check with "-c" return immediately with no error, the validation continue in background and possibly even collide with the running process. Also, to add to the difficulty, the pidfile was always overwritten by -c. If you think you can give a quick test to 3.2-dev from the git repo, it could be helpful to know if it's now fully OK (at least it looks so on our side) or if there's still a corner case. As with all early -dev versions, it's still considered quite safe since no significant changes were brought to it yet (and contains all known fixes). If you can't, no worries. Thanks! Willy
