On Tue, Feb 04, 2014 at 10:41:57PM -0800, Tyler Stobbe wrote: > 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.
Note that this became a problem since those crappy "service managers" tried to replace what has been working on all unix systems for 40 years. > 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. That's exactly what you get with the provided systemd wrapper, so I suspect you're not using it maybe. > 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. s/modern/of-the-day :-) One feature we lose with such methods is the ability to perform process upgrades because in your sequence, it's the same process that forks itself. So upgrades require a service outage. Our reload system allows you to seamlessly upgrade the daemon, and this is used a lot. Most very large deployments I know have totally automatized this and that's both efficient and reliable. That said, with the systemd wrapper, you have the best of both worlds, systemd works and the wrapper really execs the haproxy binary, either itself or a hard-coded path for now, so you can remove the binary and put the new one instead and have it upgraded (using symlinks would be more efficient). Regards, Willy
