Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1073223

Bug#994762: warnings about session IDs

Show all headers | View raw

On 2021-09-25 10:14:46, Ian Campbell wrote:
> 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'm using i3 as well, but I'm starting xss-lock from systemd, like
i3. I'm basically following:

https://vincent.bernat.ch/en/blog/2021-i3-window-manager#systemd-the-service-manager

... but now that I look at it more closely, he has a more elaborate
startup system than I expected for xss-lock, ie. this:

https://github.com/vincentbernat/i3wm-configuration/blob/master/dotfiles/systemd/xss-lock.service

actually calls that:

https://github.com/vincentbernat/i3wm-configuration/blob/master/bin/xss-lock

In the latter, they use XDG_SESSION_ID, I wonder if that might be the
trick I'm missing.

>>  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?

Yeah, that's what I'm doing, but then I get the error below:

>> 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.

It might be that my xterm is not started by i3.

I'm running i3 under gdm.

>> 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.

Okay, will try! I do see that XDG_SESSION_ID is a thing here...

> 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.

The post above does a lot of legwork, but basically, this is my
.xsession:

#!/bin/sh

. ~/.shenv

# import the stuff from .shenv, above
systemctl --user import-environment

# ... in favor of this
exec systemctl --user start --wait xsession.target

# vincent bernat instead does this:
#
#     systemctl --user daemon-reload
#     exec systemctl --user start --wait i3.service
#
# ... which i find a bit bizarre: why don't we start the
# xsession.target instead? why reload the daemon?

Enjoy!

-- 
A riot is the language of the unheard.
                         - Martin Luther King, Jr.

Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Bug#994762: warnings about session IDs Antoine Beaupre <anarcat@debian.org> - 2021-09-20 17:50 +0200
  Bug#994762: warnings about session IDs Ian Campbell <ijc@debian.org> - 2021-09-25 12:00 +0200
    Bug#994762: warnings about session IDs Antoine Beaupré <anarcat@debian.org> - 2021-09-27 15:40 +0200
      Bug#994762: warnings about session IDs Ian Campbell <ijc@debian.org> - 2021-10-17 08:40 +0200
        Bug#994762: warnings about session IDs Antoine Beaupré <anarcat@debian.org> - 2021-10-18 01:10 +0200
          Bug#994762: warnings about session IDs Ian Campbell <ijc@debian.org> - 2021-10-20 21:30 +0200
            Bug#994762: warnings about session IDs Antoine Beaupré <anarcat@debian.org> - 2021-10-21 02:20 +0200

csiph-web