chiark / gitweb /
login: log session state "closing" (as well as New/Removed)
authorAlan Jenkins <alan.christopher.jenkins@gmail.com>
Fri, 1 Jun 2018 18:03:21 +0000 (19:03 +0100)
committerSven Eden <yamakuzure@gmx.net>
Fri, 24 Aug 2018 14:47:08 +0000 (16:47 +0200)
Let's show a message at the time of logout i.e. entering the "closing"
state, not just e.g. once the user closes `tmux` and the session can be
removed completely.  (At least when KillUserProcesses=no applies.  My
thinking was we can spare the log noise if we're killing the processes
anyway).

These are two independent events.  I think the logout event is quite
significant in the session lifecycle.  It will be easier for a user who
does not know logind details to understand why "Removed session" doesn't
appear at logout time, if we have a specific message we can show at this
time :).

Tested using tmux and KillUserProcesses=no.  I can also confirm the extra
message doesn't show when using KillUserProcesses=yes.  Maybe it looks a
bit mysterious when you use KillOnlyUsers= / KillExcludeUsers=, but
hopefully not alarmingly so.

I was looking at systemd-logind messages on my system, because I can
reproduce two separate problems with Gnome on Fedora 28 where
sessions are unexpectedly in state "closing".  (One where a GUI session
limps along in a degraded state[1], and another where spice-vdagent is left
alive after logout, keeping the session around[2]).  It logged when
sessions were created and removed, but it didn't log when the session
entered the "closing" state.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1583240#c1
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1583261

Closes #9096

src/login/logind-session.c

index e5adbdcf7ee325a252f6315b4c246c51f0bc1e3f..221fa9fb7328856d23977cd92360667e2469f818 100644 (file)
@@ -706,9 +706,20 @@ static int session_stop_scope(Session *s, bool force) {
 
                 free(s->scope_job);
                 s->scope_job = job;
-        } else
+        } else {
                 s->scope_job = mfree(s->scope_job);
 
+                /* With no killing, this session is allowed to persist in "closing" state indefinitely.
+                 * Therefore session stop and session removal may be two distinct events.
+                 * Session stop is quite significant on its own, let's log it. */
+                log_struct(s->class == SESSION_BACKGROUND ? LOG_DEBUG : LOG_INFO,
+                           "SESSION_ID=%s", s->id,
+                           "USER_ID=%s", s->user->name,
+                           "LEADER="PID_FMT, s->leader,
+                           LOG_MESSAGE("Session %s logged out. Waiting for processes to exit.", s->id),
+                           NULL);
+        }
+
         return 0;
 }
 #else