[indiana-discuss] error: Failed to allocate internet-domain X11 display socket

[Brian Ruthven - Solaris Network Sustaining - Sun UK]

Replies inline

solarg wrote:
> Brian Ruthven - Solaris Network Sustaining - Sun UK wrote:
>>
>> Can you try plumbing in the ::1 interface in the zone please? I don't 
>> recall whether this can be done with ifconfig plumb or not within an 
>> NGZ or whether it is a zonecfg re-configuration which is needed.
>>
> it's very difficult to find the docs. I found this:
> http://www.sun.com/bigadmin/sundocs/articles/trsoltechfaq.jsp
> and i did:
> zonecfg:catalogue2> add net
> zonecfg:catalogue2:net> set address=::1/64
> zonecfg:catalogue2:net> set physical=e1000g1
> zonecfg:catalogue2:net> end
>
> i'm not sure how it is correct?
> in the zone, now:
> lo0:1: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> 
> mtu 8252 index 1
>         inet6 ::1/128
>
> and the message "error: Failed to allocate internet-domain X11 display 
> socket" never appears
>
> Could you confirm this workaround, and the exact syntax? i'm not very 
> friendly with ipv6.
>

It's been a while since I've configured a zone, so I'm not the best one 
to check with ;-)
On the other hand, you do end up with a ::1 address, so I guess it's 
good enough.
I expected the message to go away once a ::1 addr was available.


>> Alternatively, try one of the workarounds in 
>> http://bugs.opensolaris.org/view_bug.do?bug_id=6704823 and let me 
>> know whether you can reproduce the problem. If not, remove the 
>> workaround (unplumb the interface, etc...) and try again to confirm 
>> the error re-appears.
>>
>
> none of these workarounds works in my case. But even if the error 
> message appears, you're able to login into the zone, so i think it's 
> the reason why other people doesn't complain about it.

OK, none of the documented workarounds are applicable, but adding the 
interface with zonecfg is apparently good enough. It may need some 
refining, but it does show that nevada NGZs are applicable to this bug.

The message shouldn't stop a shell login, but IIRC you should find that 
you cannot SSH-tunnel X applications to a remote host, i.e. X forwarding 
is broken.

When I originally logged the bug, I didn't check NGZ default config (I 
didn't have the time to set one up and test as I was in the middle of 
checking and integrating another bug fix.

I'll try and check this out (and update the bug), but I don't have a lot 
of time at the moment.

Regards,
Brian

>
> thanks for your help,
>
>> Thanks,
>> Brian
>>
>>
>> solarg wrote:
>>> Brian Ruthven - Solaris Network Sustaining - Sun UK wrote:
>>>>
>>>> That bug (or rather the bug it was closed as a duplicate of) is 
>>>> technically S10-only because nevada (and hence opensolaris) plumbs 
>>>> in an IPv6 interface by default.
>>>>
>>>> Do you have the ::1 "interface" plumbed in and up? Something like 
>>>> this:
>>>>
>>>> lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> 
>>>> mtu 8252 index 1
>>>>    inet6 ::1/128
>>>>
>>>> If not, then you can be exposed to this bug on OpenSolaris.
>>>>
>>>
>>> yes, i have it in the global zone:
>>> lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> 
>>> mtu 8252 index
>>>  1
>>>         inet6 ::1/128
>>>
>>> but not in the non-global zone:
>>> root at ng-zone:~# ifconfig -a
>>> lo0:8: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> 
>>> mtu 8232 index 1
>>>         inet 127.0.0.1 netmask ff000000
>>> e1000g1:8: flags=201000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,CoS> 
>>> mtu 1500 index 3
>>>         inet x.y.z.143 netmask ffffff00 broadcast x.y.z.255
>>> root at ng-zone:~#
>>>
>>> gerard
>>>
>>>
>>
>

-- 
Brian Ruthven                                        Sun Microsystems UK
Solaris Revenue Product Engineering             Tel: +44 (0)1252 422 312
Sparc House, Guillemont Park, Camberley, GU17 9QG