[systemd-devel] Many user slices created and user managers spawned on boot
Mantas Mikulėnas
grawity at gmail.com
Sat Jan 26 16:58:03 UTC 2019
On Sat, Jan 26, 2019 at 6:55 PM Mantas Mikulėnas <grawity at gmail.com> wrote:
> On Sat, Jan 26, 2019 at 6:36 PM Steve Bergman <steve at sbergman.net> wrote:
>
>> Hi,
>>
>> I have a Debian 9 server, fully updated (systemd 240-4) which acts as an
>> X2Go desktop server hosting remote X sessions for about 150 users. I've
>> made no special customizations to the systemd configuration. On boot,
>> immediately after systemd-user-sessions.service starts, systemd
>> immediately creates slices for most of my users, starts a user manager
>> for each, and mounts a run directory for each. Users which have not
>> logged in for a very long time (possibly since before the upgrade from
>> Debian 7 with sysvinit to Debian 9 with systemd) are not included. But
>> if I log in as one of these users then, starting with the next reboot,
>> those accounts are included, as well.
>>
>> Is this normal? This server is certainly acting quite differently than
>> any of my others, where the slices and management processes get created
>> on login and destroyed on logout.
>>
>
> Take a look at /var/lib/systemd/linger. Something, quite possibly X2go
> <https://codesearch.debian.net/search?q=enable-linger+package%3A%5CQx2goserver%5CE>,
> is configuring systemd to start a user@<uid>.service for every user on
> boot.
>
> This is normally off by default and done by the admin via `loginctl
> enable-linger <user>` or `loginctl disable-linger <user>`. (The feature is
> there to let certain users start stuff on boot without having to rely on
> e.g. cron's @reboot jobs.)
>
Forgot to finish that thought. It looks like X2go uses this feature because
it also avoids systemd's usual cleanup on logout, as there's no easy
opt-out for that. (Although I believe it's now usually disabled distro-wide
via /etc/systemd/logind.conf anyway?)
--
Mantas Mikulėnas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20190126/f1b8bde8/attachment-0001.html>
More information about the systemd-devel
mailing list