On 07/09/17 10:04, Samuli Seppänen wrote: > On 07/09/2017 10:16, Samuli Seppänen wrote: >> On 07/09/2017 09:16, Gert Doering wrote: >>> Hi, >>> >>> On Thu, Sep 07, 2017 at 01:52:02AM +0200, David Sommerseth wrote: >>>> @@ -18,6 +18,8 @@ DeviceAllow=/dev/net/tun rw >>>> ProtectSystem=true >>>> ProtectHome=true >>>> KillMode=process >>>> +RestartSec=5s >>>> +Restart=on-failure >>> >>> Is there a way to get exponential backoff on restart? >>> >>> Restarting is good, but if there is something faulty that leads to >>> "the process always dies right away", this can lead to very quickly >>> filling disks with not-so-useful logging... >>> >>> (Otherwise, yes, restarting is good :-) ) >>> >> >> Hi, >> >> From systemd.unit man-page[1]: >> >> StartLimitIntervalSec=, StartLimitBurst= >> >> Configure unit start rate limiting. By default, units which are >> started more than 5 times within 10 seconds are not permitted to >> start any more times until the 10 second interval ends. >> >> I verified this behavior on CentOS 7 using another daemon (monit) by >> setting "Restart=on-failure" for it, breaking its config file and >> forcibly killing it. Note that RestartSec is the default, i.e. 100ms: >> >> --- >> >> Sep 07 09:55:37 centos-7 systemd[1]: monit.service: control process >> exited, code=exited status=1 >> >> Sep 07 09:55:37 centos-7 systemd[1]: Unit monit.service entered failed >> state. >> >> Sep 07 09:55:37 centos-7 systemd[1]: monit.service holdoff time over, >> scheduling restart. >> >> Sep 07 09:55:37 centos-7 systemd[1]: Stopping Pro-active monitoring >> utility for unix systems... >> >> Sep 07 09:55:37 centos-7 systemd[1]: Starting Pro-active monitoring >> utility for unix systems... >> >> Sep 07 09:55:37 centos-7 systemd[1]: monit.service start request >> repeated too quickly, refusing to start. >> >> Sep 07 09:55:37 centos-7 systemd[1]: Failed to start Pro-active >> monitoring utility for unix systems. >> >> Sep 07 09:55:37 centos-7 systemd[1]: Unit monit.service entered failed >> state. >> >> --- >> >> As you can see, systemd quickly realizes that monit will not come back >> up and stops trying. >> >> However, when I added "RestartSec=5s" the StartLimit* thresholds were >> never triggered. This meant that systemd never ceased trying to restart >> the monit service. >> >> David: any particular reason why you added RestartSec? Why not just let >> it be the default (100ms)?
Partly to avoid respawning too fast. We don't know what kind of additional plug-ins or management interface tools have been integrated and how they react if OpenVPN goes into a tight restart-loop. And partly to _escape_ the stopping of restarts. I'm not sure I'm easily buying into the "faulty configuration" argument. Because these restart scenarios mostly happens when a sys-admin is _not_ around. If you're playing with configurations, do a restart to test the new config, you are around to handle a failed situation. The only area where this can fail is when we break options and OpenVPN get updated automatically. But in both these scenarios, a restart delay of 5 seconds won't cause too much stress on the system. I also opted for not much longer delay, as if a restart happens successfully, most users won't notice that too much. If it is 30 seconds or 1 minute, that is much more noticeable. But I'm open for adjusting this too. -- kind regards, David Sommerseth OpenVPN Technologies, Inc
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
