Arch Linux

tcn

Member

Registered: 2011-09-30

Posts: 55

qt.qpa.xcb: could not connect to display :0

Hi!

After roughly 10 days or 2 weeks or so I'm suddenly unable to open any new windows.

Looks like this:

No protocol specified 
qt.qpa.xcb: could not connect to display :0 
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found. 
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. 

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.

I'm suspecting some tmpfiles rules cleaning up some file in /tmp/ or something. Have basically the default rules, didn't change/add much myself.
Somebody here with the same issue and possibly a solution?

thx
tcn

tcn

Member

Registered: 2011-09-30

Posts: 55

Re: qt.qpa.xcb: could not connect to display :0

I guess I was right. Files like these get deleted by tmpfiles

/tmp/xauth-1024-_0
/tmp/.X0-lock
/tmp/kde-tcn/
/tmp/kde-tcn/xauth-1024-_0
/tmp/runtime-root
/tmp/.Test-unix
/tmp/.font-unix
/tmp/.XIM-unix

Likely by /usr/lib/tmpfiles.d/tmp.conf.

q /tmp 1777 root root 10d
q /var/tmp 1777 root root 30d

And this is not prevented by /usr/lib/tmpfiles.d/x11.conf.

Any idea anyone?

zash1958

Member

Registered: 2019-10-23

Posts: 11

Re: qt.qpa.xcb: could not connect to display :0

Same problem here since yesterday. System starts, can login in my KDE environment and cannot start anything further :-(

Exactly the same error message

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 21,720

Re: qt.qpa.xcb: could not connect to display :0

That isn't the same problem. tcn is explicitly wondering about what is happening with an uptime of 2 weeks and a reboot would fix their issue. You must have a different cause, please make a new thread and include the journal output after attempting to log in.

tcn

Member

Registered: 2011-09-30

Posts: 55

Re: qt.qpa.xcb: could not connect to display :0

tcn just figured out that reinstalling/updating systemd resets (at least) tmpfiles.d/tmp.conf. I prolonged the timeout from 10d to 21d and after reinstalling it was back to 10d. No .pacnew file.

Lone_Wolf

Member

From: Netherlands, Europe

Registered: 2005-10-04

Posts: 11,919

Re: qt.qpa.xcb: could not connect to display :0

https://wiki.archlinux.org/title/Pacman … ckup_files

backup=(etc/pam.d/systemd-user
          etc/systemd/coredump.conf
          etc/systemd/homed.conf
          etc/systemd/journald.conf
          etc/systemd/journal-remote.conf
          etc/systemd/journal-upload.conf
          etc/systemd/logind.conf
          etc/systemd/networkd.conf
          etc/systemd/oomd.conf
          etc/systemd/pstore.conf
          etc/systemd/resolved.conf
          etc/systemd/sleep.conf
          etc/systemd/system.conf
          etc/systemd/timesyncd.conf
          etc/systemd/user.conf
          etc/udev/udev.conf)

No mention of any file under /usr/lib/tmpfiles.d/ , so arch devs don't think it's needed to create .pacsave or ,pacnew for those .

SYNOPSIS
       /etc/tmpfiles.d/*.conf
       /run/tmpfiles.d/*.conf
       /usr/lib/tmpfiles.d/*.conf

Try putting your adjusted *.conf file in /etc/tmpfiles.d .

Last edited by Lone_Wolf (2021-06-05 20:16:34)

---

Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.

(A works at time B)  && (time C > time B ) ≠  (A works at time C)

tcn

Member

Registered: 2011-09-30

Posts: 55

Re: qt.qpa.xcb: could not connect to display :0

Looks good:

# grep ' /tmp' /usr/lib/tmpfiles.d/tmp.conf /etc/tmpfiles.d/tmp.conf 
/usr/lib/tmpfiles.d/tmp.conf:q /tmp 1777 root root 10d
/etc/tmpfiles.d/tmp.conf:q /tmp 1777 root root 21d

# systemd-tmpfiles --cat-config | grep ' /tmp'
x /tmp/systemd-private-%b-*
X /tmp/systemd-private-%b-*/tmp
R! /tmp/systemd-private-*
q /tmp 1777 root root 21d
D! /tmp/.X11-unix 1777 root root 10d
D! /tmp/.ICE-unix 1777 root root 10d
D! /tmp/.XIM-unix 1777 root root 10d
D! /tmp/.font-unix 1777 root root 10d
D! /tmp/.Test-unix 1777 root root 10d
r! /tmp/.X[0-9]*-lock

Not sure if order matters here, perhaps the /tmp/ rule is supposed to show up at the bottom...