xfce4-session issueshttps://gitlab.xfce.org/xfce/xfce4-session/-/issues2024-03-28T06:53:16Zhttps://gitlab.xfce.org/xfce/xfce4-session/-/issues/10xfce4-session doesn't care about it's child processes but makes them zombies2024-03-28T06:53:16ZBugzilla Migrationxfce4-session doesn't care about it's child processes but makes them zombies## Submitted by fra..@..il.com
Assigned to **Xfce Bug Triage**
**[Link to original bug (#9056)](https://bugzilla.xfce.org/show_bug.cgi?id=9056)**
## Description
I use xdm to log into my xfce session (default session, Xfce 4.10, De...## Submitted by fra..@..il.com
Assigned to **Xfce Bug Triage**
**[Link to original bug (#9056)](https://bugzilla.xfce.org/show_bug.cgi?id=9056)**
## Description
I use xdm to log into my xfce session (default session, Xfce 4.10, Debian unstable) and use $HOME/.xsessionrc to start some applications. If I exit/kill those applications after xfce startup, they remain as zombie processes, which wasn't the case with Xfce 4.8.
```
example in my .xsessionrc: command: unclutter &
part of pstree: before and after killing unclutter:
├─xdm─┬─Xorg───2*[{Xorg}]
│ └─xdm───x-session-manag─┬─Xsession
│ └─unclutter
ps x after killing unclutter:
13426 ? Z 0:00 [unclutter] `<defunct>`
```
Thanks,
Franky
Version: 4.10.0https://gitlab.xfce.org/xfce/xfce4-session/-/issues/8Unable to log in from xdm2024-03-28T06:53:16ZBugzilla MigrationUnable to log in from xdm## Submitted by Daniel Pielmeier
Assigned to **Xfce Bug Triage**
**[Link to original bug (#8841)](https://bugzilla.xfce.org/show_bug.cgi?id=8841)**
## Description
I am experiencing the same problem like here: http://mail.xfce.org/...## Submitted by Daniel Pielmeier
Assigned to **Xfce Bug Triage**
**[Link to original bug (#8841)](https://bugzilla.xfce.org/show_bug.cgi?id=8841)**
## Description
I am experiencing the same problem like here: http://mail.xfce.org/pipermail/xfce/2012-March/030209.html. When I try to start XFCE from the xdm log in screen it always switches back to the screen and does not log me in. When I start it from startx I am able to log in like normal.
I get the same error message in .xsession-errors like the reporter from the mailing list:
/usr/bin/startxfce4: X server already running on display :0
XDM authorization key matches an existing client!xfce4-session: Can not open display: .
Type 'xfce4-session --help' for usage.
If I can provide more information jut ask.
Version: 4.10.0
### See also
* http://bugs.gentoo.org/show_bug.cgi?id=420745https://gitlab.xfce.org/xfce/xfce4-session/-/issues/7app windows not restored to right workspace2024-03-28T06:53:16ZBugzilla Migrationapp windows not restored to right workspace## Submitted by Chris Bainbridge
Assigned to **Xfce Bug Triage**
**[Link to original bug (#8725)](https://bugzilla.xfce.org/show_bug.cgi?id=8725)**
## Description
With applications on different workspaces, I log out and XFCE saves...## Submitted by Chris Bainbridge
Assigned to **Xfce Bug Triage**
**[Link to original bug (#8725)](https://bugzilla.xfce.org/show_bug.cgi?id=8725)**
## Description
With applications on different workspaces, I log out and XFCE saves my session. On logging back in, all of the applications are restored, but in a single workspace.
Version: 4.8.0https://gitlab.xfce.org/xfce/xfce4-session/-/issues/4xfce4-session crashes at startup if session-screenshot is enabled2024-03-28T06:53:16ZBugzilla Migrationxfce4-session crashes at startup if session-screenshot is enabled## Submitted by Landry Breuil `@landry`
Assigned to **Xfce Bug Triage**
**[Link to original bug (#6885)](https://bugzilla.xfce.org/show_bug.cgi?id=6885)**
## Description
bt:
```
#0 0x00000002111e9924 in strlen () from /usr/lib/li...## Submitted by Landry Breuil `@landry`
Assigned to **Xfce Bug Triage**
**[Link to original bug (#6885)](https://bugzilla.xfce.org/show_bug.cgi?id=6885)**
## Description
bt:
```
#0 0x00000002111e9924 in strlen () from /usr/lib/libc.so.58.0
#1 0x0000000200fabc84 in g_strconcat () from /usr/local/lib/libglib-2.0.so.2600.0
#2 0x000000000010fb18 in xfsm_load_session_preview (name=0x212b725f0 "Default") at xfsm-global.c:154
#3 0x0000000000112380 in xfsm_manager_restart (manager=0x205f5a030) at xfsm-manager.c:764
#4 0x000000000010a1f0 in main (argc=1, argv=0xffffffffffff82e8) at main.c:265
#2 0x000000000010fb18 in xfsm_load_session_preview (name=0x212b725f0 "Default") at xfsm-global.c:154
154 resource = g_strconcat ("sessions/thumbs-", display_name,
(gdb) p display_name
$2 = (gchar *) 0x13176ae0 <Address 0x13176ae0 out of bounds>
152 display = gdk_display_get_default ();
153 display_name = xfsm_gdk_display_get_fullname (display);
```
for some reason display_name contains garbage, and code doesn't check for it.
solution.. either fix the code, or disable/remove it, as some consider it has security concerns...
Version: 4.7.1https://gitlab.xfce.org/xfce/xfce4-session/-/issues/3multiple copies of apps stored in session and launched on next login2024-03-28T06:53:16ZBugzilla Migrationmultiple copies of apps stored in session and launched on next login## Submitted by David Blewett
Assigned to **Xfce Bug Triage**
**[Link to original bug (#5123)](https://bugzilla.xfce.org/show_bug.cgi?id=5123)**
## Description
Created attachment 2240
snapshot of ~/.cache/sessions
I seem to be co...## Submitted by David Blewett
Assigned to **Xfce Bug Triage**
**[Link to original bug (#5123)](https://bugzilla.xfce.org/show_bug.cgi?id=5123)**
## Description
Created attachment 2240
snapshot of ~/.cache/sessions
I seem to be continually getting myself into a situation where xfce4-session tries to launch 100+ instances of xfdesktop on login. Attached is gzipped ~/.cache/sessions folder. The only thing I can think of is that I have the "Automatically save session on logout" activated. In order to try to troubleshoot this on my end, I've nuked ~/.config so I don't have that folder to go with that set of sessions. If it happens again, I'll add it.
I'm using Xfce 4.6 on Ubuntu Jaunty.
**Attachment 2240**, "snapshot of ~/.cache/sessions":
[cache.infinite.tar.gz](/uploads/5c4375335005cac98304557b2b806d17/cache.infinite.tar.gz)
Version: 4.6.0https://gitlab.xfce.org/xfce/xfce4-session/-/issues/2Xfce session respawns pam-panel-icon2024-03-28T06:53:15ZBugzilla MigrationXfce session respawns pam-panel-icon## Submitted by Tomasz Paweł Gajc
Assigned to **Xfce Bug Triage**
**[Link to original bug (#4837)](https://bugzilla.xfce.org/show_bug.cgi?id=4837)**
## Description
After few login/logouts you can notice that amount of running pam-...## Submitted by Tomasz Paweł Gajc
Assigned to **Xfce Bug Triage**
**[Link to original bug (#4837)](https://bugzilla.xfce.org/show_bug.cgi?id=4837)**
## Description
After few login/logouts you can notice that amount of running pam-panel-icon and pam-timestamps processes, grows up.These comes from the usermode package.Anyways this can be noticed only under xfce.
Sometimes there is a start race condition between stuff from /autostart and from saved last session. Simple fix would be to blacklist for session saving apps that are cast from /autostart.
Version: 4.5.93 (4.6 beta 3)https://gitlab.xfce.org/xfce/xfce4-session/-/issues/1xfce4-session has problems restoring gui-apps that pass cmdline args already ...2024-03-28T06:53:14ZBugzilla Migrationxfce4-session has problems restoring gui-apps that pass cmdline args already seperated by commas## Submitted by Terry Chan
Assigned to **Xfce Bug Triage**
**[Link to original bug (#2703)](https://bugzilla.xfce.org/show_bug.cgi?id=2703)**
## Description
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gec...## Submitted by Terry Chan
Assigned to **Xfce Bug Triage**
**[Link to original bug (#2703)](https://bugzilla.xfce.org/show_bug.cgi?id=2703)**
## Description
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20061224 Firefox/2.0.0.1
Build Identifier:
Using mrxvt (multi-session/windowed rxvt), xfce4-session cannot correctly restore this app between sessions because the invocation line for mrxvt already uses commas. So "mrxvt -ip 0,1,2,3" is the way I need to invoke mrxvt to restore my profiles for windows 0, 1, 2, and 3. However xfce4-session in .cache/session/xfce4-session-machinename:0 saves that commandline as:
"Client0_RestartCOmmand=mrxvt,-ip,0,1,2,3,-desktop,0,-geometry,132x55+80+8,-km,NOENC,-sm,-sid,hexdigitshere
but that is incorrect as it really needs to be:
'mrxvt','-ip','0,1,2,3','-desktop',...
With xfce4-session passing 'mrxvt','-ip','0','1','2','3' the mrxvt app correctly responds with no such command 1, no such command 2, no such command 3.
I'm sure other gui-apps can or will also pass cmdline args where some parameters are seperated by commas and then whitespace. This behavior in xfce4-session needs some sort of modification to allow for those apps that have already decided to use commas in their own cmdline args.
Reproducible: Always
Steps to Reproduce:
1. invoke "mrxvt -ip 0,1,2,3" from Run program dialog box
2. End session using Quit button on xfce4-panel
3. Restart xfce4 and watch mrxvt not be restored, error messages get sent to linux console where startxfce4 was invoked from.
Actual Results:
mrxvt says something to the effect of "no such command 1" and then "no such command 2" and then "no such command 3" and then no mrxvt app is started at all.
Expected Results:
"mrxvt -ip 0,1,2,3" should open the mrxvt app with 4 windowed/sessions started up.
Version: 4.4.x4.18.3Gaël BonithonGaël Bonithonhttps://gitlab.xfce.org/xfce/xfce4-session/-/issues/192Cannot prevent XFCE from saving session2024-03-27T07:40:48ZMichael HarveyCannot prevent XFCE from saving sessionI saved a session once, and decided I didn't want a saved session. In Session & Startup, I unchecked save session on logout and deleted all sessions. XFCE continues autosaving the session on logout, and auto-starting it on login.
I know...I saved a session once, and decided I didn't want a saved session. In Session & Startup, I unchecked save session on logout and deleted all sessions. XFCE continues autosaving the session on logout, and auto-starting it on login.
I know I can hack ~/.cache/sessions/ to be read-only, but that is a workaround. I might want to save a session in the future, so this is not a solution.
BTW, I found that after deleting all sessions, ~/.cache/sessions/ still existed and contained a thumbnails folder. Doing rm -rf ~/.cache/sessions got rid of it, and now it doesn't load. But a manual step mucking around on the command line should not be required. And how was it loading a session from thumbnails? I didn't look inside the thumbnails folder before deleting it so can't offer any more insight on this odd behavior.https://gitlab.xfce.org/xfce/xfce4-session/-/issues/149[Enhancement] The one screensaver/lock screen entry point (xflock4)2024-03-12T20:52:51ZAlexander Kurakinkuraga333@mail.ru[Enhancement] The one screensaver/lock screen entry point (xflock4)What does [`xflock4`](https://gitlab.xfce.org/xfce/xfce4-session/-/blob/xfce4-session-4.17.1/scripts/xflock4) do?
1. [Tries to run](https://gitlab.xfce.org/xfce/xfce4-session/-/blob/xfce4-session-4.17.1/scripts/xflock4#L29-37) the comma...What does [`xflock4`](https://gitlab.xfce.org/xfce/xfce4-session/-/blob/xfce4-session-4.17.1/scripts/xflock4) do?
1. [Tries to run](https://gitlab.xfce.org/xfce/xfce4-session/-/blob/xfce4-session-4.17.1/scripts/xflock4#L29-37) the command set in the session's xfconf channel.
2. [Tries to run](https://gitlab.xfce.org/xfce/xfce4-session/-/blob/xfce4-session-4.17.1/scripts/xflock4#L39-45) `xscreensaver-command`, `light-locker-command`, `xfce4-screensaver-command`.
Where is it called?
1. In `xfce4-session`: `Run xflock4 before suspending or hibernating the system` (BTW, [it](https://gitlab.xfce.org/xfce/xfce4-session/-/blob/xfce4-session-4.17.1/settings/xfce4-session-settings.ui#L271) is not true: `xfce4_screensaver_lock` [tries](https://gitlab.xfce.org/xfce/xfce4-session/-/blob/xfce4-session-4.17.1/xfce4-session/xfce-screensaver.c#L497) other options before [running `xflock4`](https://gitlab.xfce.org/xfce/xfce4-session/-/blob/xfce4-session-4.17.1/xfce4-session/xfce-screensaver.c#L553-560).)
2. [The same for `xfce4-power-manager`](https://gitlab.xfce.org/xfce/xfce4-power-manager/-/blob/xfce4-power-manager-4.17.0/src/xfce-screensaver.c#L569) (but [without a tooltip](https://gitlab.xfce.org/xfce/xfce4-power-manager/-/blob/xfce4-power-manager-4.17.0/data/interfaces/xfpm-settings.ui#L2068)).
3. [In `xfce4-panel`](https://gitlab.xfce.org/xfce/xfce4-panel/-/blob/xfce4-panel-4.17.4/plugins/actions/actions.c#L1110-1112).
4. As a [keyboard shortcut](https://gitlab.xfce.org/xfce/libxfce4ui/-/blob/libxfce4ui-4.17.8/libxfce4kbd-private/xfce4-keyboard-shortcuts.xml#L14).
5. In several plugins.
So, in pp. 3-5 it is called directly.
But in in pp. 1, 2, D-Bus-based screensavers are tried first. And then, `xflock4` is called (which [tries to call `xfce4-screensaver-command`](https://gitlab.xfce.org/xfce/xfce4-session/-/blob/xfce4-session-4.17.1/scripts/xflock4#L39-45) and [is a fork bomb](https://gitlab.xfce.org/xfce/xfce4-session/-/issues/120), among other things). As I understand, `xfce4-screensaver` provides a D-Bus-based screensaver entry point. So, `xflock` tries to call it one more time.
So: sometimes, `xflock4` is a screensaver/lock screen entry point. Sometimes, it's not. Sometimes, it will be recursive.
I have an idea: to have **one screensave/lock screen entry point**. Maybe in Bash, maybe in C. Which tries (or doesn't try - **according to command line/XfConf options**) to send relevant DBus messages, run relevant binaries.
Everything will call it. By one line. To one behavior only.
---
(list is updated) See also / possibly related / possibly will (partially) solve / is solving by:
* https://bugzilla.xfce.org/show_bug.cgi?id=11488,
* https://bugzilla.xfce.org/show_bug.cgi?id=15151,
* https://bugzilla.xfce.org/show_bug.cgi?id=15300,
* https://bugzilla.xfce.org/show_bug.cgi?id=16738,
* https://gitlab.xfce.org/xfce/xfce4-session/-/issues/15 / https://gitlab.xfce.org/xfce/libxfce4ui/-/issues/70,
* https://gitlab.xfce.org/xfce/xfce4-session/-/issues/17,
* https://gitlab.xfce.org/xfce/xfce4-session/-/issues/68,
* https://gitlab.xfce.org/xfce/xfce4-session/-/issues/69,
* https://gitlab.xfce.org/xfce/xfce4-session/-/issues/79,
* https://gitlab.xfce.org/xfce/xfce4-session/-/issues/108,
* https://gitlab.xfce.org/xfce/xfce4-session/-/issues/110,
* https://gitlab.xfce.org/xfce/xfce4-session/-/issues/115,
* https://gitlab.xfce.org/xfce/xfce4-session/-/issues/120,
* https://gitlab.xfce.org/xfce/xfce4-session/-/issues/148,
* https://gitlab.xfce.org/xfce/xfce4-session/-/issues/150,
* https://gitlab.xfce.org/xfce/xfce4-session/-/issues/175,
* https://gitlab.xfce.org/xfce/xfce4-session/-/issues/178,
* https://gitlab.xfce.org/xfce/xfce4-session/-/issues/182,
* https://gitlab.xfce.org/xfce/xfce4-session/-/merge_requests/20,
* https://gitlab.xfce.org/xfce/xfce4-session/-/merge_requests/23,
* https://gitlab.xfce.org/xfce/xfce4-session/-/merge_requests/24,
* https://gitlab.xfce.org/xfce/xfce4-session/-/merge_requests/41,
* https://gitlab.xfce.org/xfce/xfce4-session/-/commit/7c846f57a5776f831d2777687b6d4b154c55b505,
* https://gitlab.xfce.org/xfce/xfce4-session/-/commit/ec4f05ba944085c00798f91fe53b7a975ea496a0,
* https://gitlab.xfce.org/xfce/xfce4-power-manager/-/issues/5,
* https://gitlab.xfce.org/xfce/xfce4-power-manager/-/issues/7,
* https://gitlab.xfce.org/xfce/xfce4-power-manager/-/issues/12,
* https://gitlab.xfce.org/xfce/xfce4-power-manager/-/issues/19,
* https://gitlab.xfce.org/xfce/xfce4-power-manager/-/issues/51 / https://gitlab.xfce.org/xfce/libxfce4ui/-/issues/63,
* https://gitlab.xfce.org/xfce/xfce4-power-manager/-/issues/65,
* https://gitlab.xfce.org/xfce/xfce4-power-manager/-/issues/68,
* https://gitlab.xfce.org/xfce/xfce4-power-manager/-/issues/71,
* https://gitlab.xfce.org/xfce/xfce4-power-manager/-/issues/81,
* https://gitlab.xfce.org/xfce/xfce4-power-manager/-/issues/83,
* https://gitlab.xfce.org/xfce/xfce4-power-manager/-/issues/84,
* https://gitlab.xfce.org/xfce/xfce4-power-manager/-/issues/113,
* https://gitlab.xfce.org/xfce/xfce4-power-manager/-/issues/127 / https://gitlab.xfce.org/xfce/libxfce4ui/-/issues/64,
* https://gitlab.xfce.org/xfce/xfce4-power-manager/-/issues/142,
* https://gitlab.xfce.org/xfce/xfce4-power-manager/-/issues/153,
* https://gitlab.xfce.org/xfce/xfce4-power-manager/-/issues/187,
* https://gitlab.xfce.org/xfce/xfce4-power-manager/-/issues/202,
* https://gitlab.xfce.org/xfce/xfce4-power-manager/-/issues/209,
* https://gitlab.xfce.org/xfce/xfce4-power-manager/-/issues/210,
* https://gitlab.xfce.org/xfce/xfce4-power-manager/-/merge_requests/24,
* https://gitlab.xfce.org/xfce/xfce4-power-manager/-/merge_requests/32,
* https://gitlab.xfce.org/xfce/xfce4-power-manager/-/merge_requests/43,
* https://gitlab.xfce.org/xfce/xfce4-power-manager/-/merge_requests/50,
* https://gitlab.xfce.org/xfce/xfce4-power-manager/-/merge_requests/52,
* https://gitlab.xfce.org/apps/xfce4-screensaver/-/issues/1 (and many duplicates),
* https://gitlab.xfce.org/apps/xfce4-screensaver/-/issues/12 (and many duplicates),
* https://gitlab.xfce.org/apps/xfce4-screensaver/-/issues/20,
* https://gitlab.xfce.org/apps/xfce4-screensaver/-/issues/28,
* https://gitlab.xfce.org/apps/xfce4-screensaver/-/issues/36,
* https://gitlab.xfce.org/apps/xfce4-screensaver/-/issues/53,
* https://gitlab.xfce.org/apps/xfce4-screensaver/-/issues/75,
* https://gitlab.xfce.org/apps/xfce4-screensaver/-/issues/78,
* https://gitlab.xfce.org/apps/xfce4-screensaver/-/issues/96,
* https://gitlab.xfce.org/apps/xfce4-screensaver/-/issues/107,
* https://gitlab.xfce.org/apps/xfce4-screensaver/-/issues/111,
* https://gitlab.xfce.org/apps/xfce4-screensaver/-/issues/129,
* https://gitlab.xfce.org/apps/xfce4-screensaver/-/issues/130,
* https://gitlab.xfce.org/apps/xfce4-screensaver/-/issues/133,
* https://gitlab.xfce.org/apps/xfce4-screensaver/-/issues/134,
* https://gitlab.xfce.org/apps/xfce4-screensaver/-/issues/140,
* https://gitlab.xfce.org/apps/xfce4-screensaver/-/issues/143,
* https://gitlab.xfce.org/apps/xfce4-screensaver/-/merge_requests/21,
* https://gitlab.xfce.org/apps/xfce4-screensaver/-/commit/b4ede5236656532a3c05925c1909c7aabb07f733,
* https://gitlab.xfce.org/apps/xfce4-screensaver/-/commit/9df3ad56d7c607dbdd101afc3ff6bcce6d565832,
* https://gitlab.xfce.org/xfce/xfwm4/-/issues/541,
* https://gitlab.xfce.org/xfce/xfwm4/-/issues/715,
* https://gitlab.xfce.org/xfce/xfwm4/-/issues/753,
* https://gitlab.xfce.org/xfce/libxfce4ui/-/issues/62,
* https://gitlab.xfce.org/xfce/libxfce4ui/-/merge_requests/97,
* https://gitlab.xfce.org/xfce/libxfce4ui/-/merge_requests/98,
* https://gitlab.xfce.org/xfce/libxfce4ui/-/merge_requests/99,
* https://gitlab.xfce.org/xfce/libxfce4ui/-/commit/a25f036b656546f2d5ad840ea2aa1a49d8ece232,
* https://gitlab.xfce.org/xfce/libxfce4ui/-/commit/32f761266658e2f59093af259655e44efecf31a9,
* https://gitlab.xfce.org/xfce/xfce4-panel/-/issues/55,
* https://forum.xfce.org/viewtopic.php?id=16953,
* https://gitlab.gnome.org/GNOME/gtk/-/issues/3659,
* https://bugs.launchpad.net/ubuntu/+source/xscreensaver/+bug/1858027.4.19.1Gaël BonithonGaël Bonithonhttps://gitlab.xfce.org/xfce/xfce4-session/-/issues/190Git: xfce4-session refuses to build with --guess-what (disable wayland)2024-03-11T08:34:59ZPatronosGit: xfce4-session refuses to build with --guess-what (disable wayland)May you please have a look?
```
make[2]: Leaving directory '/root/rpmbuild/BUILD/xfce4-session-4.19.1/xfsm-shutdown-helper'
make[2]: *** No rule to make target 'xfce-wayland.desktop.in', needed by 'xfce-wayland.desktop'. Stop.
make[2]:...May you please have a look?
```
make[2]: Leaving directory '/root/rpmbuild/BUILD/xfce4-session-4.19.1/xfsm-shutdown-helper'
make[2]: *** No rule to make target 'xfce-wayland.desktop.in', needed by 'xfce-wayland.desktop'. Stop.
make[2]: *** Waiting for unfinished jobs....
make[2]: Entering directory '/root/rpmbuild/BUILD/xfce4-session-4.19.1'
/usr/bin/msgfmt --desktop --template xfce.desktop.in -d ./po -o xfce.desktop
make[2]: Leaving directory '/root/rpmbuild/BUILD/xfce4-session-4.19.1'
make[1]: *** [Makefile:608: all-recursive] Error 1
make: *** [Makefile:498: all] Error 2
```
No wayland! No xfce-wayland.desktop after make dist.4.19.2Gaël BonithonGaël Bonithonhttps://gitlab.xfce.org/xfce/xfce4-session/-/issues/181Please provide an xfce-portals.conf for xdg-desktop-portal >= 1.172023-12-22T19:46:29ZSimon McVittiePlease provide an xfce-portals.conf for xdg-desktop-portal >= 1.17## Context
[xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal) is a D-Bus service providing access to desktop-environment-related functionality for applications. It was originally written to provide sandboxed apps (Flatp...## Context
[xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal) is a D-Bus service providing access to desktop-environment-related functionality for applications. It was originally written to provide sandboxed apps (Flatpak, Snap, etc.) with limited access to resources outside their sandbox with user consent, but
is increasingly also used by non-sandboxed apps (.deb or equivalent) as a desktop-environment-independent interface to features like screen-sharing that are otherwise difficult to implement in a cross-desktop way.
x-d-p itself does not contain any desktop-environment-specific code, and is shared between all desktop environments. However, a lot of what it does requires use of desktop-environment-specific mechanisms or user interface conventions. To allow for that, it contacts a desktop-specific backend ([x-d-p-gtk](https://github.com/flatpak/xdg-desktop-portal-gtk), [x-d-p-gnome](https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome), [x-d-p-kde](https://invent.kde.org/plasma/xdg-desktop-portal-kde/) and so on) and uses that to provide its full functionality.
XFCE doesn't currently have a desktop-specific backend of its own, although there is some discussion in #159 about whether it should. Until/unless it does, there are a couple of options for what XFCE could use:
* [x-d-p-gtk](https://github.com/flatpak/xdg-desktop-portal-gtk) was originally written for GNOME, but most of its GNOME-specific bits have now been moved into x-d-p-gnome, and it's common to use it in desktop environments that don't have their own portal backend. It currently uses GTK 3 dialogs for its UI.
* [x-d-p-xapp](https://github.com/linuxmint/xdg-desktop-portal-xapp) was written by Linux Mint developers and claims to support Cinnamon, Mate and XFCE - although Mate developers seem to be unhappy about it, and I don't know whether any XFCE developers have been involved in its development or testing. It doesn't implement the Lockdown interface on XFCE, and the Screenshot implementation for XFCE seems rather half-finished (I'm not sure whether it really works outside Cinnamon in practice).
## The issue
In older versions of x-d-p, if x-d-p does not find a suitable backend for the current desktop environment, it would fall back to trying *any* backend. This meant that all backends needed to be prepared to run in an environment where their functionality cannot actually work, which is rarely tested, leading to undesired situations where a desktop environment's backend can cause bugs (such as crashes or slow application startup) while running different desktop environments.
In the x-d-p 1.17.x prereleases and the upcoming 1.18.x stable release, this has been changed to give desktop environment developers more control over the backends they use. As described in <https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst>, the recommendation is now that each desktop environment should provide a file listing its preferred backends, similar to the one added by <https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/95/diffs> in GNOME. This mechanism is similar to `mimeapps.list`, and it makes sense to configure it in some "reasonably central" desktop package - in GNOME, it's gnome-session that took responsibility, and in XFCE, xfce4-session seems like a reasonable place.
A simple implementation would be to write this into `${datadir}/xdg-desktop-portal/xfce-portals.conf`:
```
[preferred]
default=gtk;
```
or if you want to use the `-xapp` implementation if available, maybe something like this:
```
[preferred]
default=gtk;
org.freedesktop.impl.portal.Inhibit=xapp;gtk;
org.freedesktop.impl.portal.Wallpaper=xapp;gtk;
```
Most desktop environments implement most portal backends in the same service, but it's possible to divide up responsibility between multiple D-Bus services. If someone writes a `-xfce` backend that installs an `xfce.portal` file, then you'd also want to add `xfce` to one or more of these lists. Similarly, if Thunar wants to register as a backend for the FileChooser interface (thunar#547), you'd probably want something like `org.freedesktop.impl.portal.FileChooser=thunar;gtk;`. See https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/95/diffs for a real-world example of a non-trivial portal configuration like this.4.18.4Gaël BonithonGaël Bonithonhttps://gitlab.xfce.org/xfce/xfce4-session/-/issues/186Icons of xfce4-session-logout are blurry when window scaling is greater than ...2023-09-27T18:29:02ZManuel GrießmayrIcons of xfce4-session-logout are blurry when window scaling is greater than 1 on hidpi screens![session_logout_icons](/uploads/e27264c94f328cde7e44427e5e405964/session_logout_icons.png)
@Tamaranch Coud be something for you because you did a great job with the icons of the xfce4-weather-plugin :)![session_logout_icons](/uploads/e27264c94f328cde7e44427e5e405964/session_logout_icons.png)
@Tamaranch Coud be something for you because you did a great job with the icons of the xfce4-weather-plugin :)https://gitlab.xfce.org/xfce/xfce4-session/-/issues/163XFCE4 won't Suspend or Hibernate2023-09-20T11:57:49ZRichard MyersXFCE4 won't Suspend or HibernateWhen I try the Suspend (or Hibernate) in the Actions Buttons plugin, I get a popup window:
![image](/uploads/5525be20d9e2c369958f9426ca2ff2d0/image.png)
Failed to run action "Suspend"
GDBus.Error:org.xfce.SessionManager.Error.Failed: ...When I try the Suspend (or Hibernate) in the Actions Buttons plugin, I get a popup window:
![image](/uploads/5525be20d9e2c369958f9426ca2ff2d0/image.png)
Failed to run action "Suspend"
GDBus.Error:org.xfce.SessionManager.Error.Failed: Failed to lock the screen.
Suspending via:
**$ systemctl suspend**
works fine.
Also, locking works fine using the Action Button, "Lock Screen"
If I run:
**$ xfce4-session-logout --suspend**
I get a popup window:
"Received error while trying to log out
GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: Type of
message, "(yb)", does not match expected type "(b")""
and the following is output on the command line:
"Received error while trying to log out, error was GDBus.Error:org.xfce.SessionManager.Error.Failed: Failed to lock the screen."
**$ xfconf-query -c xfce4-session -p /general/LockCommand** outputs:
dm-tool lock
**$ dm-tool lock**
works fine.
```
Fedora F37 versions:
libxfce4util-4.16.0-6.fc37.x86_64
libxfce4ui-4.16.1-3.fc37.x86_64
xfce4-panel-4.16.5-1.fc37.x86_64
xfce4-settings-4.16.5-1.fc37.x86_64
xfce4-session-4.16.0-6.fc37.x86_64
xfce4-dict-0.8.4-5.fc37.x86_64
xfce4-dict-plugin-0.8.4-5.fc37.x86_64
xfce4-pulseaudio-plugin-0.4.4-1.fc37.x86_64
xfce4-xkb-plugin-0.8.3-2.fc37.x86_64
xfce4-battery-plugin-1.1.4-4.fc37.x86_64
xfce4-clipman-plugin-1.6.2-5.fc37.x86_64
xfce4-cpufreq-plugin-1.2.7-2.fc37.x86_64
xfce4-cpugraph-plugin-1.2.6-2.fc37.x86_64
xfce4-datetime-plugin-0.8.1-5.fc37.x86_64
xfce4-diskperf-plugin-2.7.0-2.fc37.x86_64
xfce4-eyes-plugin-4.6.0-2.fc37.x86_64
xfce4-fsguard-plugin-1.1.2-5.fc37.x86_64
xfce4-genmon-plugin-4.1.1-5.fc37.x86_64
xfce4-mailwatch-plugin-1.3.0-5.fc37.x86_64
xfce4-mount-plugin-1.1.5-5.fc37.x86_64
xfce4-mpc-plugin-0.5.2-7.fc37.x86_64
xfce4-netload-plugin-1.4.0-4.fc37.x86_64
xfce4-notes-plugin-1.9.0-5.fc37.x86_64
xfce4-notifyd-0.6.4-1.fc37.x86_64
xfce4-power-manager-4.16.0-6.fc37.x86_64
xfce4-sensors-plugin-1.4.3-5.fc37.x86_64
xfce4-smartbookmark-plugin-0.5.2-5.fc37.x86_64
xfce4-systemload-plugin-1.3.1-4.fc37.x86_64
xfce4-time-out-plugin-1.1.2-4.fc37.x86_64
xfce4-timer-plugin-1.7.1-7.fc37.x86_64
xfce4-verve-plugin-2.0.1-5.fc37.x86_64
xfce4-wavelan-plugin-0.6.3-2.fc37.x86_64
xfce4-weather-plugin-0.11.0-4.fc37.x86_64
xfce4-places-plugin-1.8.3-1.fc37.x86_64
xfce4-volumed-0.2.3-30.fc37.x86_64
xfce4-terminal-1.0.4-2.fc37.x86_64
xfce4-appfinder-4.16.1-5.fc37.x86_64
xfce4-about-4.16.1-3.fc37.x86_64
xfce4-taskmanager-1.5.4-2.fc37.x86_64
xfce4-dev-tools-4.16.0-5.fc37.x86_64
libxfce4util-devel-4.16.0-6.fc37.x86_64
libxfce4ui-devel-4.16.1-3.fc37.x86_64
xfce4-panel-devel-4.16.5-1.fc37.x86_64
xfce4-screensaver-4.16.0-8.fc37.x86_64
xfce4-screenshooter-1.10.3-1.fc37.x86_64
xfce4-screenshooter-plugin-1.10.3-1.fc37.x86_64
xfce4-whiskermenu-plugin-2.7.2-1.fc37.x86_64
```
I've seen other reports of this issue, with no resolution offered. I'm bringing it up again, and hoping for some resolution.https://gitlab.xfce.org/xfce/xfce4-session/-/issues/109Envoking xfsm_logout_dialog Core Dumps xfce4-session2023-09-20T11:51:57ZScott KrallEnvoking xfsm_logout_dialog Core Dumps xfce4-sessionThe odd time, when I click the "Log Out" button to power off/restart the computer, instead of the logout dialog window appearing, the lightdm login appears. Seemed to start happening about 2-3 months ago and is random, but only when I u...The odd time, when I click the "Log Out" button to power off/restart the computer, instead of the logout dialog window appearing, the lightdm login appears. Seemed to start happening about 2-3 months ago and is random, but only when I use the Log Out button. I'm using Arch and have xfce4-session 4.16.0 installed.
These error's appear every time it happens.
```
Process 541 (xfce4-session) of user 1000 dumped core.
Stack trace of thread 541:
#0 0x00007fe9be91cc84 n/a (libgdk-3.so.0 + 0x87c84)
#1 0x00007fe9be922b5b n/a (libgdk-3.so.0 + 0x8db5b)
#2 0x00007fe9be922ed2 n/a (libgdk-3.so.0 + 0x8ded2)
#3 0x00007fe9be8c713b gdk_display_get_event (libgdk-3.so.0 + 0x3213b)
#4 0x00007fe9be922a54 n/a (libgdk-3.so.0 + 0x8da54)
#5 0x00007fe9be380f9c g_main_context_dispatch (libglib-2.0.so.0 + 0x53f9c)
#6 0x00007fe9be3d4a49 n/a (libglib-2.0.so.0 + 0xa7a49)
#7 0x00007fe9be380503 g_main_loop_run (libglib-2.0.so.0 + 0x53503)
#8 0x00007fe9bead4a3f gtk_dialog_run (libgtk-3.so.0 + 0x13fa3f)
#9 0x0000563c9722842a xfsm_logout_dialog (xfce4-session + 0x2042a)
#10 0x0000563c97229512 n/a (xfce4-session + 0x21512)
#11 0x0000563c972296f6 n/a (xfce4-session + 0x216f6)
#12 0x00007fe9be380ea0 g_main_context_dispatch (libglib-2.0.so.0 + 0x53ea0)
#13 0x00007fe9be3d4a49 n/a (libglib-2.0.so.0 + 0xa7a49)
#14 0x00007fe9be380503 g_main_loop_run (libglib-2.0.so.0 + 0x53503)
#15 0x00007fe9beb6b58f gtk_main (libgtk-3.so.0 + 0x1d658f)
#16 0x0000563c9721a177 main (xfce4-session + 0x12177)
#17 0x00007fe9be164b25 __libc_start_main (libc.so.6 + 0x27b25)
#18 0x0000563c9721a3ee _start (xfce4-session + 0x123ee)
Stack trace of thread 590:
#0 0x00007fe9be23137f __poll (libc.so.6 + 0xf437f)
#1 0x00007fe9be3d49d8 n/a (libglib-2.0.so.0 + 0xa79d8)
#2 0x00007fe9be380503 g_main_loop_run (libglib-2.0.so.0 + 0x53503)
#3 0x00007fe9be5be558 n/a (libgio-2.0.so.0 + 0x102558)
#4 0x00007fe9be3aefb1 n/a (libglib-2.0.so.0 + 0x81fb1)
#5 0x00007fe9be315299 start_thread (libpthread.so.0 + 0x9299)
#6 0x00007fe9be23c053 __clone (libc.so.6 + 0xff053)
Stack trace of thread 10465:
#0 0x00007fe9be236a9d syscall (libc.so.6 + 0xf9a9d)
#1 0x00007fe9be3cef5b g_cond_wait_until (libglib-2.0.so.0 + 0xa1f5b)
#2 0x00007fe9be3508b3 n/a (libglib-2.0.so.0 + 0x238b3)
#3 0x00007fe9be3b1ccb n/a (libglib-2.0.so.0 + 0x84ccb)
#4 0x00007fe9be3aefb1 n/a (libglib-2.0.so.0 + 0x81fb1)
#5 0x00007fe9be315299 start_thread (libpthread.so.0 + 0x9299)
#6 0x00007fe9be23c053 __clone (libc.so.6 + 0xff053)
Stack trace of thread 589:
#0 0x00007fe9be23137f __poll (libc.so.6 + 0xf437f)
#1 0x00007fe9be3d49d8 n/a (libglib-2.0.so.0 + 0xa79d8)
#2 0x00007fe9be37e6f1 g_main_context_iteration (libglib-2.0.so.0 + 0x516f1)
#3 0x00007fe9be37e742 n/a (libglib-2.0.so.0 + 0x51742)
#4 0x00007fe9be3aefb1 n/a (libglib-2.0.so.0 + 0x81fb1)
#5 0x00007fe9be315299 start_thread (libpthread.so.0 + 0x9299)
#6 0x00007fe9be23c053 __clone (libc.so.6 + 0xff053)
Stack trace of thread 10464:
#0 0x00007fe9be236a9d syscall (libc.so.6 + 0xf9a9d)
#1 0x00007fe9be3cef5b g_cond_wait_until (libglib-2.0.so.0 + 0xa1f5b)
#2 0x00007fe9be3508b3 n/a (libglib-2.0.so.0 + 0x238b3)
#3 0x00007fe9be3b1ccb n/a (libglib-2.0.so.0 + 0x84ccb)
#4 0x00007fe9be3aefb1 n/a (libglib-2.0.so.0 + 0x81fb1)
#5 0x00007fe9be315299 start_thread (libpthread.so.0 + 0x9299)
#6 0x00007fe9be23c053 __clone (libc.so.6 + 0xff053)
```
And .xsession-errors log
```
(xfce4-session:540): Gdk-CRITICAL **: 21:38:29.583: gdk_event_set_source_device: assertion 'GDK_IS_DEVICE (device)' failed
(xfce4-session:540): Gdk-CRITICAL **: 21:38:29.584: gdk_device_get_n_axes: assertion 'GDK_IS_DEVICE (device)' failed
(xfce4-session:540): Gdk-CRITICAL **: 21:38:29.584: gdk_event_set_source_device: assertion 'GDK_IS_DEVICE (device)' failed
ICE default IO error handler doing an exit(), pid = 703, errno = 11
(xfce4-panel:656): libxfce4ui-WARNING **: 21:38:29.810: ICE I/O Error
(xfce4-panel:656): libxfce4ui-WARNING **: 21:38:29.810: Disconnected from session manager.
(xfwm4:643): libxfce4ui-WARNING **: 21:38:29.810: ICE I/O Error
(xfsettingsd:648): libxfce4ui-WARNING **: 21:38:29.810: ICE I/O Error
(xfwm4:643): libxfce4ui-WARNING **: 21:38:29.810: Disconnected from session manager.
(xfsettingsd:648): libxfce4ui-WARNING **: 21:38:29.810: Disconnected from session manager.
(xfdesktop:666): libxfce4ui-WARNING **: 21:38:29.810: ICE I/O Error
(xfdesktop:666): libxfce4ui-WARNING **: 21:38:29.810: Disconnected from session manager.
(wrapper-2.0:675): pulseaudio-plugin-WARNING **: 21:38:29.811: Disconected from the PulseAudio server. Attempting to reconnect in 5 seconds.
Gdk-Message: 21:38:29.813: xfwm4: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Gdk-Message: 21:38:29.814: xfsettingsd: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Gdk-Message: 21:38:29.814: xfce4-panel: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Gdk-Message: 21:38:29.814: Thunar: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Gdk-Message: 21:38:29.815: wrapper-2.0: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Gdk-Message: 21:38:29.815: wrapper-2.0: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Gdk-Message: 21:38:29.815: wrapper-2.0: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Gdk-Message: 21:38:29.815: wrapper-2.0: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Gdk-Message: 21:38:29.815: wrapper-2.0: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Gdk-Message: 21:38:29.816: blueman-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
Gdk-Message: 21:38:29.816: xfce4-notifyd: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
Gdk-Message: 21:38:29.816: wrapper-2.0: Fatal IO error 104 (Connection reset by peer) on X server :0.
X connection to :0.0 broken (explicit kill or server shutdown).
Gdk-Message: 21:38:29.816: nm-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
Gdk-Message: 21:38:29.816: polkit-gnome-authentication-agent-1: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
Gdk-Message: 21:38:29.817: pamac-tray: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
Gdk-Message: 21:38:29.818: blueman-tray: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
Gdk-Message: 21:38:29.836: xfdesktop: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
```https://gitlab.xfce.org/xfce/xfce4-session/-/issues/182Going to sleep with lockscreen causes sleep to be delayed until lock process ...2023-09-18T13:32:52ZKristian AngelovGoing to sleep with lockscreen causes sleep to be delayed until lock process finishesxfce4-session 4.18.3 (Xfce 4.18) on Arch.
This is a regression from a previous version.
My setup is as follows: xfconf setting `/general/LockCommand` is set to `xsecurelock`
I sleep the system (either through the panel button, hotkey o...xfce4-session 4.18.3 (Xfce 4.18) on Arch.
This is a regression from a previous version.
My setup is as follows: xfconf setting `/general/LockCommand` is set to `xsecurelock`
I sleep the system (either through the panel button, hotkey or lid).
The system turns on the lockscreen but does not go to sleep.
I enter my password.
The system immediately goes to sleep.
I'm unsure which version I was on prior but it was likely before this summer (I would guess maybe 4.15 or 4.16).
It appears that xfce waits until xflock4 returns to actually begin sleeping.
I've also tested `slock` which exhibits the same behavior
Best regardshttps://gitlab.xfce.org/xfce/xfce4-session/-/issues/180Xfce display settings launches after resuming from sleep2023-09-05T13:40:24ZLucas SouzaXfce display settings launches after resuming from sleepOn a fresh installon version 4.18 the Xfce display settings launches after resuming from sleep, i found the workaround disabling the xfce4-display-settings default shortcuts fixed the problem.
I found the workaround here: https://bugs.l...On a fresh installon version 4.18 the Xfce display settings launches after resuming from sleep, i found the workaround disabling the xfce4-display-settings default shortcuts fixed the problem.
I found the workaround here: https://bugs.launchpad.net/ubuntu/+source/xfce4-settings/+bug/1264629https://gitlab.xfce.org/xfce/xfce4-session/-/issues/177XDG_* environment variables don't end up in the environment of processes star...2023-08-04T20:56:26ZBrian TarriconeXDG_* environment variables don't end up in the environment of processes started by dbus-daemon or systemdSome people set `XDG_CACHE_HOME` (for example) to a location other than `~/.cache`. On a system where the systemd user session is started by PAM when the user logs in, that systemd process won't know about any of the `XDG_*` env vars. ...Some people set `XDG_CACHE_HOME` (for example) to a location other than `~/.cache`. On a system where the systemd user session is started by PAM when the user logs in, that systemd process won't know about any of the `XDG_*` env vars. If some services like `tumblerd` or `xfce4-notifyd` are started via systemd, they will not know about the settings of these variables.
Even if those services are started by DBus activation, if the dbus-daemon session bus process is started by the systemd user session (instead of in the Xfce startup scripts), dbus-daemon won't have those environment variables, and will start these services without them.
One possible solution is by using the `systemctl import-environment` command (presumably in our `xinitrc` script) to ask systemd to import a list of env vars that we specify. Then those env vars will be passed on to services systemd starts.
This still doesn't completely solve the problem of DBus activation: presumably dbus-daemon will have already been started by systemd before our startup script runs. However, DBus activation does support associating a systemd unit with the activation, and will (instead of starting the service directly) instead start the systemd unit; this would solve that problem.
So to summarize, I think we should do two things:
1. In our `xinitrc` script, after setting up the various `XDG_` variables (as well as `DESKTOP_SESSION`, I guess), we should run `systemctl import-environment $LIST_OF_VARS`.
2. We should ensure all our services that support DBus activation also include the `SystemdService` key to point to a systemd unit that can be used to start the service, and those services will need to ship systemd unit files as well, if they aren't already).
This won't be perfect: ~~any third-party app that relies on DBus activation, and does not provide a systemd unit file, will not benefit from this fix.~~ (Edit: looks like there's `dbus-update-activation-environment` for this, which *also* updates systemd's env vars when passed the `--systemd` option) And there's still the potential problem of any service that gets started by systemd before our `xinitrc` script runs. But hopefully this should fix up at least some of the issues.
~~Edit^2: Hm, seems like passing `--systemd` to `dbus-update-activation-environment` doesn't actually work. I guess we can just call both programs.~~ no, it does, looks like we just didn't properly `export` something in our startup script...4.18.4Brian TarriconeBrian Tarriconehttps://gitlab.xfce.org/xfce/xfce4-session/-/issues/104XDG_CONFIG_HOME is not respected2023-08-04T10:46:40ZLuna CatkinsXDG_CONFIG_HOME is not respectedI'm using the lightdm display manager to run xfce4-session.
lightdm sources ~/.profile and ~/.xprofile. I'm using this to set `XDG_CONFIG_HOME` to `$HOME/config` (note the missing dot).
Via `ps eww` I've verified that in the processes ...I'm using the lightdm display manager to run xfce4-session.
lightdm sources ~/.profile and ~/.xprofile. I'm using this to set `XDG_CONFIG_HOME` to `$HOME/config` (note the missing dot).
Via `ps eww` I've verified that in the processes of xfce4-session, xfsettingsd, xfdesktop, etc., XDG_CONFIG_HOME indeed has the correct value. However, everything still reads from the default ~/.config directory, causing the default configuration to be used.
I am on XFCE 4.16.
As a temporary workaround I've symlinked .config to config. This is really not my preferred solution, though.
I believe I have narrowed it down to `xfconfd`, which is started by dbus, not receiving XDG_CONFIG_HOME properly.
Indeed. running `dbus-update-activation-environment --systemd XDG_CONFIG_HOME="$XDG_CONFIG_HOME"` as an initialization step causes everything to work as indtended.https://gitlab.xfce.org/xfce/xfce4-session/-/issues/150[Enhancement] xflock4: try to call dm-tool, too2023-06-18T08:59:46ZAlexander Kurakinkuraga333@mail.ru[Enhancement] xflock4: try to call dm-tool, tooMaybe it's a good idea to try to call `dm-tool lock` in `xflock4`, too. It blocks display as such as other called tools.
Thanks!Maybe it's a good idea to try to call `dm-tool lock` in `xflock4`, too. It blocks display as such as other called tools.
Thanks!https://gitlab.xfce.org/xfce/xfce4-session/-/issues/120Fork bomb possible with xflock42023-05-22T17:16:07ZLudovic BellièreFork bomb possible with xflock4If the setting `/general/LockCommand` is set to `xflock4`, [the script](https://gitlab.xfce.org/xfce/xfce4-session/-/blob/53ef72c40f6afd8170a7f7c37937576773ca8a35/scripts/xflock4) will gladfully call itself until all resources on the hos...If the setting `/general/LockCommand` is set to `xflock4`, [the script](https://gitlab.xfce.org/xfce/xfce4-session/-/blob/53ef72c40f6afd8170a7f7c37937576773ca8a35/scripts/xflock4) will gladfully call itself until all resources on the host are used.
A workaround would be to ignore `$LOCK_CMD` if the resolution of the command is the script itself.
I assume something like this would solve the issue, but it is probably too naive.
```sh
LOCK_CMD="xflock4"
if [ "$(realpath "$0")" = "$(which "$LOCK_CMD")" ]; then
LOCK_CMD=""
fi
```4.19.1Gaël BonithonGaël Bonithon