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

Brian Ruthven - Sun UK Brian.Ruthven at Sun.COM
Tue May 12 02:07:44 PDT 2009


This was fixed in snv_114. Unfortunately, this is not yet available via 
the dev repository, so for now, I'd go with the workaround of adding the 
::1 address through zonecfg.

Regards,
Brian


Brian Ruthven - Solaris Network Sustaining - Sun UK wrote:
> 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




More information about the indiana-discuss mailing list