GNOME Bugzilla – Bug 688716
When hostname changes, apps look "remote"
Last modified: 2013-02-22 09:07:57 UTC
mutter-3.6.2-1.fc18.x86_64 gnome-shell-3.6.2-2.fc18.x86_64 1. Boot with your machine called "localhost.localdomain" 2. Change the hostname: gdbus call --system --dest org.freedesktop.hostname1 --object-path /org/freedesktop/hostname1 --method org.freedesktop.hostname1.SetHostname "novo" false () 3. See that a number of apps now have "(on localhost.localdomain)" in their titlebar (but bizarrely, not all). The apps are still local, that string shouldn't appear.
How do we know that the apps are local, if WM_CLIENT_MACHINE has a different hostname than ours?
(In reply to comment #1) > How do we know that the apps are local, if WM_CLIENT_MACHINE has a different > hostname than ours? Because they were already running when the name was localhost.localdomain.
Note that this causes more problems than just the above. gnome-shell started thinking that new windows from the same apps (opening a gnote note for example) and new applications are somehow foreign, and we get a crummy old school icon and no application name.
*** Bug 688862 has been marked as a duplicate of this bug. ***
I complained about this issue already a long time ago: https://bugzilla.redhat.com/show_bug.cgi?id=817500 if that is the same issue.
Is there any valid reason to break user interface features upon hostname changes? Seen problems like that in XFCE years ago, but didn't expect to see it again.
Guys, what can I do to have this fixed? It is almost year I reported this issue into RH bugzilla (referenced above) and nothing happened. Since my IP and hostname is changed quite often, this makes my system unusable without restarts. Not mentioning that connect my laptop in different location has the same effect. That pretty well break Gnome's assumption that people will sleep the computer just by closing lid and move to another location, since on that another location the applications stop to group, which makes them to restart or something similar.
*** Bug 694303 has been marked as a duplicate of this bug. ***
Created attachment 236978 [details] [review] window: deduplicate is_remote logic set_title_text does the equivalent of meta_window_is_remote on its own. This commit changes set_title_text to just use meta_window_is_remote.
Created attachment 236979 [details] [review] window: fix meta_window_is_remote across hostname changes meta_window_is_remote uses a cached copy of the system hostname. Of course, the system hostname can change at any time, so caching it is wrong. This commit makes the function call gethostname() on each call.
(untested because i wrote them on the wrong machine, will test in a second)
(In reply to comment #10) > Of course, the system hostname can change at any time, so caching > it is wrong. Ah, that will be the problem. > This commit makes the function call gethostname() on each call. Great work!
I thought at least the Linux kernel could notify when the hostname changes?
(In reply to comment #13) > I thought at least the Linux kernel could notify when the hostname changes? Monitoring /etc/hostname should be enough for systemd-powered OSes as well (it's what we use to change the hostname in the first place).
(In reply to comment #13) > I thought at least the Linux kernel could notify when the hostname changes? As far as I understand it, Linux nor glibc provide no such functionality.
Review of attachment 236979 [details] [review]: OK.
Review of attachment 236978 [details] [review]: OK.
i don't think we really need to be notified of changes here. gethostname() isn't a slow call, afaik, and we don't really need to "do" anything when it changes (other than not use the stale value)
(marking needs work because it doesn't deal with the fact that there's a WM_CLIENT_MACHINE mismatch still)
Comment on attachment 236979 [details] [review] window: fix meta_window_is_remote across hostname changes (this one's fine)
Comment on attachment 236978 [details] [review] window: deduplicate is_remote logic (err this one)
Created attachment 236980 [details] [review] window: fix meta_window_is_remote across hostname changes meta_window_is_remote compares a cached copy of the system hostname with the hostname of the client window (as presented by the WM_CLIENT_MACHINE property). Of course, the system hostname can change at any time, so caching it is wrong. Also, the WM_CLIENT_MACHINE property won't necessarily change when the system hostname changes, so comparing it with the new system hostname is wrong, too. This commit makes the code call gethostname() at the time WM_CLIENT_MACHINE is set, check whether it's remote then, and cache that value, rather than comparing potentially out of sync hostnames later.
Review of attachment 236980 [details] [review]: OK.
Attachment 236978 [details] pushed as 64544fa - window: deduplicate is_remote logic Attachment 236980 [details] pushed as 2cafb8b - window: fix meta_window_is_remote across hostname changes
Looking forward to Fedora 19. Thank you guys.
BTW, since this seems to be tiny patch, have you considered to backport it for Gnome 3.6 and 3.4? This would make my life easier, since I am going to restart my computer running F18 just because of this issue :/
(In reply to comment #26) > This would make my life easier, since I am going to restart > my computer running F18 just because of this issue :/ I must agree, this would be a +1 for both Gnome and Fedora.