On Mon, 2023-01-23 at 17:28 -0500, Stuart Freeman wrote:
> I actually added the `-s ${XDG_SESSION_ID}` while trying to debug the
> issue after reading through #994762
>
> xss-lock had been working for over a year until as recently as a
> couple days ago when I experienced a prolonged power outage that
> forced a reboot, so I'm not sure if it was broken by some other
> package updating and just hadn't been restarted until then or what.
It is possible that the reboot caused you to actually run xss-lock
0.3.0+git20220214.adafe4-2 for the first time, even if as you say the
upgrade might have been a long while before.
It looks like the new upstream includes:
https://github.com/wavexx/xss-lock/commit/7b0b4dc83ff3716fd3051e6abf9709ddc434e985
Which adds the assert you are seeing triggered.
In earlier versions the inability to connect to logind would have been
ignored, you just wouldn't get the hints set.
> It does seem to work after re-adding the XDG_SESSION_ID and
> `systemctl --user import-environment XDG_SESSION_ID` but that doesn't
> explain why it suddenly stopped being able to get the session id
> (presumably from dbus).
It looks like without -s the `GetSessionByPID` dbus method is called
and with it `GetSession` is used instead (passing the value of the
argument). You logs have:
> GDBus.Error:org.freedesktop.login1.NoSessionForPID: Caller does not belong to
> any known session.
Which seems to suggest GetSessionByPID was used and didn't work. I
can't see anything different around that end of things. I suppose it is
possible that this was never working for you, just previously it would
silently not set the idle hint with logind and now it errors out.
Do your systemd/journald arrangements mean you have logs from when you
were running 0.3.0-10 or sooner? If so you might see that you had that
message back then too, it was just non fatal. Actually I think #994762
was about exactly that on an older version too.
I think `systemctl --user import-environment XDG_SESSION_ID` is likely
the right thing to be doing, at least for now, since it will result in
you connecting to the logind session.
The alternative would be to request that upstream revert the change I
pointed to earlier or to otherwise make the requirement for logind
optional somehow, although I'm not really sure what the implications of
not giving hints to logind are...
Ian.
