/etc/X11/Xsession.d/65snappy cause XRDP error

[Hiroo MATSUMOTO]

This is different issue with XRDP connection error to GNOME3 Unity.
This will affect XRDP connection to LXDE, Xfce and MATE Desktop.

$ sudo apt-get install -y xubuntu-desktop
$ echo "xfce4-session" > ~/.xsession
$ sudo reboot
# RDP connect after boot and then cause error.

/etc/X11/Xsession.d/65snappy always add /var/lib/snapd/desktop to
XDG_DATA_DIRS however /var/lib/snapd/desktop is not exists.

If starting Xsession by XRDP with correct XDG_DATA_DIRS,
e.g. /usr/share/xfce4, XDRP will work.

But if starting Xsession with empty XDG_DATA_DIRS, Xsession by XRDP
will use incorrect XDG_DATA_DIRS and cause crash or unavailable
desktop item.

XRDP on ubuntu 15.10 will work with empty XDG_DATA_DIRS.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: snapd 2.0.2
ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6
Uname: Linux 4.4.0-21-generic x86_64
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
Date: Tue Apr 26 16:35:01 2016
InstallationDate: Installed on 2016-04-24 (1 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
ProcEnviron:
 TERM=screen
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=ja_JP.UTF-8
 SHELL=/bin/bash
SourcePackage: snapd
UpgradeStatus: No upgrade log present (probably fresh install)
modified.conffile..etc.X11.Xsession.d.65snappy: [modified]
mtime.conffile..etc.X11.Xsession.d.65snappy: 2016-04-26T16:23:37.137298

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "snapd-check-XDG_DATA_DIRS.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[André Colomb (acolomb)]

I was also bitten by this bug, causing the GNOME session to fail completely on login. gnome-settings-daemon did not find any GSettings schemas installed, therefore aborting the session via TRAP signal. After much investigation, the snapd package seems to be the root cause, because the /etc/X11/Xsession.d/65snappy script manages to overwrite $XDG_DATA_DIRS.

After adding an upstart job to the session that just prints out $XDG_DATA_DIRS, it turned out to be set as XDG_DATA_DIRS=:/var/lib/snapd/desktop. Notice it is missing the default locations like /usr/share.

No idea why neither the 55gnome-session_gnomerc nor 60x11-common_xdg_path scripts initially set a value for the variable (which is probably a separate bug). However, the 65snappy script should not unconditionally append to the variable.

The appropriate GNOME and Xfce Xsession scripts take it even one step further than the proposed patch, and append the default paths (/usr/local/share/:/usr/share/) to the XDG_DATA_DIRS variable in case it is being set for the first time. Otherwise, the standard paths will not be searched anymore. I suggest doing the same for the 65snappy script.

[André Colomb (acolomb)]

Improved patch that respects the XDG default fallback paths when initially setting XDG_DATA_DIRS.

Rebased against current version 2.0.3.

[Oliver Grawert (ogra)]

please revert the last iteration, setting the default dirs here is surely wrong (not snapd's job and if 60x11-common_xdg_path did not set them before there is something else wrong) ...

[Oliver Grawert (ogra)]

also the first patch could use some quoting around $XDG_DATA_DIRS in the assignment :)

[Gustavo Niemeyer (niemeyer)]

Thanks André. We'll likely need to do something along those lines, even including the default system paths for the time being. This sounds like a bug elsewhere in the system indeed, but we'll fix that separately rather than waiting for it.

[André Colomb (acolomb)]

I think adding the standard paths in case $XDG_DATA_DIRS was not set before is mandatory. It's also how the other Xsession scriptlets work.

Consider a user who does not care about the paths (like me). Quoting from the XDG Base Directory Specification [1]: "If $XDG_DATA_DIRS is either not set or empty, a value equal to /usr/local/share/:/usr/share/ should be used." If any script needs to add to the paths, it must follow this recommendation in order to not mess up previously working applications. The first patch's approach effectively REPLACES the default paths with only the snappy path. IMO removing or changing any default paths should be a conscious choice reserved for the power user.

[1]: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables

Regarding my own case, I traced it back to a very rude and messy script added by the "cadence" package from the unofficial KXStudio repositories. It prepends a command to the $STARTUP Xsession variable, which causes the check in 55gnome-session_gnomerc to fail. Afterwards, 60x11-common_xdg_path does a different check for GNOME and skips the XDG_DATA_DIRS setting. A comment there claims that "gnome is already added if gnome-session installed".

Maybe the check in 60x11-common_xdg_path should be changed to not explicitly check for GNOME, and possibly 55gnome-session_gnomerc should look at the $DESKTOP_SESSION instead of $STARTUP. Please share any opinions on this, then I will open the respective bug reports.

[jklasdf (jjj11x)]

This also prevents KDE from starting correctly: http://bugs.launchpad.net/ubuntu/+source/plasma-desktop/+bug/1576500

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Hiroo MATSUMOTO (hiroom2-mail)]

