this post was submitted on 08 Jan 2025
11 points (100.0% liked)

linux4noobs

1495 readers
2 users here now

linux4noobs


Noob Friendly, Expert Enabling

Whether you're a seasoned pro or the noobiest of noobs, you've found the right place for Linux support and information. With a dedication to supporting free and open source software, this community aims to ensure Linux fits your needs and works for you. From troubleshooting to tutorials, practical tips, news and more, all aspects of Linux are warmly welcomed. Join a community of like-minded enthusiasts and professionals driving Linux's ongoing evolution.


Seeking Support?

Community Rules

founded 1 year ago
MODERATORS
11
submitted 1 week ago* (last edited 1 week ago) by [email protected] to c/linux4noobs
 

For a long time, when using my computer (Arch linux), I would sometimes run into this problem. When trying to open an application in a new window, I'll be met by:

Invalid MIT-MAGIC-COOKIE-1 key
cannot open display: :0

I've tried a lot of "solutions" without luck, but I've finally found a way to consistently reproduce the error. It happens everytime I connect to a new wifi.

I found this 9 year old post about the same problem, but it does not include a real solution or the cause of the problem.

I'll try asking it here, to see if anybody knows why it happens and how to solve it, and perhaps to help others with the same problem find the cause of this error. It is such a relief for me, knowing that it is caused by changing wifi.

In advance, thanks for the help/feedback :)

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 2 points 1 week ago* (last edited 1 week ago) (1 children)

Hmm.

My hostname doesn't change on connecting to a WiFi network on my laptop.

But xauth -n list does have entries that appear to reference my hostname and a unix domain socket. And I do see some people apparently having problems with this after modifying their hostname during an X11 session. Maybe the hostname is a factor here, even when not connecting to a remote machine. Huh.

pokes around

It looks like the default behavior for NetworkManager is to set the hostname if you don't have a configured hostname for your machine. I do:

$ cat /etc/hostname
talmachine
$

I'm not sure whether yours is "archlinux" or just not specified and "archlinux" is some sort of default that Arch Linux uses on systems with no hostname set.

If it's not set and acceptable to you to set a hostname there, that might be the most-reasonable way to address the issue, if you don't have a hostname set for the machine -- go ahead and edit that file as root, set a hostname in that file, boot the system, and see if your issue goes away. I just have a single word on my system ("talmachine"), not a fully-qualified domain name ("talmachine.domain.com").

It looks like the modern, systemd-friendly way to update a hostname and simultaneously inform running software that the hostname has changed is to run hostnamectl hostname <hostname>, so hostnamectl hostname talmachine or similar. Should have basically the same effect as editing that file, might cause some software to not need a reboot. I'd probably reboot anyway, cause X11 to produce a new magic cookie and such.

Looking at man NetworkManager.conf, it also looks like it's possible to instruct NetworkManager to not modify the hostname on connection on hosts that don't have a hostname set.

   hostname-mode
       Set the management mode of the hostname. This parameter will affect only the transient hostname. If a valid static
       hostname is set, NetworkManager will skip the update of the hostname despite the value of this option. An hostname
       empty or equal to 'localhost', 'localhost6', 'localhost.localdomain' or 'localhost6.localdomain' is considered
       invalid.

       default: NetworkManager will update the hostname with the one provided via DHCP or reverse DNS lookup of the IP
       address on the connection with the default route or on any connection with the property hostname.only-from-default
       set to 'false'. Connections are considered in order of increasing value of the hostname.priority property. In case
       multiple connections have the same priority, connections activated earlier are considered first. If no hostname can
       be determined in such way, the hostname will be updated to the last one set outside NetworkManager or to
       'localhost.localdomain'.

       dhcp: this is similar to 'default', with the difference that after trying to get the DHCP hostname, reverse DNS
       lookup is not done. Note that selecting this option is equivalent to setting the property
       'hostname.from-dns-lookup' to 'false' globally for all connections in NetworkManager.conf.

       none: NetworkManager will not manage the transient hostname and will never set it.

So I guess, if you don't want to set a hostname on your system, or one is already set and for some reason you're still smacking into this, you might also try modifying /etc/NetworkManager/NetworkManager.conf to read something like:

[main]
hostname-mode=none
[–] [email protected] 2 points 1 week ago (1 children)

Thanks so much <3

Turns out I didn't have a file at /etc/hostname. I created one and now the problem is gone :)

Thanks so much for your help <3

[–] [email protected] 2 points 1 week ago

No prob. Glad it worked!