Starting systemd user services on boot on a Debian server

[Fredrik Jonson]

Hi,

What is the recommended way to set up Systemd user services with Debian?

With previous Debian releases I've been running services like tomcat from
regular user accounts by creating wrapper scripts that controls the PATH and
environment variables, and start those scripts with @reboot from the user's
crontab.

While this works ok, I find that the scripts are hard to maintan and does not
meet all requirements of service managment. It would be nice to migrate
away from my fragile scripts to something that's dedicated to controlling
services, like Systemd units.

AFAIU, to make this happen, I need to have a user Systemd instance started on
boot. How do I set up my Debian server to automatically start a user instance
for a regular user on boot to control the user's service units? Is there a
recommended way to do it?

BTW, if I just try to start systemd from the console, it fails:

$ systemd --user
Trying to run as user instance, but $XDG_RUNTIME_DIR is not set.

Clearly that is not the way to do it. Any advice?

--
Fredrik Jonson

[Ansgar Burchardt]

Fredrik Jonson <fre...@jonson.org> writes:
> What is the recommended way to set up Systemd user services with Debian?

[...]

> AFAIU, to make this happen, I need to have a user Systemd instance started on
> boot. How do I set up my Debian server to automatically start a user instance
> for a regular user on boot to control the user's service units? Is there a
> recommended way to do it?

Just run

loginctl enable-linger [USER...]

as root. This will make logind start the systemd user instance for the
given user(s).

Ansgar

[Fredrik Jonson]

Ansgar Burchardt wrote:
> Fredrik Jonson <fre...@jonson.org> writes:
> > What is the recommended way to set up Systemd user services with Debian?
>

> Just run 'loginctl enable-linger [USER]' as root.

Initially that didn't work...

root@host# loginctl enable-linger foouser
Failed to create bus connection: No such file or directory

A quick google seems to indicate[0][1] that it is related to dbus somehow.
I checked, and the server didn't have dbus installed on the machine, so I
installed it (apt-get install dbus) and reran the command:

root@host# loginctl enable-linger foouser

This time the command ran without any apparent objections from the system.

Next, I create my unit in $HOME/.config/systemd/user/foo.service but
systemctl fails to enable it:

foouser@host$ systemctl --user enable foo.service
Failed to get D-Bus connection: Connection refused

Now what?

I notice that there isn't a systemd or dbus instance running under the user.
Should there be, and if, what's responsible for starting it?

Additionally, when I try to start a user instance manually, it fails:

foouser@host$ systemd --user

Trying to run as user instance, but $XDG_RUNTIME_DIR is not set.

[0] http://immae.eu/blog/2014/05/26/manage-your-session-with-systemd/
[1] https://lists.archlinux.org/pipermail/arch-general/2014-May.txt

--
Fredrik Jonson

[Ansgar Burchardt]

Fredrik Jonson <fre...@jonson.org> writes:
> Ansgar Burchardt wrote:
>> Fredrik Jonson <fre...@jonson.org> writes:
>> > What is the recommended way to set up Systemd user services with Debian?
>> Just run 'loginctl enable-linger [USER]' as root.
>
> Initially that didn't work...
>
> root@host# loginctl enable-linger foouser
> Failed to create bus connection: No such file or directory
>
> A quick google seems to indicate[0][1] that it is related to dbus somehow.
> I checked, and the server didn't have dbus installed on the machine, so I
> installed it (apt-get install dbus) and reran the command:

Hmm, right. logind needs dbus to work.

> root@host# loginctl enable-linger foouser
>
> This time the command ran without any apparent objections from the system.
>
> Next, I create my unit in $HOME/.config/systemd/user/foo.service but
> systemctl fails to enable it:
>
> foouser@host$ systemctl --user enable foo.service
> Failed to get D-Bus connection: Connection refused
>
> Now what?
>
> I notice that there isn't a systemd or dbus instance running under the user.
> Should there be, and if, what's responsible for starting it?
>
> Additionally, when I try to start a user instance manually, it fails:
>
> foouser@host$ systemd --user
> Trying to run as user instance, but $XDG_RUNTIME_DIR is not set.

The documentation for "loginctl enable-linger" says "If enabled for a
specific user, a user manager is spawned for the user at boot and kept
around after logouts." I guess you didn't restart the system?

A user manager should in either case also be started when logging
in. This is handled by logind + libpam-systemd. I assume you might not
have the latter installed? (Note that using "su" to switch from root to
foouser does not count as a login.)

