You are not logged in.
Hi,
I'm running xfce 4.12 on debian buster and sometimes login as root. But if I click on a desktop launcher the program doesn't start and after about 15 seconds I get an error dialog box stating "Failed to run "xxxxx", "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, ...".
A similar installation running on debian stretch does not have this problem.
Does anybody have a solution to this problem.
Thanks,
Steven
Last edited by phelum (2020-12-05 21:39:40)
Offline
Hello and welcome!
I think we'll need some more info, like...
- how are you starting your session? from the command line or using a display manager/graphical login manager?
- is dbus running?
- do you have a .xsession-errors file in your home directory?
Etc. Then I'm sure some of our fellow users will be able an willing to help!
Offline
Hello and welcome!
I think we'll need some more info, like...
- how are you starting your session? from the command line or using a display manager/graphical login manager?
- is dbus running?
- do you have a .xsession-errors file in your home directory?Etc. Then I'm sure some of our fellow users will be able an willing to help!
Hi,
I have systemd set-default multi-user.target and I've tried different ways of starting xfce. "startx" is my normal method. I've also tried " startx /etc/xdg/xfce4/xinitrc /usr/bin/xfce4-session" and other variants with the standard /etc/X11/xinit/xinitrc and also /usr/bin/startxfce4. The result is always that xfce runs but I can't start any program from a desktop icon. However starting from a desktop icon is fine if I'm logged in as a normal user. On another PC running debian stretch rather than buster I have no problems with any user including root.
On the bad installation I noticed it didn't have the 20dbus_xdg-runtime file in the /etc/X11/Xsession.d directory so I copied it from the good system. Comparing .xsession-errors on the bad installation with the good installation I notice that DBUS_SESSION_BUS_ADDRESS isn't loaded when starting the X session and the .xsessions-errors file shows it is set to "unix:abstract=/tmp/dbus-sTrU5070fQ,guid=6efcf77cbe1fd65445bf108d5fc32575" whereas on the good system it is loaded when starting the Xsession and is set to "unix:path=/run/user/0/bus". The .xsessions-errors file also shows problems at the start:
Xsession: X session started for root at Sun 29 Nov 10:40:52 AEDT 2020
dbus-update-activation-environment: setting DISPLAY=:0
dbus-update-activation-environment: warning: error sending to systemd: org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.systemd1 exited with status 1
localuser:root being added to access control list
dbus-update-activation-environment: setting GTK_MODULES=gail:atk-bridge
dbus-update-activation-environment: warning: error sending to systemd: org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.systemd1 exited with status 1
dbus-update-activation-environment: setting QT_ACCESSIBILITY=1
dbus-update-activation-environment: warning: error sending to systemd: org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.systemd1 exited with status 1
dbus-update-activation-environment: setting MAIL=/var/mail/root
dbus-update-activation-environment: setting LANGUAGE=en_AU:en
dbus-update-activation-environment: setting USER=root
dbus-update-activation-environment: setting XDG_SESSION_TYPE=tty
dbus-update-activation-environment: setting SHLVL=1
dbus-update-activation-environment: setting HOME=/root
dbus-update-activation-environment: setting HUSHLOGIN=FALSE
dbus-update-activation-environment: setting GTK_MODULES=gail:atk-bridge
dbus-update-activation-environment: setting DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-nD800S89FY,guid=a2152ba411d91283b28593fe5fc2e004
dbus-update-activation-environment: setting LOGNAME=root
dbus-update-activation-environment: setting JOURNAL_STREAM=8:23520
dbus-update-activation-environment: setting _=/usr/bin/xinit
dbus-update-activation-environment: setting XDG_SESSION_CLASS=user
dbus-update-activation-environment: setting TERM=linux
dbus-update-activation-environment: setting WINDOWPATH=4
dbus-update-activation-environment: setting PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
dbus-update-activation-environment: setting INVOCATION_ID=a7d9f829eadd4b7689c39fa270d84cab
dbus-update-activation-environment: setting XDG_RUNTIME_DIR=/run/user/0
dbus-update-activation-environment: setting DISPLAY=:0
dbus-update-activation-environment: setting LANG=en_AU.UTF-8
dbus-update-activation-environment: setting SHELL=/bin/bash
dbus-update-activation-environment: setting QT_ACCESSIBILITY=1
dbus-update-activation-environment: setting GPG_AGENT_INFO=/run/user/0/gnupg/S.gpg-agent:0:1
dbus-update-actiDBUS_SESSION_BUS_ADDRESSDBUS_SESSION_BUS_ADDRESSvation-environment: setting PWD=/root
dbus-update-activation-environment: setting XDG_DATA_DIRS=/usr/share/xfce4:/usr/local/share/:/usr/share/
dbus-update-activation-environment: warning: error sending to systemd: org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.systemd1 exited with status 1
xfce4-session-Message: 10:40:52.423: SSH authentication agent is already running
gpg-agent[1160]: WARNING: "--write-env-file" is an obsolete option - it has no effect
gpg-agent: a gpg-agent is already running - not starting a new one
(xfce4-session:1075): xfce4-session-WARNING **: 10:40:52.425: gpg-agent returned no PID in the variables
There are lots of parse errors reported by Thunar.
Connection failure: Connection refused
pa_context_connect() failed: Connection refused
** (light-locker:1185): ERROR **: 10:40:52.866: Environment variable XDG_SESSION_PATH not set. Is LightDM running?
I'm not sure why DBUS_SESSION_BUS_ADDRESS is loaded before starting the X session. I'll try clearing it first.
Note that I also have icewm installed on this bad installation.
I've just done some checking and starting xfce with a normal user gives me the same errors in .xsessions-errors as when starting under root. So it appears that the differences above are because the good installation is running stretch not buster.
The only differences on this bad machine are some extra lines in the root log:
dbus-update-activation-environment: setting JOURNAL_STREAM=8:39393
dbus-update-activation-environment: setting INVOCATION_ID=412987a8d19c4a3bb3bd7328e93e2c9c
(xfce4-session:8461): xfce4-session-WARNING **: 17:36:28.618: xfsm_manager_load_session: Something wrong with /root/.cache/sessions/xfce4-session-PC222:1, Does it exist? Permissions issue?
Connection failure: Connection refused
pa_context_connect() failed: Connection refused
The last warning about opening a cache/sessions file turns up in the good run (normal user) but isn't followed by the Connection failure line and the pa_contect line.
Cheers,
Steven
Last edited by phelum (2020-11-29 07:25:57)
Offline
I think you're right in that this is a dbus issue.
dbus-update-activation-environment: warning: error sending to systemd: org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.systemd1 exited with status 1
...and
I notice that DBUS_SESSION_BUS_ADDRESS isn't loaded when starting the X session and the .xsessions-errors file shows it is set to "unix:abstract=/tmp/dbus-sTrU5070fQ,guid=6efcf77cbe1fd65445bf108d5fc32575" whereas on the good system it is loaded when starting the Xsession and is set to "unix:path=/run/user/0/bus".
The later is the proper correct set up.
I came across this old-ish debian bug report that looks very similar and talks about a dbus-user-session package - you might want to check if its installed.
It might also be worth creating a test account on your system to see if the problem persists with a new profile.
As for the .xsession-errors messages:
(xfce4-session:8461): xfce4-session-WARNING **: 17:36:28.618: xfsm_manager_load_session: Something wrong with /root/.cache/sessions/xfce4-session-PC222:1, Does it exist? Permissions issue?
...basically a warning that you are not saving sessions - it can be ignored.
pa_context_connect() failed: Connection refused
...looks like a pulseaudio message - may be a side effect of the dbus issue.
Please remember to mark your thread [SOLVED] to make it easier for others to find
--- How To Ask For Help | FAQ | Developer Wiki | Community | Contribute ---
Offline
I think you're right in that this is a dbus issue.
As for the .xsession-errors messages:(xfce4-session:8461): xfce4-session-WARNING **: 17:36:28.618: xfsm_manager_load_session: Something wrong with /root/.cache/sessions/xfce4-session-PC222:1, Does it exist? Permissions issue?
...basically a warning that you are not saving sessions - it can be ignored.
pa_context_connect() failed: Connection refused
...looks like a pulseaudio message - may be a side effect of the dbus issue.
Hi,
Thanks for the reply and the info about the insignificant warnings.
I now see that buster sets up the DBus sockets differently compared to stretch.
I installed the dbus-user-session package and left the 20dbus_xdg-runtime file in /etc/X11/Xsession.d. Now the DBUS_SESSION_BUS_ADDRESS entry is the same as when running under stretch. But I still can't execute from a desktop icon.
I do notice a warning in xsessions-errors:
gpg-agent: a gpg-agent is already running - not starting a new one
Could this be part of the problem ?
There is no problem with any user account on this PC, except for root.
Cheers,
Steven
Last edited by phelum (2020-11-30 06:12:51)
Offline
Hi,
I still haven't got anywhere with this problem.
In summary, with the debian xfce 4.12 package running on debian buster x64 and when logged in as user root I can't start programs from user desktop icons (referencing .desktop files in /root/Desktop). However when running xfce 4.12 on debian stretch or when running the LinuxMint version I have no problems. So the problem seems to be limited to debian buster.
Can anybody get desktop icons to work properly when logged in as user root and running debian buster ? I'm trying to ascertain if the problem is specific to my PC or if it's a common issue.
Thanks,
Steven
Offline
Are the thunar versions the same between the different instances? Its the thunarx API that manages the icons on the desktop. There have been some dbus bug fixes around "sudo thunar" in the past couple of years that might underlie the problem.
Here is one such bug report: https://bugzilla.xfce.org/show_bug.cgi?id=15149, fixed in version 1.8.5, and buster seems to run 1.8.4.
Indeed, manually building 1.8.5 on a buster VM fixes the issue. Notes below:
apt build-dep thunar
<download and uncompress from archive.xfce.org/src>
./configure --prefix=/usr
make
make install
<re-login>
Please remember to mark your thread [SOLVED] to make it easier for others to find
--- How To Ask For Help | FAQ | Developer Wiki | Community | Contribute ---
Offline
Are the thunar versions the same between the different instances? Its the thunarx API that manages the icons on the desktop. There have been some dbus bug fixes around "sudo thunar" in the past couple of years that might underlie the problem.
Hi,
Yes, the thunar versions are the same as is the entire package. The desktop files for both the root user and the normal user are the same (except for the user:group).
I've tried to make the entire 4.14 xfce package but some of the files in the debian buster release are too old. So I made thunar 1.8.9. It seemed a bit risky installing the 4.14 thunar in a 4.12 system. The new thunar does start programs from desktop icons when logged in as a normal user. With user root it does show the "untrusted executable" warning but after I click "mark executable" nothing happens. I don't get the 20 second delay followed by "can't start mc.desktop" dialog box as I did with the old thunar. And the icon is now labelled "MC" rather than "mc.desktop" so it looks like thunar is now recognizing it properly.
Update: Things now work properly. I created some icons using the "Create Launcher..." function and they do work. Thanks for your help here. I think the problem is fixed.
Cheers,
Steven
Last edited by phelum (2020-12-04 10:00:14)
Offline
and sometimes login as root
Back in my UNIX days and all throughout linux I've always remembered my basic training which was to never, ever use a GUI as root.
Usually GUIs are designed on this principle. I.e. they might rely on permission conventions, where a double click performs a "change everything" there's no guarantee the developer specifically excluded root from the possible outcomes, they will often rely on the assumed boundaries of a user login.
I'm sure you are well aware and your use case is spot on. But I thought it might serve other users who find this thread to mention this.
Offline
[ Generated in 0.024 seconds, 7 queries executed - Memory usage: 598.38 KiB (Peak: 615.22 KiB) ]