On Wed, May 30, 2018 at 07:57:03PM +0200, Tim Düsterhus wrote: > William, > > Am 30.05.2018 um 19:45 schrieb William Lallemand: > >> @William Lallemand Possibly the sd_notifyf should be moved below > >> mworker_unblock_signals in mworker_wait? > >> > > > > This shouldn't happen with or without systemd. I can reproduce it without > > using systemd, we should not rely on an external component to mitigate the > > problem. > > Yes, I agree. But I believe that readiness should be signaled as late as > possible to ensure that everything is set-up correctly. So the > `sd_notifyf` should be moved down below the signal registering, no? Even > if it does not fix this issue it is technically incorrect. >
Even there it's technically incorrect in fact, readiness should be notified once all workers are ready and it's not possible to do this right now. When the signals are blocked they are stored within the signal queue in order to be transmitted once they are unblocked, so that does not change a lot if it's before or after the unblock. Even if we send the reload signal just before the unblocking, it will still work. > The ideal case would be the workers signaling their status to the master > (which in turn signals to SystemD). Is this part of your current work on > master-worker Willy announced in his 1.9 mail? Better than that, the whole idea started from the need of synchronous reloading that don't rely on signals anymore. The current problems with the signal method: - kill -USR2 is asynchronous and can't return an error code - sd_notify can't signal an error during a reload, which is a big problem - we use haproxy -c as a hack to stop the reloading if the new config is wrong - haproxy can fail even if the config was right during the check - we load the configuration twice because of the -c, which is not convenient for people having a heavy configuration to load. > Personally I'd like to see that workers are able to send information like > the number of requests handled to the master to be able to display them in > SystemD [1] > I thought about it too, but people tends to rely on statistics usually. I already have in mind how to do that kind of things but I can't say it will be there, it will depends on how much time I spend on the other features :) -- William Lallemand
