SetIdleHint /SetLockedHint false, but property remains true

[edrex]

systemd 243.78-2 Arch x86_64

IdleHint and LockedHint properties are true.

Calling

gdbus call -y -d org.freedesktop.login1 -o /org/freedesktop/login1/session/auto -m org.freedesktop.login1.Session.SetIdleHint false
gdbus call -y -d org.freedesktop.login1 -o /org/freedesktop/login1/session/auto -m org.freedesktop.login1.Session.SetLockedHint false

doesn't change their values, and

gdbus monitor -y -d org.freedesktop.login1 -o /org/freedesktop/login1/session/auto

doesn't report any property changes, which would seem to rule out some other caller setting the value back.

method_set_idle_hint seems very straightforward, don't see a code path that could lead to this result.

• Originally reported at systemd/logind IdleAction taken despite not being idle swaywm/swayidle#4 (comment)
• systemd-logind idle inhibit does not emit PropertiesChanged for IdleHint when called from idle #13596 seems similar but the property is changing just not emitted.
• Previous reports of same behavior here and here.

[progandy]

A console session with IdleHint=false falls back to checking the tty access time, so it will always be idle when the tty does not receive any input events for IdleActionSec seconds. A graphical environment intercepts these and the tty will never receive any input.

systemd/src/login/logind-session.c

Lines 934 to 985 in 8246905

	int session_get_idle_hint(Session *s, dual_timestamp *t) {
	usec_t atime = 0, n;
	int r;
	assert(s);
	/* Explicit idle hint is set */
	if (s->idle_hint) {
	if (t)
	*t = s->idle_hint_timestamp;
	return s->idle_hint;
	}
	/* Graphical sessions should really implement a real
	* idle hint logic */
	if (SESSION_TYPE_IS_GRAPHICAL(s->type))
	goto dont_know;
	/* For sessions with an explicitly configured tty, let's check
	* its atime */
	if (s->tty) {
	r = get_tty_atime(s->tty, &atime);
	if (r >= 0)
	goto found_atime;
	}
	/* For sessions with a leader but no explicitly configured
	* tty, let's check the controlling tty of the leader */
	if (pid_is_valid(s->leader)) {
	r = get_process_ctty_atime(s->leader, &atime);
	if (r >= 0)
	goto found_atime;
	}
	dont_know:
	if (t)
	*t = s->idle_hint_timestamp;
	return 0;
	found_atime:
	if (t)
	dual_timestamp_from_realtime(t, atime);
	n = now(CLOCK_REALTIME);
	if (s->manager->idle_action_usec <= 0)
	return 0;
	return atime + s->manager->idle_action_usec <= n;
	}

You have to explicitly mark sessions as "graphical" to stop logind from doing that. This can be done only during the session creation in the pam_systemd module with the environment variable XDG_SESSION_TYPE or the type parameter for the pam_systemd module in the pam configuration. If you have custom code to create the session, then you need to set the type paramter of the CreateSession dbus call.

Currently there are no provisions to change the session type of an existing session or to disable atime detection for console sessions. A display manager is one way to create the pam session with XDG_SESSION_TYPE set to x11, mir or wayland (those three are recognized as graphical by systemd). Another option is to set it explicitly in your pam configuration. It should also be possible to create a systemd unit that starts your display server with a pam session that has the environment variable set as well for autologin purposes.

I have not looked into the LockedHint, it may be a consequence of being idle.

[edrex]

Thanks for the knowledge. I'll have to dig in and do some experimentation to digest all that. I see that

❯ echo $XDG_SESSION_TYPE 
tty

Does sway started from tty inherit the tty session rather than create one? Sway project recommends starting manually from TTY so

I don't understand how this explains not being able to change the IdleHint dbus property via SetIdleHint.

I just noticed the values from by loginctl and dbus don't match:

❯ gdbus call -y -d org.freedesktop.login1 -o /org/freedesktop/login1/session/auto -m org.freedesktop.DBus.Properties.Get org.freedesktop.login1.Session IdleHint
(<true>,)
❯ loginctl show-session 
...
IdleHint=no

[progandy]

Does sway started from tty inherit the tty session rather than create one?

For a given value of "inherit". It is started inside of the tty session, so it will belong to that session. No application can create its own session without special privileges (e.g. root).

I don't understand how this explains not being able to change the IdleHint dbus property via SetIdleHint.

The internal idle_hint can be changed, but the dbus property returns the result of the session_get_idle_hint method, so you'll never see that when the atime detection spits out an idle status.

[poettering]

So I thought a bit about this. But this kind of "upgrading" of sessions is quite problematic, clients should really create new sessions, so that there's a context that is referenced and when the client goes away can be destroyed again and the state returned to the status quo ante...

I thought about making the idle hint fully overridable, in both ways (currently you can mark a tty session idle, but never unmark it) but then there'd be no concept of reverting to the original state when your display manager dies again, i.e. if you leave it the last idle state will be frozen and never be updated again.

If your display manager wants the idle logic to work and operate on a tty it can of course keep touching the tty atime... But really it should just register a proper session instead that doesn't claim to be tty.

[tmccombs]

clients should really create new sessions

But as @progandy pointed out, unless the client has elevated privileges, it isn't able to create a new session. If I understand correctly, in this issue, there is no display manager, sway was started after logging in to a TTY.

Setting XDG_SESSION_TYPE in .pam_environment works if always starting a graphical session after logging in, but would probably cause unwanted behaviour if a graphical session is started in one tty and a text console is in another tty. For example, I have this in my .profile:

if [ -z "$DISPLAY" ] && [ "$XDG_VTNR" -eq 1 ]; then
  exec startx
fi

So that if I log in on tty 1, then I start X, but I can still get a normal terminal if I log in to another tty as a fallback.

[poettering]

I posted #14501 which makes this more discoverable...

"Upgrading" of tty sessions to graphical is still not better supported with that (because that's a hard problem, and not sure if even desirable), but at least the failure becomes clearly discoverable. But issues around are better tracked in #14489 or so.