I don't think you can just start "systemd --user" as it wants to manage
cgroups for services it spawns. "/lib/systemd/system/user@.service" has
Delegate=yes to allow it to do so.

libpam-systemd is also responsible for setting the XDG_RUNTIME_DIR
variable.

libpam-systemd is currently at Priority: optional. I'm wondering if it
should be raised to Priority: standard...

Ansgar

[Fredrik Jonson]

Ansgar Burchardt wrote:
> Fredrik Jonson <fre...@jonson.org> writes:

> > What is the recommended way to enable Systemd user services with Debian?
> [...]

> The documentation for "loginctl enable-linger" says "If enabled for a
> specific user, a user manager is spawned for the user at boot and kept
> around after logouts." I guess you didn't restart the system?
>

> [...]

>
> A user manager should in either case also be started when logging
> in. This is handled by logind + libpam-systemd. I assume you might not
> have the latter installed?

Good guess, that's another culprit identified:

foouser@host$ sudo apt-get install libpam-systemd
foouser@host$ sudo shutdown -r now
[... the system reboots]
[... I've previously created ~/.config/systemd/user/foo.service]
foouser@host$ systemctl --user enable foo
foouser@host$ systemctl --user start foo

Succes!

What a great friday afternoon. Debian is awesome!

> I don't think you can just start "systemd --user" as it wants to manage
> cgroups for services it spawns. "/lib/systemd/system/user@.service" has
> Delegate=yes to allow it to do so.

Right, I was just aimlessly typing commands that I hoped where anywhere close
to relevant to resolving the problem. :)

> libpam-systemd is also responsible for setting the XDG_RUNTIME_DIR
> variable.
>
> libpam-systemd is currently at Priority: optional. I'm wondering if it
> should be raised to Priority: standard.

Maybe. I gleaned at the package documentation and wasn't totally convinced it
was relevant. There was already a file /etc/pam.d/systemd-user from the systemd
package, so I didn't understand that I also had to install another package that
provided the actual pam module. Would it not make more sense to have the pam
config in the same package that provides the actual pam module?

Still there might have been relevant keywords that I should have picked up on,
the package description does state:

This package contains the PAM module which registers user sessions in
the systemd control group hierarchy.

OTOH, in the next paragraph I read the following statement, that definitively
steered me away from installing it:

If in doubt, do install this package.

When debian developers tells me in their package documentation that I really
should not install their package, I tend to follow their advice. :)

Anyway, it works now.

In summary, to enable systemd user units on boot in Debian, the following steps
are required:

sudo apt-get install dbus libpam-systemd
sudo loginctl enable-linger [USER]
sudo shutdown -r now

Ansgar, I'm greatful, thanks for all your advice!

--
Fredrik Jonson

[Michael Biebl]

Am 16.10.2015 um 19:05 schrieb Fredrik Jonson:

> If in doubt, do install this package.
>
> When debian developers tells me in their package documentation that I really
> should not install their package, I tend to follow their advice. :)

Did you maybe misread that as
"If in doubt, do *not* install this package".

Otherwise your replay doesn't make sense, unless you meant it sarcastic
in some kind of way.


--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[Fredrik Jonson]

Michael Biebl wrote:

> Am 16.10.2015 um 19:05 schrieb Fredrik Jonson:
>
> > If in doubt, do install this package.
>

> Did you maybe misread that as
> "If in doubt, do *not* install this package".

Yes I did. I don't know how many times I've read that sentence, and clearly saw
a _not_ in there. Interesting.

--
Fredrik Jonson

[Lisi Reisz]

The structure foreshadows a "not". A more natural feeling way of expressing
the positive would be:

If in doubt, install this package.

Lisi

[Fredrik Jonson]

In <qkuIV...@gated-at.bofh.it> Lisi Reisz wrote:
> On Saturday 17 October 2015 06:24:10 Fredrik Jonson wrote:
> > Michael Biebl wrote:
> > > Am 16.10.2015 um 19:05 schrieb Fredrik Jonson:
> > > > If in doubt, do install this package.
> > >
> > > Did you maybe misread that as
> > > "If in doubt, do *not* install this package".
> >
> > Yes I did. I don't know how many times I've read that sentence, and clearly
> > saw a _not_ in there. Interesting.
>
> The structure foreshadows a "not".

Maybe the presence of the entire sentence indicates that the package really
should be installed by default on systems where systemd is installed?

--
Fredrik Jonson

[Michael Biebl]

I'm not a native speaker, so I'm happy to rephrase the message to make
it more obvious. Suggestions?

