want to write a systemd service file where a user may not exist.

[Oliver Grawert]

hi,
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>
> wrote:
> > 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*.

http://0pointer.de/blog/projects/on-etc-sysinit.html

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
all.

> 
> 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)

also a:
grep default /lib/systemd/system/*
might be interesting ...

ciao
	oli
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20170211/03bcb0a6/attachment.sig>