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

[Peter Silva]

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

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.

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.

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.

etc...

>
> > in systemd, I use the documented stuff in dh_ and it puts the service
> > file in the right place.
>
> you could not use debhelper (which is responsible for enabling the
> service by default) but just install the service file to
> /lib/systemd/system/ from the debian/install file, not using the
> debhelper functions ...
>
> then it should not be started by default and you have to manually do
> "systemctl enable <service>"
>
>
OK, but I'm using debuild, and the packages get built by launchpad, for me
to stick a raw 'cp' in there, especially when installing on 14.04 (no
systemd) seems likely to break somewhere.




> >
> > Two issues:
> >     -- when I do systemctl status sarra ... it says: 'vendor preset:
> > enabled')  I want it to be disabled by default.  Couldn't find that.
> >
> >     -- I don't want to create the daemon user on systems where
> >  it will only be used as a client, so in many cases the 'user'
> > specified in the service file will not exist.   How to cleanly handle
> > that?
> >
> you would use a debconf question asking the admin if he wants the user
> created ...
>
>
hmm... need to think about that... when installations are automated people
are stuck specifying default answers... I would think If I'm going to ask a
question it would be something like:

'client only mode (no server, no sarra user created)?'

so *no* would ensure the user exists... (the less common case) and *yes*
would be the normal client mode...   (the most common case)   Does that
sound correct?


thanks for the suggestions! not sure we're there yet...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20170211/c911503b/attachment.html>