On 22/09/17 23:25, Gert Doering wrote:
> Hi,
>
> On Thu, Sep 07, 2017 at 03:16:45PM +0200, David Sommerseth wrote:
>> So the RestartForceExitStatus/RestartPreventExitStatus is not going to
>> be helpful if all graceful errors results in 1, which is the most common
>> way OpenVPN stops - through th
Hi,
On Thu, Sep 07, 2017 at 03:16:45PM +0200, David Sommerseth wrote:
> So the RestartForceExitStatus/RestartPreventExitStatus is not going to
> be helpful if all graceful errors results in 1, which is the most common
> way OpenVPN stops - through the M_FATAL. So that leaves us with
> SIGSEGV, SI
Hi,
On Fri, Sep 08, 2017 at 01:41:15AM +0100, fragmentux wrote:
> WRT systemd and 3rd party 'servers'
>
> I am curious to know of any other "Server service" who decide ..
> to *rely* on ..
> a *forced* 'systemd (almost) unconditional restart by default'
Some software provides their own wrapper s
Hi,
On Thu, Sep 07, 2017 at 10:02:08PM +0100, fragmentux wrote:
> all your comment are totally valid from a sys-admin point of view but
> from an openvpn POV, the only responsibility is to provide a secure VPN.
Uh, no. Part of our responsibility is also to provide a reasonably good
experience to
On 08/09/17 02:45, fragmentux wrote:
Hi,
On 08/09/17 02:30, Steven Haigh wrote:
On 2017-09-08 10:41, fragmentux wrote:
WRT systemd and 3rd party 'servers'
I am curious to know of any other "Server service" who decide ..
to *rely* on ..
a *forced* 'systemd (almost) unconditional restart by d
Hi,
On 08/09/17 02:30, Steven Haigh wrote:
On 2017-09-08 10:41, fragmentux wrote:
WRT systemd and 3rd party 'servers'
I am curious to know of any other "Server service" who decide ..
to *rely* on ..
a *forced* 'systemd (almost) unconditional restart by default'
As a basic list:
/usr/lib/sys
On 2017-09-08 10:41, fragmentux wrote:
WRT systemd and 3rd party 'servers'
I am curious to know of any other "Server service" who decide ..
to *rely* on ..
a *forced* 'systemd (almost) unconditional restart by default'
As a basic list:
/usr/lib/systemd/system $ grep -r Restart *.service
autov
WRT systemd and 3rd party 'servers'
I am curious to know of any other "Server service" who decide ..
to *rely* on ..
a *forced* 'systemd (almost) unconditional restart by default'
Regards,
--
Check out the vibrant tech
Hi,
On 07/09/17 23:55, David Sommerseth wrote:
On 07/09/17 23:02, fragmentux wrote:
i,
all your comment are totally valid from a sys-admin point of view but
from an openvpn POV, the only responsibility is to provide a secure VPN.
Use all of systemd's functions to maximize openvpn's process *s
On 07/09/17 23:02, fragmentux wrote:
i,
>
> all your comment are totally valid from a sys-admin point of view but
> from an openvpn POV, the only responsibility is to provide a secure VPN.
>
> Use all of systemd's functions to maximize openvpn's process *security*
> But *forcing* restart as an al
Hi,
all your comment are totally valid from a sys-admin point of view but
from an openvpn POV, the only responsibility is to provide a secure VPN.
Use all of systemd's functions to maximize openvpn's process *security*
But *forcing* restart as an almost unconditional default is nonsense.
How wou
On 07/09/17 17:08, fragmentux wrote:
> Hi,
>
> On 07/09/17 00:52, David Sommerseth wrote:
>> Systemd supervises services it has started and can act upon unexpected
>> scenarios. This change will restart OpenVPN after 5 seconds if the
>> OpenVPN
>> process exits unexpectedly.
>
> Define "unexpect
Hi,
On 07/09/17 00:52, David Sommerseth wrote:
Systemd supervises services it has started and can act upon unexpected
scenarios. This change will restart OpenVPN after 5 seconds if the OpenVPN
process exits unexpectedly.
Define "unexpectedly"
(my2c: something needs to be fixed)
The on-failu
On 07/09/17 08:16, Gert Doering wrote:
>
> 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...
Oh, I overlooked this one. Just one comment in regards to the "filling
On 07/09/2017 16:00, David Sommerseth wrote:
> 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 @@ DeviceAll
On 07/09/17 14:17, Samuli Seppänen wrote:
> On 07/09/2017 11:13, Gert Doering wrote:
>> Hi,
>>
>> On Thu, Sep 07, 2017 at 11:04:01AM +0300, Samuli Seppänen wrote:
>>> "Note that units which are configured for Restart= and which reach the
>>> start limit are not attempted to be restarted anymore; ho
On 07/09/17 15:07, Gert Doering wrote:
> Hi,
>
> On Thu, Sep 07, 2017 at 03:02:20PM +0200, David Sommerseth wrote:
>>> Which is not what I hoped for... "turn it off and leave it so" is non
>>> helpful (it might be a transient error preventing the startup).
>>
>> I'm confused. What is it you want?
Hi,
On Thu, Sep 07, 2017 at 03:02:20PM +0200, David Sommerseth wrote:
> > Which is not what I hoped for... "turn it off and leave it so" is non
> > helpful (it might be a transient error preventing the startup).
>
> I'm confused. What is it you want?
>
> * try restarting in an endless loop?
> *
On 07/09/17 10:13, Gert Doering wrote:
> Hi,
>
> On Thu, Sep 07, 2017 at 11:04:01AM +0300, Samuli Seppänen wrote:
>> "Note that units which are configured for Restart= and which reach the
>> start limit are not attempted to be restarted anymore; however, they may
>> still be restarted manually at
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
Pro
On 07/09/2017 11:13, Gert Doering wrote:
> Hi,
>
> On Thu, Sep 07, 2017 at 11:04:01AM +0300, Samuli Seppänen wrote:
>> "Note that units which are configured for Restart= and which reach the
>> start limit are not attempted to be restarted anymore; however, they may
>> still be restarted manually a
Hi,
On Thu, Sep 07, 2017 at 11:04:01AM +0300, Samuli Seppänen wrote:
> "Note that units which are configured for Restart= and which reach the
> start limit are not attempted to be restarted anymore; however, they may
> still be restarted manually at a later point, from which point on, the
> restar
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
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
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
Systemd supervises services it has started and can act upon unexpected
scenarios. This change will restart OpenVPN after 5 seconds if the OpenVPN
process exits unexpectedly.
The on-failure mode is the recommended mode by upstream systemd.
This change have been tested on a test server for some mo
26 matches
Mail list logo
