| Summary: | logind session gets stuck semi-often | ||
|---|---|---|---|
| Product: | systemd | Reporter: | Marius Vollmer <marius.vollmer> |
| Component: | general | Assignee: | systemd-bugs |
| Status: | RESOLVED WORKSFORME | QA Contact: | systemd-bugs |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
Smells like a bug with cgroup notifications. I need to debug that in some detail, we have seen this elsewhere too. One thing however, before I look into that in detail: is there any reason why you fill in the TTY field with something that is not actually a TTY? we do idle-detection on the tty specified there, hence I'd prefer if that field could be properly initialize or not initialized at all... (In reply to Lennart Poettering from comment #1) > One thing however, before I look into that in detail: is there any reason > why you fill in the TTY field with something that is not actually a TTY? No, I think we cargo-culted that from somewhere else. I'll change this. https://github.com/cockpit-project/cockpit/pull/1808 Is that correct? I took the liberty to set the session type to "web" although it is not one of the supported values. I think you were going to add that type, no? Yeah, looks good, commented in more detail on the github review thing... I am pretty sure this works reliably on current systems. Closing. If this is still an issue, please file a new issue on github. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
systemd-216-17.fc21.x86_64 In our testsuite, we can fairly regularly observe sessions stuck in the 'closing' state without any processes in them: 3 - admin (1000) Since: Sat 2015-02-07 19:35:01 EET; 4min 41s ago Leader: 782 TTY: cockpit-782 Remote: 10.111.111.200 Service: cockpit; type tty; class user State: closing Unit: session-3.scope <empty> As far as I can tell, this state persists indefinitely. "loginctl terminate-session 3" will remove the session immediately. The session is created by our own code. The journal shows these messages: Feb 07 16:57:08 localhost.localdomain systemd-logind[320]: New session 3 of user admin. Feb 07 16:57:08 localhost.localdomain systemd[786]: pam_unix(systemd-user:session): session opened for user admin by (uid=0) ... Feb 07 16:57:10 localhost.localdomain cockpit-session[781]: pam_unix(cockpit:session): session closed for user admin Note that systemd seems to open the session, but cockpit-session seems to close it. (If I have copied the right lines.) Any hints for debugging this would be appreciated.