want to write a systemd service file where a user may not exist.
ogra at ubuntu.com
Sat Feb 11 15:31:50 UTC 2017
On Sa, 2017-02-11 at 08:38 -0500, Peter Silva wrote:
> On Sat, Feb 11, 2017 at 7:41 AM, Oliver Grawert <ogra at ubuntu.com>
> > hi,
> > On Fr, 2017-02-10 at 09:04 -0500, Peter Silva wrote:
> > >
> > > Hi folks, wondering if people could direct me to a good place to
> > ask
> > > this question. It isn't really a user question, but ... anyways.
> > I
> > > work on a package that can run either under a dedicated user, as
> > a
> > > sort of daemon or server mode, or it can be used by ordinary
> > users
> > > directly in client mode (connecting to daemons elsewhere.)
> > >
> > there are plenty of ways to achieve that :)
> > > When I install the package, on older releases, there is
> > /etc/default
> > > and I put a file there to ensure it is disabled by default.
> > That's
> > > fine.
> > you could use a wrapper script for starting your daemon that first
> > checks /etc/default ...
> It is a practical suggestion and should work, but I wonder if the
> systemd gods somewhere will say *You're doing it wrong*.
recommends to use /etc/default/ or (for fedora) /etc/sysconfig/ through
the EnvironmentFile= option in your service file (but that indeed
requires that your daemon uses the env vars from there internally)
> Reading through systemd information, and through bitter experience, I
> know most systemd services completely ignore /etc/default, so it
> would be *surprising* for admins on a systemd system if one service
> was actually using them:
> As far as I can tell /etc/default is only supposed to be used by
> upstart or init files, and can be referenced as a crutch by systemd,
> but it isn't correct to build a systemd service that uses it.
no, /etc/default is not directly tied to the init system, it is
actually for setting package defaults :)
just take a look at your current /etc/default on a xenial or later
install, there are still plenty of packages using it even with systemd
as the default init system.
> On the subject of a wrapper script... The obvious thing is to just
> point at the /etc/init script I already provide, but then it feels
> like I'm not doing it the *systemd* way. I end up with systemd stuff
> that explicitly invokes sysv stuff.
> example of surprise:
> systemctl enable foo
> won't work, as people will need to modify /etc/default/foo as well as
> enable, and folks will complain that it isn't properly in systemd.
well, yes, indeed ... i meant the suggestion as an either/or thing ..
use a wrapper startup script that reacts to /etc/default variables and
keep the debhelper unit management, or ship a unit without starting it
by default via the debian/install file and do not use /etc/default at
> Some to think of it, I think I could just skip the systemd.service
> entirely then, and systemd's compatibility stuff could just pick up
> the init stuff. Still ugly.
> So I'm looking for the systemd-ish way to do it right.
well, just look at other packages that have an /etc/default file ...
there are plenty of them, even in systemd times (only a few, like
apport for example, use it to en/disable ... fun fact: apport was
developed by ubuntus systemd maintainer)
grep default /lib/systemd/system/*
might be interesting ...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: This is a digitally signed message part
More information about the ubuntu-users