Bug#994762: warnings about session IDs
On 2021-10-20 20:22:08, Ian Campbell wrote:
> On Sun, 2021-10-17 at 19:07 -0400, Antoine Beaupré wrote:
>> And I can confirm it works, or at least does not warn.
>
> Excellent, thanks.
>
> Is the diff as simple as:
>
>$ git diff
>diff --git a/doc/xss-lock.service b/doc/xss-lock.service
>index 52086c8..37d733e 100644
>--- a/doc/xss-lock.service
>+++ b/doc/xss-lock.service
>@@ -4,7 +4,7 @@ PartOf=graphical-session.target
>
> [Service]
> Type=simple
>-ExecStart=/usr/bin/xss-lock -l -s ${GRAPHICAL_SESSION_ID} -- i3lock
>+ExecStart=/usr/bin/xss-lock -l -s ${XDG_SESSION_ID} -- i3lock
>
> [Install]
> WantedBy=graphical-session.target
That sounds about right, here's my current service file.
--
Your injured body has become the burden of your digital soul.
- Yin Aiwen, 2013, The Massage is the Medium
[Unit]
Description=xss-lock - use external locker as X screen saver
Documentation=man:xss-lock(1)
PartOf=graphical-session.target
Wants=xset.service
After=xset.service
[Service]
Type=simple
EnvironmentFile=/home/anarcat/.xsecurelock.env
# note that when this works, document in #994762
ExecStart=/usr/bin/xss-lock --verbose --transfer-sleep-lock
--session=${XDG_SESSION_ID} --notifier /usr/libexec/xsecurelock/dimmer --
xsecurelock
[Install]
WantedBy=graphical-session.target
Bug#994762: warnings about session IDs
On Sun, 2021-10-17 at 19:07 -0400, Antoine Beaupré wrote:
> And I can confirm it works, or at least does not warn.
Excellent, thanks.
Is the diff as simple as:
$ git diff
diff --git a/doc/xss-lock.service b/doc/xss-lock.service
index 52086c8..37d733e 100644
--- a/doc/xss-lock.service
+++ b/doc/xss-lock.service
@@ -4,7 +4,7 @@ PartOf=graphical-session.target
[Service]
Type=simple
-ExecStart=/usr/bin/xss-lock -l -s ${GRAPHICAL_SESSION_ID} -- i3lock
+ExecStart=/usr/bin/xss-lock -l -s ${XDG_SESSION_ID} -- i3lock
[Install]
WantedBy=graphical-session.target
?
Bug#994762: warnings about session IDs
On 2021-10-17 07:31:09, Ian Campbell wrote: > (sorry for the delay) > > On Mon, 2021-09-27 at 09:27 -0400, Antoine Beaupré wrote: >> > 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... > > Thanks. And I can confirm it works, or at least does not warn. >> > 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: > > Thanks. It's probably a bit of a broad setup/concept for the xss-lock > docs but it's something I may try for myself at some point. Yeah, it's an emerging idea, and probably very niche, ie. restricted to non-GNOME/KDE/etc sessions... But I still think it's kind of cool. Oh, and xss-lock is awesome, thanks. Feels like a bit of too many moving parts and I'm somewhat worried about it not working sometimes, but it's much snappier than xscreensaver and "feels" a little more secure because the way the components are setup. And now that I think of it, I wonder if those processes couldn't be better sandboxed... Ideas? a. -- When I came back to the United States, I decided that if you could use propaganda for war, you could certainly use it for peace. And "propaganda" got to be a bad word because of the Germans using it, so what I did was to try and find some other words so we found the words "public relations". - Edward Bernays
Bug#994762: warnings about session IDs
(sorry for the delay) On Mon, 2021-09-27 at 09:27 -0400, Antoine Beaupré wrote: > > 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... Thanks. > > 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: Thanks. It's probably a bit of a broad setup/concept for the xss-lock docs but it's something I may try for myself at some point. Ian.
Bug#994762: warnings about session IDs
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 00 > > 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.
Bug#994762: warnings about session IDs
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 00 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/
Bug#994762: warnings about session IDs
Package: xss-lock Version: 0.3.0-10+b1 Severity: normal I'm not sure how to use this program. 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. 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 Somehow it still seems to work, however, so I'm not sure what to do with those warnings... -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xss-lock depends on: ii libc62.31-13 ii libglib2.0-0 2.66.8-1 ii libxcb-screensaver0 1.14-3 ii libxcb-util1 0.4.0-1+b1 ii libxcb1 1.14-3 xss-lock recommends no packages. xss-lock suggests no packages. -- debconf-show failed
