I actually added the `-s ${XDG_SESSION_ID}` while trying to debug the issue
after reading through #994762 <994...@bugs.debian.org>
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.
Without the `-s ${XDG_SESSION_ID}` I still get the core dump (that prompted
me to attempt adding it):
× xss-lock.service - X Session Lock
Loaded: loaded
(/home/stuart/.config/systemd/user/xss-lock.service; enabled; preset:
enabled)
Active: failed (Result: core-dump) since Mon 2023-01-23 17:05:52
EST; 16s ago
Duration: 3min 17.814s
Process: 3389 ExecStart=xss-lock -n /usr/libexec/xsecurelock/dimmer
-l -- xsecurelock (code=dumped, signal=ABRT)
Main PID: 3389 (code=dumped, signal=ABRT)
CPU: 121ms
Jan 23 17:02:35 gamera systemd[1469]: Started X Session Lock.
Jan 23 17:02:35 gamera xss-lock[3389]: Error getting session:
GDBus.Error:org.freedesktop.login1.NoSessionForPID: PID 3389 does not
belong to any known session
Jan 23 17:05:52 gamera xss-lock[3389]: xss-lock: ./src/xss-lock.c:469:
logind_session_set_locked_hint: Assertion `logind_session' failed.
Jan 23 17:05:52 gamera systemd-coredump[6948]: [🡕] Process 3389
(xss-lock) of user 1000 dumped core.
Stack trace of thread 3389:
#0 0x00007fba5e596ccc
__pthread_kill_implementation (libc.so.6 + 0x8accc)
#1 0x00007fba5e547ef2
__GI_raise (libc.so.6 + 0x3bef2)
#2 0x00007fba5e532472
__GI_abort (libc.so.6 + 0x26472)
#3 0x00007fba5e532395
__assert_fail_base (libc.so.6 + 0x26395)
#4 0x00007fba5e540df2
__GI___assert_fail (libc.so.6 + 0x34df2)
#5 0x000056156371cff7 n/a
(xss-lock + 0x3ff7)
#6 0x000056156371d6cc n/a
(xss-lock + 0x46cc)
#7 0x000056156371d8ee n/a
(xss-lock + 0x48ee)
#8 0x00007fba5e78867f
g_main_context_dispatch (libglib-2.0.so.0 + 0x5467f)
#9 0x00007fba5e788a38 n/a
(libglib-2.0.so.0 + 0x54a38)
#10 0x00007fba5e788cef
g_main_loop_run (libglib-2.0.so.0 + 0x54cef)
#11 0x000056156371c7e2 main
(xss-lock + 0x37e2)
#12 0x00007fba5e53318a
__libc_start_call_main (libc.so.6 + 0x2718a)
#13 0x00007fba5e533245
__libc_start_main_impl (libc.so.6 + 0x27245)
#14 0x000056156371caf1
_start (xss-lock + 0x3af1)
Stack trace of thread 3393:
#0 0x00007fba5e6080af
__GI___poll (libc.so.6 + 0xfc0af)
#1 0x00007fba5e7889ae n/a
(libglib-2.0.so.0 + 0x549ae)
#2 0x00007fba5e788acc
g_main_context_iteration (libglib-2.0.so.0 + 0x54acc)
#3 0x00007fba5e788b11 n/a
(libglib-2.0.so.0 + 0x54b11)
#4 0x00007fba5e7b2cfd n/a
(libglib-2.0.so.0 + 0x7ecfd)
#5 0x00007fba5e594fd4
start_thread (libc.so.6 + 0x88fd4)
#6 0x00007fba5e61566c
__clone3 (libc.so.6 + 0x10966c)
Stack trace of thread 3396:
#0 0x00007fba5e6080af
__GI___poll (libc.so.6 + 0xfc0af)
#1 0x00007fba5e7889ae n/a
(libglib-2.0.so.0 + 0x549ae)
#2 0x00007fba5e788cef
g_main_loop_run (libglib-2.0.so.0 + 0x54cef)
#3 0x00007fba5e9e4996 n/a
(libgio-2.0.so.0 + 0x118996)
#4 0x00007fba5e7b2cfd n/a
(libglib-2.0.so.0 + 0x7ecfd)
#5 0x00007fba5e594fd4
start_thread (libc.so.6 + 0x88fd4)
#6 0x00007fba5e61566c
__clone3 (libc.so.6 + 0x10966c)
ELF object binary
architecture: AMD x86-64
Jan 23 17:05:52 gamera systemd[1469]: xss-lock.service: Main process
exited, code=dumped, status=6/ABRT
Jan 23 17:05:52 gamera systemd[1469]: xss-lock.service: Failed with
result 'core-dump'.
logind is running, I haven't changed its configuration on this machine, so
if it's misconfigured it was packaged that way.
I don't think it can be starting before dbus, as it's started by
`WantedBy=xsession.target` and xsession.target is
`BindsTo=graphical-session.target`
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).
--
Stuart
On Mon, Jan 23, 2023 at 4:12 PM Ian Campbell <i...@debian.org> wrote:
> On Mon, 2023-01-23 at 11:04 -0500, Stuart Freeman wrote:
> > Process: 8434 ExecStart=xss-lock -s ${XDG_SESSION_ID} -n
> /usr/libexec/xsecurelock/dimmer -l -- xsecurelock (code=dumped, signal=ABRT)
>
> Are you sure that `${XDG_SESSION_ID}` is being properly substituted
> here and with the correct value?
>
> I've just been playing locally and by default nothing is substituted.
> If I run `systemctl --user import-environment XDG_SESSION_ID` and then
> reload the daemon it does get correctly substituted.
>
> A wrong or missing value for XDG_SESSION_ID could very well explain the
> issue you are seeing.
>
> Ian.
>
>
