[systemd-devel] How to Listen for SessionRemoved Signal

[Mantas Mikulėnas]

On Fri, Jul 11, 2014 at 7:18 AM, Kurt von Laven <kurt at endlessm.com> wrote:

> Hello folks,
>
> Apologies if anybody is getting this message twice; I originally posted on
> dbus at lists.freedesktop.org and was directed here.
>
> I am attempting to listen to the SessionRemoved signal from the login
> manager <http://www.freedesktop.org/wiki/Software/systemd/logind/>. I
> have no trouble in the case where the user logs out and waits for ~15
> seconds before shutting down, but when the user shuts down the system
> without first logging out I don't hear the SessionRemoved signal in time. I
> would've thought that inhibiting shutdown (by calling the Inhibit method
> of the login manager
> <http://www.freedesktop.org/wiki/Software/systemd/inhibit/>) would be the
> appropriate way to keep my process alive long enough to record the
> SessionRemoved signal before my process gets killed. Apparently that is not
> the case though. I am fairly certain that I am actually inhibiting
> shutdown, because my process shows up when I call ListInhibitors in D-Feet
> <https://wiki.gnome.org/action/show/Apps/DFeet>.
>
> In case it's relevant, I'm using the delay mode of the inhibit method, and
> my process runs as root.
>

Inhibitors do not make any sense here. You're inhibiting not just the final
power-off of the machine, but the *entire* shutdown process, *including the
stopping of login sessions*, so you would not see SessionRemoved until
after you release the inhibitor anyway.


> To test whether my process was running in the user session, I called getsid
> (0) <http://linux.about.com/library/cmd/blcmdl2_getsid.htm>. It returned
> the PID of my process, which does not match the session ID of the
> SessionRemoved signals I was able to record. Is this a legitimate way to
> verify that my process isn't running in the user session? My original
> assumption was that my process couldn't possibly be in the user session
> because I am able to hear the SessionRemoved signal when the user logs out
> and waits for ~15 seconds. Is that a bad assumption to make?
>

No, this is the wrong method. logind's sessions have nothing to do with
getsid() and POSIX sessions (which are limited to the point of being
completely useless).

To see if you're running within a logind session, the preferred way is
*sd_pid_get_session(0,
&session_id)*. Alternatively, you can:

a) check the $XDG_SESSION_ID variable, which will contain the session ID if
you're inside one,
b) check the cgroups of your process (e.g. in /proc/self/cgroup), which
will show you as being in "/user.slice/user-%s.slice/session-%d.scope".

Note that there is no supported way for escaping a user session. But if you
run your program as a system service (from a .service unit), then it won't
be put in a session in the first place.


> I was advised that some shutdown commands bypass logind, so I tried
> shutting down several different ways (systemctl shutdown, shutdown now,
> sudo shutdown now, calling Shutdown method on org.gnome.SessionManager from
> D-Feet, and the typical GUI way). In all cases I got the same result: I
> didn't hear the SessionRemoved signal.
>

logind is just a "proxy" for purposes of polkit authorization (which cannot
be done in pid 1); it only forwards the shutdown request to systemd (PID
1). Even tools that use the old SysVinit "/dev/initctl" method still result
in the same request, and systemd performs the same shutdown process.


> If anyone has any suggestions on how to debug this or knows what I am
> missing here, that would be greatly appreciated. Please let me know if any
> additional details would be helpful.
>

If I remember correctly the details of systemd boot process, the best
approach would be to run your monitor-thingy in a system service (a
.service unit), and *order the service
"Before=systemd-user-sessions.service"*. That way, during boot, it will be
started *before* any session gets created, and the opposite happens during
shutdown – your service will be stopped *after* all sessions are removed.

-- 
Mantas Mikulėnas <grawity at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140711/6043c706/attachment-0001.html>