Bug 1371721
| Summary: | With linger enabled, the user manager can die and won't be restarted | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jason Tibbitts <j> |
| Component: | systemd | Assignee: | systemd-maint |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | bugzilla, dtardon, 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: | 2022-08-23 14:56:33 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. |
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.