[Thinlinc-technical] automatically unlocking screen saver on session connect?

Torsten Kasch tk at CeBiTec.Uni-Bielefeld.DE
Mon Dec 1 14:47:22 CET 2014

Hi Carsten,

On 29.11.2014 18:10, Carsten Rose wrote:
> According to
> https://www.cendio.com/resources/docs/tag/configuration_customizing_user_session.html
> there is a /opt/thinlinc/etc/sessionreconnect.d/

Oops, it seems I missed this part of the documentation -- thanks for the pointer!

> We didn't step deeper into this. Our idea was:
> In sessionreconnect.d (vsmserver host) tell the screenlock (vsmagent host) to
> unlock.
> Some approaches:
> Option d)
> Like (a) but instead of unlock, kill the user screenserver and start a new one
> (might be easier than doing an unlock.

Thanks for your input; this indeed comes close to what I had in mind originally.
Fiddling with xscreensaver-command(1) reveals that the "-deactivate" option does
unblank the screen but wouldn't unlock it (as documented).

The Gnome counterpart, OTOH, seems to support this feature via the command line:
I was able to successfully manually unlock a session via

    gnome-screensaver-command -d

on my old FC19 box which I currently have available for testing. I haven't yet
succeeded in getting this command to work via a script in sessionreconnect.d,
but I hope to find some more time to look into this later this week...

But while we're at it: looking at the output of env(1) run from such a
"reconnect script" shows hardly any info about the session to be connected
(apart from $USER which reveals the session's owner). Since the script
apparently isn't called with any arguments I'm wondering if there is some
official method to identify the user session to be connected? I tried running

    /bin/su - ${USER} -c "${TLPREFIX}/bin/tl-session-param -a /"

from the "reconnect script" but that didn't produce any output for me. From
within the session I do get an appropriate output, though. Did I miss something


More information about the Thinlinc-technical mailing list