control: tag -1 upstream,help

Thanks for your report!

On Mon, 2021-09-20 at 11:42 -0400, Antoine Beaupre wrote:
> I'm not sure how to use this program.

FWIW I use it by launching from my .i3/config with:

    exec --no-startup-id exec xss-lock --transfer-sleep-lock -- i3lock -d 
--color 000000

Which desktop env are you using?

>  I have tried to start it from
> systemd using the `.service` file provided by the package, but this
> fails with:
> 
>     sep 20 11:38:29 curie xss-lock[3803849]: Error getting session:
> GDBus.Error:org.freedesktop.login1.NoSessionForPID: Caller does not
> belong to any known session.
> 
> When inspecting the service, the GRAPHICAL_SESSION_ID variable is not
> actually set.

In fact the only hit online is your bugreport AFAICT. I wonder if the
author of that service file used it as a placeholder to be replaced
with something specific to the actual environment or if it was
something they arranged locally some other way?

Have you tried just removing that bit of the service file? `-s` is
documented as `Use the session **ID** instead of the current session.`
so maybe it'll just DTRT?

> 
> I have tried to run it from a xterm using:
> 
>     /usr/bin/xss-lock -l -n /usr/lib/xsecurelock/dimmer --
> xsecurelock
> 
> and this fails with:
> 
>     ** (xss-lock:3806201): WARNING **: 11:41:13.273: Error getting
> session: GDBus.Error:org.freedesktop.login1.NoSessionForPID: PID
> 3806201 does not belong to any known session

Hrm, I don't see those, perhaps it is desktop or session manager
specific somehow. I'm using i3 under lightdm.

> Somehow it still seems to work, however, so I'm not sure what to do
> with those warnings...

Me neither and I'm afraid upstream[0] has been dormant for several
years so I'm rather reliant on contributions for issues people see
which I don't.

Perhaps
https://bitbucket.org/raymonad/xss-lock/issues/13/allow-operation-as-systemd-user-unit#comment-45869112
is useful, since they appear to be the author of the `-s` feature. And
https://bitbucket.org/raymonad/xss-lock/issues/13/allow-operation-as-systemd-user-unit#comment-46751262
then suggests using $XDG_SESSION_ID (but makes reference to having to
export it somehow...).

Worth a try I suppose, please let me know if it works and I'll update
the service file in the package.

Out-of-interest how does one go about activating the service file for
your user, I suppose you copy it to ~/.config somewhere or pass it to
some systemctl command -- it'd be great if I could add some
instructions to the docs.

Cheers,
Ian.

[0] https://bitbucket.org/raymonad/xss-lock/

Reply via email to