Copy paste issue: xsel: Can't open display: (null)

snap
1

Seeing this issue on openSUSE Tumbleweed where a snap I maintain is suddenly failing to write to the clipboard.

xsel: Can't open display: (null)
: Bad file descriptor

It is a python cli application accessing the clipboard via pyperclip with xsel as the backend.

$ snap --version
snap                 2.47.1-3.17
snapd                2.47.1-3.17
series               16
opensuse-tumbleweed  20201121
kernel               5.9.8-2-default

Works in Ubuntu, even when running under Wayland. Also works under GNOME Xorg in openSUSE TW.

Here is a link to the snapcraft.yaml of the project:

Searching the forum I found one somewhat relevant thread. But xhost + local: makes no difference in this case.

2

I have no idea why but changing xsel to the alternative xclip solved the issue.

3

The issue is back with a new error message.

Error: Can’t open display: 0

4

did you try running the snappy-debug tool (from the snappy-debug snap) in a second terminal while trying to use your snap ? that should show if there are any interfaces missing (i doubt the x11 plug alone is enough to get access to all desktop ressources)

5

I did not known that tool existed. Thanks for the tip! That would have been very useful the first time around when I had problems setting up the permissions to get access to the clipboard.

Unfortunately it does not show anything while I am using the problematic snap. I did have some problems running the command “the standard way” though. Maybe that is why I am not seeing anything?

$ snappy-debug
ERROR: '/var/log/syslog' does not exist. Aborting. Please choose another file with
       --log-file or try redirecting journalctl. Eg:
ERROR: $ sudo journalctl --output=short --follow --all | sudo snappy-debug
$ sudo journalctl --output=short --follow --all | sudo /snap/bin/snappy-debug
kernel.printk_ratelimit = 0
6

It sounds a lot like you’re running into this:

Mutter in GNOME 3.38 was changed to not listen on the abstract namespace X11 socket when running a Wayland session. Snapd’s x11 support relied on access to this socket. This change was reverted in Mutter 3.38.2, but your distro may not have picked up that update yet.

Things work in Ubuntu because releases before 20.10 ship older releases of GNOME, and for 20.10 we back ported the mutter fix.

On the snapd side, we’ve made changes to make the non-abstract socket available to snaps, which should make them functional on systems where the abstract socket is not available. That change landed in snapd 2.48 though, which is newer than what you appear to be running.

So the solution comes down to doing one of the following: upgrade mutter, upgrade snapd, or switch back to the X11 session.

1 Like
7

This very much sounds like the problem. Applied the latest updates and now i have mutter 3.38.2 and snapd 2.47. Now it works again! :partying_face:

Thanks for the info and good to hear that it is a known and fixed issue that will not hit the Ubuntu users of my snap down the line.

1 Like