Repository navigation
haproxy 3.1.0 fails to fully start #395
Description
Activity
Are you able to share any non-sensitive parts of your config? At least with a basic proxy setup 3.1.0 works ok for me, so I wonder if this is due to specific features.
Interesting. Unfortunately my test install is also my production install so I don't have a good way to generate a minimum test case right now.
I think the secrets are all out of the attached full config. I should extract a promise not to laugh... :)
haproxy.cfg.txtSorry I missed your question for so long.
- added a commit that references this issue
on Jan 5, 2025 Stupid stupid GitHub autoclose.
- added 2 commits that reference this issue
on Jan 28, 2025 - added a commit that references this issue
on Feb 9, 2025 I present to you, minimum broken configuration:
global master-worker frontend test bind :8080 timeout client 60sand minimum functioning configuration
frontend test bind :8080 timeout client 60sPlease note the minimum broken configuration will leave haproxy master processes running that are difficult to kill off. Even after a
svcadm disablethere will still be several haproxy processes not making forward progress.[root@a4dbe587-830b-4502-8a99-882d25c578b0 ~]# svcs | grep haproxy [root@a4dbe587-830b-4502-8a99-882d25c578b0 ~]# ptree 470279 /sbin/init 470315 /lib/svc/bin/svc.startd 472096 /usr/lib/saf/sac -t 300 472119 /usr/lib/saf/ttymon 472141 /usr/lib/saf/ttymon -g -d /dev/console -l console -m ldterm,ttcompat -h -p a4db 473268 /opt/local/sbin/haproxy -f /opt/local/etc/haproxy.cfg -D 473269 /opt/local/sbin/haproxy -f /opt/local/etc/haproxy.cfg -D 473270 /opt/local/sbin/haproxy -f /opt/local/etc/haproxy.cfg -DI suspect, but do not know, that some of the operations described in https://docs.haproxy.org/3.2/management.html#4 work differently on illumos, and are likely tripping it up in master-worker mode.
I've narrowed it down to this change.
I've found the issue and raised it upstream in the above. I'll apply a patch to pkgsrc in the meantime to get you guys unblocked.
149 remaining items
- added 3 commits that reference this issue
on May 14, 2026 - added a commit that references this issue
on May 20, 2026 - added 7 commits that reference this issue
on May 22, 2026 - added 2 commits that reference this issue
on Jun 1, 2026 - added a commit that references this issue
on Jun 23, 2026 - added a commit that references this issue
on Jul 27, 2026
Our haproxy guest got updated to haproxy-3.1.0 this morning. After an extended period of searching, I realized that none of the listen ports were actually in use. Some fiddling with
truss -fseems to show that the master process starts its first worker, which never really makes any progress, and there's just no further truss output. There's a message "Failed to load worker".Falling back to 3.0.6 has us back on the air for now.
Platform 20241017T041739Z.
Apologies for the crappy bug report.