[SOLVED] why changing hostname on the fly break GUI programs

avi9526 · 2019-02-21 07:55:41

kate

runs fine

sudo hostname ftw
kate
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: wayland-org.kde.kwin.qpa, eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb.

Aborted (core dumped)

this is problem because I want set /etc/hostname empty so system can receive hostname from DHCP but it cause this problem

Last edited by avi9526 (2019-02-22 12:49:41)

Piri · 2019-02-21 08:52:35

https://stackoverflow.com/questions/206 … -dont-open

Basically, your .Xauthority file does not match anymore after a hostname change.

seth · 2019-02-21 08:54:32

Because X11 is a network protocol w/ attached GUI functionality. Changing the hostname will break the connection. Delay the graphical target until the hostname is received.

Edit: while you might be able to start programs again, the issue goes beyond xauth. If you can, wait for the hostname before starting X11 to prevent issues down the road (albeit your common gtk/qt stuff is likely not affected)

Last edited by seth (2019-02-21 09:00:56)

Trilby · 2019-02-21 14:15:53

If you don't want to wait, just check out the XServer man page section on "Granting Access". There are many approaches that do not rely on host names including the simplest which only accepts connections from the local host (but doesn't rely on checking the hostname). There's also another method that lets you create a list of authorized hosts - this may be good if your machine's hostname comes from a finite set of possible options (and with some other assumptions about how much of a threat other members of that set should be considered).

Waiting for the hostname is only relevant if you use the default authorization mechanism used by xinit/startx (specifically a single MIT-MAGIC-COOKIE-1 record generated from the current hostname). But that just doesn't fit your needs, so use something else.

Even using my currrent access methods, this works fine:

$ kate
# kate opens ... I close it

$ sudo hostname gibberish

$ kate
# kate opens again ... no errors

If you don't want to rely on the hostname, set up your access method to not rely on hostnames.

Last edited by Trilby (2019-02-21 14:22:49)

avi9526 · 2019-02-21 22:32:30

Seems like in my system .Xauthority is generated by SDDM which directly calls "xauth" command to make xauth list in /var/run/sddm/{<random_uuid>} and then copies it to .Xauthority. I pretty sure that SDDM put hostname in .Xauthority and will not adapt to other access method that Trilby was telling about.

The only thing I managed to do is break it by adding

[X11]
XauthPath=/non_existent_file

to /etc/sddm.conf

which cause xauth lists to be empty. I suspect this is worst idea ever. But it allowed me to test hostname change on the fly. Still got problem

kate

sudo hostname ftw

kate
_IceTransSocketUNIXConnect: Cannot connect to non-local host myoldname
_IceTransSocketUNIXConnect: Cannot connect to non-local host myoldname
Qt: Session management error: Could not open network socket

so it seems that seth was right and there is more than just xauth problems.

Maybe easiest and safest solution for my problem with NetworkManager is to add

Wants=network-online.target
After=network.target network-online.target

to sddm.service

Trilby wrote:

If you don't want to wait, just check out the XServer man page section on "Granting Access". … If you don't want to rely on the hostname, set up your access method to not rely on hostnames.

Unfortunately I was not able to comprehend XServer manual

seth · 2019-02-21 22:57:33

ICE is an IPC protocol, this is ~/.ICEauthority and you can edit it using https://www.archlinux.org/packages/extr … g-iceauth/
Things would start to get really (unresolvably) nasty if you're using X11 over tcp (because X11 itself doesn't communicate the hostname so you'd ultimately run into a situation where the client has the old hostname and tries to XOpenDisplay afterwards)

my problem with NetworkManager

Sanity check: is

can receive hostname from DHCP

really deliberate or some kludge?

Arch Linux

#1 2019-02-21 07:55:41

[SOLVED] why changing hostname on the fly break GUI programs

#2 2019-02-21 08:52:35

Re: [SOLVED] why changing hostname on the fly break GUI programs

#3 2019-02-21 08:54:32

Re: [SOLVED] why changing hostname on the fly break GUI programs

#4 2019-02-21 14:15:53

Re: [SOLVED] why changing hostname on the fly break GUI programs

#5 2019-02-21 22:32:30

Re: [SOLVED] why changing hostname on the fly break GUI programs

#6 2019-02-21 22:57:33

Re: [SOLVED] why changing hostname on the fly break GUI programs

Board footer