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.