We might also consider bumping the prio of libpam-systemd to standard,
as Ansgar suggested. That means, it would be installed by default,
unless you explicitly deselect the standard task in d-i.

[Mart van de Wege]

Michael Biebl <bi...@debian.org> writes:

> Am 17.10.2015 um 10:20 schrieb Fredrik Jonson:
>> In <qkuIV...@gated-at.bofh.it> Lisi Reisz wrote:
>>> On Saturday 17 October 2015 06:24:10 Fredrik Jonson wrote:
>>>> Michael Biebl wrote:
>>>>> Am 16.10.2015 um 19:05 schrieb Fredrik Jonson:
>>>>>> If in doubt, do install this package.
>>>>>
>>>>> Did you maybe misread that as
>>>>> "If in doubt, do *not* install this package".
>>>>
>>>> Yes I did. I don't know how many times I've read that sentence, and clearly
>>>> saw a _not_ in there. Interesting.
>>>
>>> The structure foreshadows a "not".
>>
>> Maybe the presence of the entire sentence indicates that the package really
>> should be installed by default on systems where systemd is installed?
>>
>
> I'm not a native speaker, so I'm happy to rephrase the message to make
> it more obvious. Suggestions?

The use of 'do' in that way suggests emphasis. If you wanted that
emphasis, a more unambiguous way is

If in doubt, *install* this package

If the emphasis is unnecessary, just leave out the the 'do'.

Mart

--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.

[Brian]

The sentence is unambiguous (there no word "not" in it); it has a hint
of instruction in it but is perfectly good English as it stands. Leaving
out "do" is still good English but is more requesting or invitational.

[Curt]

On 2015-10-17, Brian <ad...@cityscape.co.uk> wrote:
>>
>> The use of 'do' in that way suggests emphasis. If you wanted that
>> emphasis, a more unambiguous way is
>>
>> If in doubt, *install* this package
>>
>> If the emphasis is unnecessary, just leave out the the 'do'.
>
> The sentence is unambiguous (there no word "not" in it); it has a hint
> of instruction in it but is perfectly good English as it stands. Leaving
> out "do" is still good English but is more requesting or invitational.
>
>

I find the 'do' rather chummy myself.

"If you're in the neighborhood, do stop by."

[Brian]

On Sat 17 Oct 2015 at 13:29:48 +0200, Michael Biebl wrote:

> We might also consider bumping the prio of libpam-systemd to standard,
> as Ansgar suggested. That means, it would be installed by default,
> unless you explicitly deselect the standard task in d-i.

Looking at the policy manual at

https://www.debian.org/doc/debian-policy/ch-archive.html

we see

standard

These packages provide a reasonably small but not too limited
*character-mode* system. This is what will be installed by
default if the user doesn't select anything else. It doesn't
include many large applications.

(The emphasis is mine).

Unless I am misunderstanding something, libpam-systemd has a focus on
non-character-mode systems.

[Lisi Reisz]

On Saturday 17 October 2015 12:29:48 Michael Biebl wrote:
> Am 17.10.2015 um 10:20 schrieb Fredrik Jonson:
> > In <qkuIV...@gated-at.bofh.it> Lisi Reisz wrote:
> >> On Saturday 17 October 2015 06:24:10 Fredrik Jonson wrote:
> >>> Michael Biebl wrote:
> >>>> Am 16.10.2015 um 19:05 schrieb Fredrik Jonson:
> >>>>> If in doubt, do install this package.
> >>>>
> >>>> Did you maybe misread that as
> >>>> "If in doubt, do *not* install this package".
> >>>
> >>> Yes I did. I don't know how many times I've read that sentence, and
> >>> clearly saw a _not_ in there. Interesting.
> >>
> >> The structure foreshadows a "not".
> >
> > Maybe the presence of the entire sentence indicates that the package
> > really should be installed by default on systems where systemd is
> > installed?
>
> I'm not a native speaker, so I'm happy to rephrase the message to make
> it more obvious. Suggestions?

"If in doubt, install this package."

That "do" makes one expect the "not" that isn't there, and even assume that it
is meant to be there, if one has noticed that it isn't.

Lisi

[Brian]

On Sat 17 Oct 2015 at 19:40:50 +0100, Lisi Reisz wrote:

