On Sa, 05.09.20 18:46, Richard Hector (rich...@walnut.gen.nz) wrote:
> Hi all,
>
> Quoting from another thread:
>
> On 5/09/20 4:36 am, Lennart Poettering wrote:
> > Unit instances can be activated on-the-fly without further prepartion
> > or regsitration of the instance string or so. it's suffici
On Sat, Sep 5, 2020 at 9:50 AM Michael Chapman wrote:
> Since the instance name for this unit is used to derive a configuration
> filename, a simple solution here would be to use:
>
> ConditionPathExists=/etc/openvpn/client/%i.conf
>
> in the unit. Or, if you want the start job to fail when gi
On Sat, 5 Sep 2020, Richard Hector wrote:
> Hi all,
>
> Quoting from another thread:
>
> On 5/09/20 4:36 am, Lennart Poettering wrote:
> > Unit instances can be activated on-the-fly without further prepartion
> > or regsitration of the instance string or so. it's sufficient if the
> > template un
On 05/09/2020 13:18, Kevin P. Fleming wrote:
> It's a general issue with templated unit files; I've had this happen
> as well, and could not figure out why the service had failed to start.
> It was because I had mistyped the instance name. As best I can tell
> systemd doesn't have any mechanism to
It's a general issue with templated unit files; I've had this happen
as well, and could not figure out why the service had failed to start.
It was because I had mistyped the instance name. As best I can tell
systemd doesn't have any mechanism to restrict the instance names
which can be used for a s
Hi all,
Quoting from another thread:
On 5/09/20 4:36 am, Lennart Poettering wrote:
> Unit instances can be activated on-the-fly without further prepartion
> or regsitration of the instance string or so. it's sufficient if the
> template unit exists.
Is that preventable?
I have some instance nam