[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Starting systemd user services on boot on a Debian server



Fredrik Jonson <fredrik@jonson.org> writes:
> Ansgar Burchardt wrote:
>>  Fredrik Jonson <fredrik@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


Reply to: