'Twas brillig, and Colin Guthrie at 03/09/12 14:47 did gyre and gimble: > [colin@jimmy systemd-189]$ cat /run/systemd/users/492 > # This is private data. Do not parse. > NAME=gdm > STATE=online > CGROUP=/user/gdm > RUNTIME=/run/user/492 > DISPLAY=1 > SESSIONS=1 > SEATS=seat0 > ACTIVE_SESSIONS= > ACTIVE_SEATS= > > > It does not seem to reflect anything to do with the fact that the > session is closing. > > So, how can I differentiate between an State=active session and a > State=closing one via the sd_* methods? > > Does something extra need to get added to this env var and a new API > method added to sd-login.c to cope with this? > > > I would propose that STATE= variable gets updated to "closing" here (if > possible) and that sd_uid_get_sessions() is modified such that passing a > require_active value of 2 (or -1?) would only return if a session is > both SESSIONS=(>=1) and STATE=(active|online). > > > Alternatively, we could just make uid_get_array() always require that > STATE=(active|online) and make that hard coded. > > > WDYT?
I realise this suggestion is not possible, as the STATE= value here is aggregate over multiple sessions. I thus change the proposal to add a new variable to the env file: ONLINE_SESSIONS= This is very similar to SESSIONS= but will exclude any sessions in the closing state. The implementation of sd_uid_get_sessions() can then either be changed to search for ONLINE_SESSIONS= vs. ACTIVE_SESSIONS=, or the require_active value can be end up with three values: 0 == SESSIONS, 1 == ACTIVE_SESSIONS, 2 == ONLINE_SESSIONS. Either that or a new function: sd_uid_get_online_sessions() be used instead. Personally I actually prefer the three-value approach as it degrades somewhat nicely. Opinions welcome. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
