/etc/hosts and system entries

Adam Jackson ajackson at redhat.com
Mon Oct 1 19:41:05 UTC 2007

On Mon, 2007-10-01 at 15:47 +0100, Bill Crawford wrote:
> On 01/10/2007, Adam Jackson <ajackson at redhat.com> wrote:
> > I think there's something more subtle going on in this case.  What we do
> > at least in startx(1) is add the cookie to ~/.Xauthority twice, once
> > for :0 and once for foo:0, so the first one should always win.
> I noticed that. Still got this in my output (shortly before a crash in
> libGLcore, which I'm guessing is unrelated to the network issue):
> _IceTransSocketUNIXConnect: Cannot connect to non-local host bill.wcn.co.uk
> Warning: Tried to connect to session manager, Could not open network socket

Okay, I think I have a fix for this.

The bug is that the ICE sockets are bound at session startup by
gnome-session (or whatever), and the path to them is stashed in
$SESSION_MANAGER in the environment as a tuple of (transport, hostname,
port).  But the hostname in that tuple is whatever you got back from
gethostname().  NetworkManager won't change the system hostname when
changing DHCP leases, but dhclient will, and more generally we can't
rely on the user to not set the hostname to whatever they want.

Fortunately, there's a special case in the xtrans code that treats the
hostname "unix" as meaning "no, really, local machine", so for AF_UNIX
transports we just lie and set the "hostname" in the above tuple to be
"unix" and avoid that whole mess.

Fixed in xorg-x11-xtrans-devel 1.0.3-5 and libICE 1.0.4-2 (currently
building).  Anyone who was seeing X app launch stalling or failing after
changing networks/IPs/hostnames/whatever, please update libICE and see
if you can still repro it.

- ajax

More information about the fedora-devel-list mailing list