After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 688716 - When hostname changes, apps look "remote"
When hostname changes, apps look "remote"
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
3.6.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 688862 694303 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-11-20 11:16 UTC by Bastien Nocera
Modified: 2013-02-22 09:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
window: deduplicate is_remote logic (5.85 KB, patch)
2013-02-20 20:27 UTC, Ray Strode [halfline]
committed Details | Review
window: fix meta_window_is_remote across hostname changes (11.88 KB, patch)
2013-02-20 20:27 UTC, Ray Strode [halfline]
accepted-commit_now Details | Review
window: fix meta_window_is_remote across hostname changes (13.84 KB, patch)
2013-02-20 21:06 UTC, Ray Strode [halfline]
committed Details | Review

Description Bastien Nocera 2012-11-20 11:16:26 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.
Comment 1 Giovanni Campagna 2012-11-20 14:26:27 UTC
How do we know that the apps are local, if WM_CLIENT_MACHINE has a different hostname than ours?
Comment 2 Bastien Nocera 2012-11-20 14:45:32 UTC
(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.
Comment 3 Bastien Nocera 2012-11-20 15:10:13 UTC
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.
Comment 4 Rui Matos 2012-11-22 10:57:46 UTC
*** Bug 688862 has been marked as a duplicate of this bug. ***
Comment 5 Vít Ondruch 2012-11-22 19:11:54 UTC
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.
Comment 6 Pavel Simerda 2012-12-20 13:20:44 UTC
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.
Comment 7 Vít Ondruch 2013-02-07 12:44:10 UTC
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.
Comment 8 Florian Müllner 2013-02-20 20:04:21 UTC
*** Bug 694303 has been marked as a duplicate of this bug. ***
Comment 9 Ray Strode [halfline] 2013-02-20 20:27:48 UTC
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.
Comment 10 Ray Strode [halfline] 2013-02-20 20:27:52 UTC
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.
Comment 11 Ray Strode [halfline] 2013-02-20 20:29:14 UTC
(untested because i wrote them on the wrong machine, will test in a second)
Comment 12 Pavel Simerda 2013-02-20 20:47:21 UTC
(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!
Comment 13 Olav Vitters 2013-02-20 20:48:55 UTC
I thought at least the Linux kernel could notify when the hostname changes?
Comment 14 Bastien Nocera 2013-02-20 20:50:40 UTC
(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).
Comment 15 Jasper St. Pierre (not reading bugmail) 2013-02-20 20:51:27 UTC
(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.
Comment 16 Jasper St. Pierre (not reading bugmail) 2013-02-20 20:52:22 UTC
Review of attachment 236979 [details] [review]:

OK.
Comment 17 Jasper St. Pierre (not reading bugmail) 2013-02-20 20:52:31 UTC
Review of attachment 236978 [details] [review]:

OK.
Comment 18 Ray Strode [halfline] 2013-02-20 20:53:51 UTC
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)
Comment 19 Ray Strode [halfline] 2013-02-20 20:56:02 UTC
(marking needs work because it doesn't deal with the fact that there's a WM_CLIENT_MACHINE mismatch still)
Comment 20 Ray Strode [halfline] 2013-02-20 21:05:56 UTC
Comment on attachment 236979 [details] [review]
window: fix meta_window_is_remote across hostname changes

(this one's fine)
Comment 21 Ray Strode [halfline] 2013-02-20 21:06:17 UTC
Comment on attachment 236978 [details] [review]
window: deduplicate is_remote logic

(err this one)
Comment 22 Ray Strode [halfline] 2013-02-20 21:06:44 UTC
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.
Comment 23 Jasper St. Pierre (not reading bugmail) 2013-02-20 21:18:48 UTC
Review of attachment 236980 [details] [review]:

OK.
Comment 24 Ray Strode [halfline] 2013-02-20 21:20:09 UTC
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
Comment 25 Vít Ondruch 2013-02-20 21:21:38 UTC
Looking forward to Fedora 19. Thank you guys.
Comment 26 Vít Ondruch 2013-02-21 08:46:23 UTC
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 :/
Comment 27 Pavel Simerda 2013-02-22 09:07:57 UTC
(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.