HAProxy is quite nice, don't get me wrong in all of this, but I have a very basic change request that would bring it more in line with the modern era...
The problem stems from the fact that, the way the daemon works now, a "reload" request dumps the initial process group completely, which is entirely antithetical to how daemons have traditionally worked. This has led to fedora shipping with completely broken systemd service files and, I wouldn't be surprised if upstart services are non-working as well. The current HAProxy daemonization process: 1. Launch, fork, all the standard daemon things 2. Do your stuff 3. Someone runs haproxy with -sf (a completely different process group) 4. Agree, soft-shutdown, and exit after the other process group says, "Good to go" 5. Profit? No. Because haproxy is gone as far as any service manager is concerned. Indeed, in this scenario, an entirely new process group was started, without any oversight from anyone, and other process group is dead. Not so good. I would like to see the following instead (very standard practice): 1. Launch, fork, all the standard daemon things 2. On SIGUSR2 (frequently this is SIGHUP, but I read your docs and that's in use), fork a "fresh" process that reads the config. 3. Just before the sub-process starts binding listening ports report to the parent, "Okay, I'm going to listen now, please stop listening" 4. The parent then shuts down listening sockets (but not active connections) and starts a "graceful" shutdown process. 5. The new child (soon to be main/only process in the group) listens and continues on as a normal "main" process would. 6. Rinse and repeat as necessary. This, not only being the traditional way to do things (HAProxy was the first I came across that does it completely the opposite) solves tons of issues with modern service managers and process control in general. Let me know your thoughts. Once again, HAProxy is quite nice. Tyler Stobbe Online Technology Leader The Sacramento Bee
