Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 25 May 2020 15:53:49 +0000
From:      bugzilla-noreply@freebsd.org
To:        gnome@FreeBSD.org
Subject:   [Bug 221452] sysutils/consolekit2: session's active state lost when switching between virtual terminals
Message-ID:  <bug-221452-6497-jksDCj8de3@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-221452-6497@https.bugs.freebsd.org/bugzilla/>
References:  <bug-221452-6497@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221452

--- Comment #25 from Christina Mueller <chris@mumac.de> ---
Sorry for the delay, things got into the way. I've now reproduced the issue=
 on
a new VM with 13-CURRENT and KDE/SCCM with kern.vty=3Dvt:

This is with KDE on the screen after switching between various VTs:
chris@ck-test:~ $ sysctl kern.vty
kern.vty: vt
chris@ck-test:~ $ ck-list-sessions
Session2:
        unix-user =3D '1001'
        realname =3D 'Christina Mueller'
        seat =3D 'Seat1'
        session-type =3D 'unspecified'
        session-class =3D 'user'
        session-state =3D 'online'
        active =3D FALSE
        x11-display =3D ':0'
        x11-display-device =3D '/dev/ttyv8'
        display-device =3D '/dev/   ?   '
        remote-host-name =3D ''
        is-local =3D TRUE
        on-since =3D '2020-05-25T15:42:38.148925Z'
        login-session-id =3D ''
        XDG_RUNTIME_DIR =3D '/var/run/user/1001'
        VTNr =3D '9'

One thing worth noting is that just switching from the X VT to VT #1 doesn't
trigger the problem. the X session is still reported as active. Even loggin=
g in
on VT #1 did not change anything. switching to VT #2/3/4 and back finally m=
ade
the X session inactive and it did not reactivate when switching back to it.

I haven't noticed this before but this could mean that consolekit2 misses s=
ome
of the VT switches and this might be part of the problem.

I'll recompile the installed packages with debug info and see if I can track
this down but debugging dbus-launched services is a pain as dbus tends to s=
tart
new instances almost at will (I guess it's not happy with the delays incurr=
ed
by debugging).

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-221452-6497-jksDCj8de3>