Arch Linux

How do you start GNOME?

gdm via systemd. I run xmonad and load several useful gnomish services using the following script run by the gdm xsession file:

#!/bin/bash

export DE='gnome'
export VDPAU_DRIVER=r600

trayer --edge top --align right --SetDockType true --SetPartialStrut true --width 5 --height 12 --transparent true --tint 0x000000 &
/usr/lib/gnome-settings-daemon/gnome-settings-daemon &
gnome-screensaver &
gtk-redshift -l38.89:-77.03 -t6000:3700 &
if [ -x /usr/bin/gnome-power-manager ]; then
sleep 1
gnome-power-manager &
fi
if [ -x /usr/bin/nm-applet ]; then
nm-applet --sm-disable &
fi

if [ -e $HOME/.xmodmap ]; then
xmodmap $HOME/.xmodmap
fi

unclutter &
/usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1 &

eval $(gnome-keyring-daemon)
export GNOME_KEYRING_CONTROL SSH_AUTH_SOCK GPG_AGENT_INFO GNOME_KEYRING_PID
exec xmonad

Additional data point: If I start Nautilus under the default Gnome session (gnome-shell with dbus 1.8.6-3) it functions correctly.

Any idea why there would be a regression for other configurations? There's nothing obvious in the logs for dbus or nautilus.

i added a patch, but i seriously doubt that it is the problem.

could you have a look in "journalctl -b" to see if there are any relevant messages? also have a look in ~/.xsession-errors, and try starting the broken apps from a terminal to see if they spit out anything to the console.

Filtered journalctl output is attached. No .xsession-errors file is generated.

Nautilus produces no CLI output at startup and nothing during the broken operations. It isn't clear from the nautilus man page how one could output debugging or verbose information.

I see starting these messages after upgrading to dbus 1.6.8-3:
dbus[389]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
dbus-daemon[389]: dbus[389]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
dbus-daemon[389]: dbus[389]: [system] Activated service 'org.freedesktop.nm_dispatcher' failed: The permission of the setuid helpe
r is not correct
dbus[389]: [system] Activated service 'org.freedesktop.nm_dispatcher' failed: The permission of the setuid helper is not correct

I have not experienced issues though (KDE).

Observation:
dbus-daemon is not running as root.

/usr/share/dbus-1/system-services/org.freedesktop.nm_dispatcher.service wants to run as root with User=root.

The permission error message is DBUS_ERROR_SPAWN_PERMISSIONS_INVALID which is set in check_permissions at bus/activation-helper.c:167 (called from check_dbus_user which is called from run_launch_helper)
Three cases need to be passed before the check returns success:
- The specified DBus user needs to be valid. dbus is valid: OK
- Real user ID of process should equal the dbus user: `ps u -p 389` shows dbus: OK
- Effective user ID should be root: presumably OK too for /usr/lib/dbus-1.0/dbus-daemon-launch-helper?

Could it have anything to do with systemd-user-session.patch?

Just to be certain, could someone try to reproduce this problem with:

https://dev.archlinux.org/~tomegun/dbus-1.6.8-4.1-i686.pkg.tar.xz
https://dev.archlinux.org/~tomegun/dbus-1.6.8-4.1-x86_64.pkg.tar.xz

?

Please test -5 in testing. Should work now.

dbus[389]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
dbus-daemon[389]: dbus[389]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
dbus-daemon[389]: dbus[389]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
dbus[389]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'

-5 works for me.

GVFS plugin regression (smb, ssh, udisks2) still present in -5 in my configuration.

@nocko: if you add 'dbus-launch --sh-syntax --exit-with-session' to your scritp, does that make everything work as before?

eval $(dbus-launch --sh-syntax --exit-with-session) added to my xsession script fixes the problems.

Thanks for your help!

Tom, just a quick question whether the solution here is a (necessary?) hack or something we should have all the time from here on.

@ngoonee: the most recent version of dbus reinstated the old behaviour (by adding back /etc/X11/xinitrc.d/30-dbus), so the workaround shown here is not necessary. Maybe we will revisit this in the future (as the xinitrc.d stuff is a bit weird imho), but for the time being this will continue working as before.