A snapd 2.0.5 in xenial-proposed works for XRDP connection.
Thanks all.

[James Johnston (mail-codenest)]

In case anyone else is searching on this issue, this bug also causes icons to mysteriously go missing all over the whole GUI in more lightweight window managers / desktop environments like: jwm, icewm. Removal of 65snappy "fixed" the problem. On a Ubuntu Server 16.04 installation:

# Skip the screensaver recommendation:
sudo apt-get install icewm menu xauth --no-install-recommends
sudo apt-get install tightvncserver
sudo apt-get install xrdp

And then connect via xrdp and you will see all the icons that are supposed to be there are missing... until you remove or fix the offending 65snappy.

Glad to see there is a patch on the way, thank you everyone!

[Oliver Grawert (ogra)]

65snappy is fine, check bug #1576500 for a proper fix in 60x11-common_xdg_path so that the defaults get applied even if DESKTOP_SESSION is not set (which i.e. installing only icewm doesnt set)...

[James Johnston (mail-codenest)]

@Oliver Grawert: I don't think that 65snappy is fine based on my understanding of the spec. As per: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

"$XDG_DATA_DIRS defines the preference-ordered set of base directories to search for data files in addition to the $XDG_DATA_HOME base directory. The directories in $XDG_DATA_DIRS should be seperated with a colon ':'.

----> If $XDG_DATA_DIRS is either not set or empty, a value equal to /usr/local/share/:/usr/share/ should be used. <----"

So it sounds like it's perfectly legal for XDG_DATA_DIRS to be empty/not set, in which case a default is assumed. But if you set it, it does not say to append any defaults to the list - therefore if you set it, you would want to manually ensure those entries are in the list.

In light of the above spec, 65snappy has two problems: (1) it just appends to the list, leaving a leading ":" even if there was something in there, (2) if the list is empty, it does not put in these defaults before assigning it.

Examining my copy of 60x11-common_xdg_path indicates the following:
 * "Add additionnal xdg paths depending on selected desktop session" --- clearly the purpose is to add some non-default paths, not specify the default ones for other broken packages like snapd.
 * If you follow the logic, it's clear that the ONLY time this script will modify XDG_DATA_DIRS is if it is needing to add "/usr/share/"$DESKTOP_SESSION"" to the list of paths. However, unlike snapd, it checks to see if the variable is empty, and if so, is careful to add the default paths as per the spec.

In no way do I interpret 60x11-common_xdg_path as being a script to work around other scripts that don't correctly follow the XDG base dir spec.

Asking 60x11-common_xdg_path, which is from a different package, to work around the brokenness of another package (snapd), sounds very fragile to me.

[Oliver Grawert (ogra)]

@james 60x11-common_xdg_path is the one that is supposed to set the system defaults for the var and it does not do so when DESKTOP_SESSION is not set, which is a bug (namely bug #1576500 )...

the scripts are sourced in order so when 65snappy runs the variable should have content, it isnt the job of 65snappy to set the default, it should only append to the default that the system did set before.

[André Colomb (acolomb)]

@oliver I have to strongly agree with James here. No package's scripts should implicitly depend on the functionality of another, but rather each script should honor the standard independently. The complexity and runtime overhead for the check does not matter in this case.

Not having $XDG_DATA_DIRS set at all is a very common and normal situation, since the spec explicitly mandates the default paths. Only if there is a strong need for an additional path IMO justifies setting the variable at all. That is correctly implemented in the individual scripts (GNOME, XFCE) and they all honor the spec's default paths. So does the -proposed version of snapd.

The only fix needed for 60x11-common_xdg_path IMO is to not set anything, since each desktop environment should do it on their own. Special-casing GNOME in there is even more of a no-go.

[Symax (ayourk)]

I use Fluxbox and nodm packages. Neither one have a DESKTOP_SESSION by default.

[Michael Vogt (mvo)]

The etc/X11/Xsession.d/65snappy got fixed some time ago - is this still a problem with a snapd version > 2.0.5?

[Hiroo MATSUMOTO (hiroom2-mail)]

This was fixed with a snapd version > 2.0.5.