A User's perspective: We run OpenVPN on some 2500 systems in a (unmanned) client-server config (we're the ones hoping to someday see Gava's client-nat and ftp-nat patches included). Long ago we came up with a brute force workaround to the service restart issue -- a script that pings back to a node behind our server, if no reply then restart service. Not pretty, but it has worked for us over many years. I'm happy to see the issue being addressed now within the source for the new versions.
>>what is a reasonable delay? Our experience says 3 minutes. >>under which conditions should systemd restart the server? Our votes: >>- on-failure? Yes. >>- on-abnormal? Yes. >>- on-abort? Yes. >>- always? I am of the opinion that this IS workable, at least in our scenario (unmanned clients). For us, the most common reason for connection failure is some network change or blockage at the remote site -- but it is not always so. For us, having it continue to retry is important for troubleshooting, even if it is our fault because we did something stupid such as configuration errors (e.g. typos in the .ovpn etc.) Hope this helps, Marvin Adeff On Mon, Nov 14, 2016 at 2:44 AM, David Sommerseth < [email protected]> wrote: > On 12/11/16 16:00, Gert Doering wrote: > > Hi, > > > > On Fri, Nov 11, 2016 at 01:35:57PM +0100, David Sommerseth wrote: > >> We can of course investigate if we should enable systemd to restart > >> OpenVPN, at least the server profile, if it dies unexpectedly. > >> Currently, I am not fully convinced we want that. > > > > I think this would be useful to have. Server processes are expected to > > be there - if they are not, it needs to be investigated why not, but > > with some reasonable delay, they should be restarted. > > Let's take the easiest part first ... what is a reasonable delay? > RestartSec= defines how long systemd should wait before restarting the > service. Default is 100ms. Would 30 seconds, 1 minute, 5 minutes, 15 > minutes or 1 hour be a reasonable delay? Or another value? I honestly > don't know. > > > So to the slightly harder part ... under which conditions should systemd > restart the server? The Restart= setting can have a few alternatives. > > - on-success? Only when openvpn exits with exit code 0. Probably not. > > - on-failure? When openvpn exits with exit code != 0 or "unclean" > exit signals. [1] Probably. > > - on-abnormal? When openvpn is killed by a signal, a timeout event or > watchdog timeout event happens. [1] Perhaps. > > - on-abort? Only when an uncaught signal not considered as a "clean > exit" occurs. Perhaps. > > - on-watchdog? Only when a watchdog timeout occurs. Most likely not. > > - always? Whenever OpenVPN stops running regardless of reason > why it stopped, it will be restarted. Most likely not > what we want. > > - no? This is the default, which we already have. > > And you can only choose one of these alternatives. > > In regards to those triggers including a watchdog, that needs the > OpenVPN process to signal to the systemd daemon that it will provide a > watchdog signal. So unless we add that in our OpenVPN code, watchdog is > not relevant for us. > > The systemd.service man page [2] recommends: > > Setting this to on-failure is the recommended > choice for long-running services, in order to > increase reliability by attempting automatic > recovery from errors. For services that shall > be able to terminate on their own choice (and > avoid immediate restarting), on-abnormal is an > alternative choice. > > [1] Also includes terminated by signal, including core dump but excludes > SIGHUP, SIGINT, SIGTERM adn SIGPIPE (those four signals are > considered clean exits) > > [2] > <https://www.freedesktop.org/software/systemd/man/systemd. > service.html#Restart=> > > > > (I thought this was what systemd was all about? "Because sysvinit cannot > > restart stuff!" - which was never true, but standard rc.d scripts do not > > support it) > > Flame bait? ;-) > > I don't know exactly why this isn't enabled by default, but there are > probably plenty of reasons. One could be that because the vast majority > of rc.d scripts don't do this, so it would be a very unexpected change > for very many services and/or sys-admins. As you see from above, the > feature is easily available, fairly flexible and it is far easier to > enable it than adding extra code to an rc.d script. > > For the "this was what systemd was all about?" ... not just this, but it > is one area of all the stuff systemd wants to improve or simplify. > > > -- > kind regards, > > David Sommerseth > OpenVPN Technologies, Inc > > > > ------------------------------------------------------------ > ------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > Openvpn-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > >
------------------------------------------------------------------------------
_______________________________________________ Openvpn-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openvpn-devel
