Hi Pavlos, On Tue, Oct 25, 2016 at 10:34:14AM +0200, Pavlos Parissis wrote: > Well, I have full confidence on the quality of your code
You should not, keep in mind that I still hold and by far the record on the number of bugs in this project :-) > (assuming you will > polish the patch to handle errors as you mentioned :-) ) and I am willing to > test it on our environment when arrives on HAPEE. OK but anyway I don't intend to backport it until it's confirmed as OK by those who currently face problems. There may be other stupid issues I have no clue about when using systemd. > But, we will never hit the > conditions which triggers this behavior as our configuration tool for haproxy > doesn't allow to reload very often, we allow 1 reload per min (this is > configurable of course). We did that in order to address also the case of too > many live processes for a cluster of haproxies which has a lot of long-lived > TCP > connections [1]. I think that's reasonable. I've also seen other methods in the past which I found were pretty efficient, especially in websocket environments : the principle was to gracefully shut down the previous process and kill the oldest ones (or just keep a certain number). Of course there can be variations, but all of these methods try to address the same issues. > > I'm really open to suggestions. I absolutely despise systemd and each time > > I have to work on the wrapper I feel like I'm going to throw up. So for me > > working on this crap is a huge pain each time. But I'm really fed up with > > seeing people having problems in this crazy environment because one clueless > > guy decided that he knew better than all others how a daemon should reload, > > so whatever we can do to make our users' lifes easier in captivity should > > at least be considered. > > > > Have you considered to report this to systemd? May be they have a solution, I > don't know. It's impossible to report any single bug to them. Everytime it's someone else doing something wrong because *they* are right. I reported a machine getting dead at boot due to a dead RTC battery and this stupid systemd spinning in loops on the time. I was told it was a kernel bug. The kernel bug is not being able to store a date prior to 1970 on a 32-bit time_t... I even proposed a patch to address the issue, it was rejected to put pressure on the kernel. In the end another workaround was found in the kernel to address this crap. So the systemd team just wants to adapt operating systems to their vision of what an OS should be, and they use us (the users) to put pressure on other ones. BTW it's how we ended up having this systemd-wrapper ourselves. We should have called it "die-crappy-systemd" instead... > To sum up, go ahead with the patch as it addresses real problems of users and > you can count on me testing HAPEE in our environment. Thank you! I'm waiting for Pierre's testing to confirm he cannot kill it either anymore. Willy