> On Saturday 17 October 2015 12:29:48 Michael Biebl wrote:
> > Am 17.10.2015 um 10:20 schrieb Fredrik Jonson:
> > > In <qkuIV...@gated-at.bofh.it> Lisi Reisz wrote:
> > >> On Saturday 17 October 2015 06:24:10 Fredrik Jonson wrote:
> > >>> Michael Biebl wrote:
> > >>>> Am 16.10.2015 um 19:05 schrieb Fredrik Jonson:
> > >>>>> If in doubt, do install this package.
> > >>>>
> > >>>> Did you maybe misread that as
> > >>>> "If in doubt, do *not* install this package".
> > >>>
> > >>> Yes I did. I don't know how many times I've read that sentence, and
> > >>> clearly saw a _not_ in there. Interesting.
> > >>
> > >> The structure foreshadows a "not".
> > >
> > > Maybe the presence of the entire sentence indicates that the package
> > > really should be installed by default on systems where systemd is
> > > installed?
> >
> > I'm not a native speaker, so I'm happy to rephrase the message to make
> > it more obvious. Suggestions?
>
> "If in doubt, install this package."
>
> That "do" makes one expect the "not" that isn't there, and even assume that it
> is meant to be there, if one has noticed that it isn't.

As my spouse says:

"When you go to the Co-op, please do get butter."

Her expectations are not necessarily met by the eventual outcome. :)

[Lisi Reisz]

:-)

Yes, but she says it, not writes it. You would get a slight (? depending on
whether you forgot last time ;-) ) stress on the "do". ;-)

Lisi

[Brian]

Indeed. The stress is almost always there in conversational English.

If I were to rewrite part of the package description I would have

If in doubt install this package.

No comma. Its not needed.

Install this package if in doubt.

[Joel Rees]

How about,

When in doubt, definitely install this package.

or, to guide the reader more carefully,

This package is installed by default. Unless you have a very good
reason and know what you are doing, leave it that way.

--
Joel Rees

Be careful when you look at conspiracy.
Arm yourself with knowledge of yourself, as well:
http://reiisi.blogspot.jp/2011/10/conspiracy-theories.html

[Chris Bannister]

Weird, I think I (mis)read it that way as well. Better would be
'If in doubt, install this package.'

--
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the
oppressing." --- Malcolm X

[Chris Bannister]

On Sun, Oct 18, 2015 at 09:10:09AM +0900, Joel Rees wrote:
>
> How about,
>
> When in doubt, definitely install this package.
>
> or, to guide the reader more carefully,
>
> This package is installed by default. Unless you have a very good
> reason and know what you are doing, leave it that way.

Unless I'm missing something, they conflict. If it's installed by
default, there would be no need for the first instruction at all.

[Fredrik Jonson]

Brian wrote:
> On Sat 17 Oct 2015 at 13:29:48 +0200, Michael Biebl wrote:
>
> > We might also consider bumping the prio of libpam-systemd to standard,
> > as Ansgar suggested. That means, it would be installed by default,
> > unless you explicitly deselect the standard task in d-i.
>

> [priority] standard

>
> These packages provide a reasonably small but not too limited
> *character-mode* system.
>

> Unless I am misunderstanding something, libpam-systemd has a focus on
> non-character-mode systems.

Maybe. Though this thread shows that libpam-systemd solves at least one common
use case on character-mode only systems too.

The installed size of libpam-systemd plus dbus is 1.2 MB. Is that too much for
priority standard?

--
Fredrik Jonson

[Curt]

On 2015-10-17, Brian <ad...@cityscape.co.uk> wrote:
>

> If I were to rewrite part of the package description I would have
>
> If in doubt install this package.
>
> No comma. Its not needed.

No, an apostrophe is needed.

> Install this package if in doubt.
>
>

--

[Brian]

On Sun 18 Oct 2015 at 09:50:14 +0000, Fredrik Jonson wrote:

> Brian wrote:
> > On Sat 17 Oct 2015 at 13:29:48 +0200, Michael Biebl wrote:
> >
> > > We might also consider bumping the prio of libpam-systemd to standard,
> > > as Ansgar suggested. That means, it would be installed by default,
> > > unless you explicitly deselect the standard task in d-i.
> >
> > [priority] standard
> >
> > These packages provide a reasonably small but not too limited
> > *character-mode* system.
> >
> > Unless I am misunderstanding something, libpam-systemd has a focus on
> > non-character-mode systems.
>
> Maybe. Though this thread shows that libpam-systemd solves at least one common
> use case on character-mode only systems too.

So it seems. Is it worth a bug report to keep track of the issue?

> The installed size of libpam-systemd plus dbus is 1.2 MB. Is that too much for
> priority standard?

dbus has been changed to have a priority of standard.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759293