Hey, using xfce4-session 4.13.2 I no longer get a prompt to unlock my gnome keyring on login. I also cannot get it to prompt when trying to open the keyring in seahorse. Reverting to xfce4-session Version 4.12.1 fixes this issue.
Any warnings or errors in your ~/.xsession-errors log file?
No such file is created, so no. I did compile with --enable-debug=yes, do I have to do something else? I am starting xfce with xinit, is this of any significance?
I tried launching xfce with LightDM. Here everything works and I do get Warnings in my .xsession-errors file as well. I also realised that when starting with xinit, Notifications do not work. The setting dialog tells me, that no notification service is started. I also could not open or in any other way interact with the xfce4-pulseaudio panel applet. And as I already observed, no errors or warnings are written into the .xsession-errors file.
Maybe something to do with D-Bus not being properly initialized. Instead try the command "startxfce4" which is used by LightDM also.
My .xinitrc already invokes startxfce4 so the problem has to lie somewhere else.
A list of things which may help to debug this issue: - redirect the terminal output: startxfce4 > ~/.xsession-errors 2>&1 - add "export XFSM_VERBOSE=1" to your .xinitrc and after a relog check ~/.xfce4-session.verbose-log - compare environmental variables with the "env" command
Created attachment 8660 startxfce4 errors
Created attachment 8661 Verbose session log Here is the two files. I don't really know how to interpret all of it. One additional thing: pinentry did not work even when using LightDM. I am not really sure how much time I can invest in this bug the coming days, I will probably just revert to 4.12 for the time.
I did a quick test and noticed that DISPLAY is not set for the systemd user environment. $ systemctl --user show-environment ... $ systemctl --user set-environment DISPLAY=:0.0 $ systemctl --user start xfce4-notifyd.service
Hi, I'm using Fedora 30 (xfce4-session-4.13.2-2.fc30) and lightdm. I created a new user with system-config-users and the Xfce session doesn't work for it. It shows just the wallpaper (inherited from the display manager) and nothing works; I need to kill the user processes from tty. I think the first time I tried to login .xsession.errors showed some DBus error and subsequent tries now give only: $ cat .xsession-errors Failed to import environment: Access denied Maybe it's related? I'll try the workarounds here.
Sergio, that sounds exactly like the following issue: https://askbot.fedoraproject.org/en/question/132253/xfce-login-stuck/
Thank you so much Theo, sorry for hacking this bug report and for not searching the web beforehand. I't just that when using Fedora one always has to troubleshoot the system a bit until it starts running smoothly and I was a bit unused to that...
Okay, university finally loosened its grip. I found this bugreport in the debian bugtracker: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842712 and after putting dbus-update-activation-environment --systemd --all into my .xinitrc, everything works just fine. Now I still don't know the underlying issue but it may only be some configuration problem within arch linux?
So, I guess this report can be closed as invalid for xfce4-session..? (which ofc doesn't imply that anything from your conversation is irrelevant in general, just not a bug in xfce4-session)
I have not looked further into this issue, but I confirmed it in comment #9 while using Xubuntu. The openSUSE package includes this patch: https://build.opensuse.org/package/view_file/X11:xfce/xfce4-session/xfce4-session-systemd-user-addons.patch
Oh ok, I guess I didn't read closely enough. Wanna craft a patch?
Created attachment 8780 Based on openSUSE patch
Comment on attachment 8780 Based on openSUSE patch From 0de6ed2141b39d7441ef338d4d9dba8c90a80d8c Mon Sep 17 00:00:00 2001 From: "Maurizio Galli (MauG)" <maurizio.galli@gmail.com> Date: Tue, 16 Jul 2019 16:56:38 +0800 Subject: [PATCH] Set XAUTHLOCALHOSTNAME in systemd user session Fixes Bug #15440 --- scripts/xinitrc.in.in | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/scripts/xinitrc.in.in b/scripts/xinitrc.in.in index 6562a117..ff044edf 100755 --- a/scripts/xinitrc.in.in +++ b/scripts/xinitrc.in.in @@ -78,6 +78,12 @@ cat /dev/null $XRESOURCES | xrdb -merge - # load local modmap test -r $HOME/.Xmodmap && xmodmap $HOME/.Xmodmap +# if XAUTHLOCALHOSTNAME is not set in systemd user session, starting of xfce4-notifyd, DISPLAY etc. will fail +if command -v systemctl >/dev/null 2>&1 && systemctl --user list-jobs >/dev/null 2>&1; then # user session is running + dbus-update-activation-environment --systemd XAUTHLOCALHOSTNAME=$XAUTHLOCALHOSTNAME +fi + + # check if we start xfce4-session with ck-launch-session. this is only # required for starting from a console, not a login manager if test "x$XFCE4_SESSION_WITH_CK" = "x1"; then
Created attachment 8781 xfce4-session-systemd-user-addons
Maurizio Galli (MauG) referenced this bugreport in commit 2cc75280995a9f77a63d50443800aa6c089a7a85 Set XAUTHLOCALHOSTNAME in systemd user session (Bug #15440) https://git.xfce.org/xfce/xfce4-session/commit?id=2cc75280995a9f77a63d50443800aa6c089a7a85
Thanks for the patch!
I think the checks for systemctl existence and running systemd user session are not necessary. Take a look: https://gitlab.freedesktop.org/dbus/dbus/blob/master/tools/dbus-update-activation-environment.c When not on Linux, dbus-update-activation-environment will ignore --systemd option. And on Linux when systemd user session is not running, it will also just emit a warning and continue. Hence just call dbus-update-activation-environment --systemd XAUTHLOCALHOSTNAME=$XAUTHLOCALHOSTNAME >/dev/null 2>&1 and done. It works this way since day 1: https://gitlab.freedesktop.org/dbus/dbus/commit/2a6cefbc3bd3ed9392603da6a76b49c0dcba7e0d
Always calling dbus-update-activation-environment will help non-systemd systems too, no? I mean this variable should be passed to dbus-daemon environment when systemd is *not* used to activates session services...
Sure, it would just log an error message ("not on Linux, ignoring --systemd argument") but since stdout/stderr is ignored, i guess it would be fine. Sadly, i would consider this sloppy practice. Ignoring stderr feels wrong... but i guess we're in an era where nobody cares. So imo, what's been commited for now is cleaner. Check first that systemd is actually used, then update its environment. Unless of course there are apps relying on XAUTHLOCALHOSTNAME being defined, and handling the case where systemd is not running, in which case why using --systemd at all and not setting the env var in all cases ?
(In reply to Landry Breuil from comment #24) > Unless of course there are apps relying on XAUTHLOCALHOSTNAME being defined, > and handling the case where systemd is not running, in which case why using > --systemd at all and not setting the env var in all cases ? The variable is set in both dbus-daemon --session and systemd --user environments. dbus-update-activation-environment(1): > dbus-update-activation-environment updates the list of environment variables > used by dbus-daemon --session when it activates session services without using > systemd. > > With the --systemd option, if an instance of systemd --user is available on > D-Bus, it **also** updates the list of environment variables used by systemd > --user when it activates user services, including D-Bus session services for > which dbus-daemon has been configured to delegate activation to systemd. This > is very similar to the import-environment command provided by systemctl(1)). So the question is: does this bug affect non-Linux or non-systemd systems (where dbus-daemon itself spawns xfce4-notifyd and other user stuff)? If it does, then the systemctl checks are not cleaner, they are wrong.