Bug 1371721

Summary: With linger enabled, the user manager can die and won't be restarted
Product: [Fedora] Fedora Reporter: Jason Tibbitts <tibbs>
Component: systemdAssignee: systemd-maint
Status: NEW --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: bugzilla, johannbg, lnykryn, mark, msekleta, muadda, s, systemd-maint, zbyszek
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Jason Tibbitts 2016-08-30 23:54:08 UTC
systemd-229-13.fc24.x86_64

Without linger, if you log in, a user manager (systemd --user if I'm not using the right terminology) will fire up for your session and exit after all of the processes have exited.

When linger is enabled, you're supposed to already have a user manager running, either at boot (which is a really suboptimal thing to happen), from one being started when linger was enabled (by someone else), or the one that was running for your login when you enabled linger.

However, if linger is enabled and your user manager exits for some reason, it will not be restarted and now you have no user manager.  The only way I've found to get one back is to disable linger, log out, and log back in.

To reproduce, make sure your test user is logged out, linger is enabled for them, and their user manager is running.  Have your test user log in (ssh is fine) and kill -9 -1, or just have root kill their user manager.  Have them log back in.  For me this gets the following:

root       13020  1.4  0.0 177728  9704 ?        Ss   18:45 00:00:00 sshd: tester2 [priv]
tester2    13023  0.0  0.0 177728  4780 ?        S    18:45 00:00:00 sshd: tester2@pts/2
tester2    13024  0.3  0.0 133428  4944 pts/2    Ss+  18:45 00:00:00 -bash

(i.e. no user manager is running at all).   /var/lib/systemd/linger has:
-rw-r--r--. 1 root root 0 Aug 30 18:43 tester2

And of course then you can't do systemd-run:
> systemd-run --user true
Failed to create bus connection: Connection refused

If at this point you enable linger (doesn't matter who does it), they still won't have a user manager.  If they disable linger, log out and log back in, _then_ they will have a user manager, and can then enable linger and run jobs in scopes.

This makes linger rather less useful, since a user can easily get into a situation where they can't run a job in a different scope to bypass KillUserProcesses=yes.  But of course, it's required in that situation, so there's no real way out....

What I don't quite understand is why lingering isn't an attribute on the scope, with the user manager exiting when no more lingering scopes exist, and of course have the manager always starting when the first user session is brought up (instead of at boot, which just causes problems when your home directories are on a network).  I'm sure it was designed this way for a reason; I just haven't been able to understand it.

Comment 1 Fedora End Of Life 2017-07-25 22:45:49 UTC
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.