Thanks for your response. I'm was still a bit puzzled why you got the:
_XSERVTransSocketUNIXCreateListener: mkdir(/tmp/.X11-unix) failed, errno = 2
The message is actually misleading. It's not that mkdir(/tmp/.X11-unix)
failed, it's that trans_mkdir(/tmp/.X11-unix) failed for the reason mentioned
on the line above it. I started to build XQuartz with -DFAIL_HARD which will
error out if /tmp/.X11-unix is not owned by root (to avoid man-in-the-middle
attacks on your X11 socket).
So I think that finishes solving the riddle.
--Jeremy
On Apr 25, 2011, at 11:05 PM, SciFi wrote:
>
> [I am using Gmane and Pan to reply. Peek at the headers of this message, esp
> User-Agent. ;) ]
>
> On Mon, 25 Apr 2011 11:32:00 -0700, Jeremy Huddleston wrote:
>
>> On Apr 25, 2011, at 07:49, SciFi wrote:
>>> Apr 25 08:45:06 scifi [0x0-0x2d02d].org.macosforge.xquartz.X11[522]:
>>> _XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be
>>> created.
>>> Apr 25 08:45:06 scifi [0x0-0x2d02d].org.macosforge.xquartz.X11[522]:
>>> _XSERVTransSocketUNIXCreateListener: mkdir(/tmp/.X11-unix) failed, errno = 2
>>> Apr 25 08:45:06 scifi [0x0-0x2d02d].org.macosforge.xquartz.X11[522]:
>>> _XSERVTransMakeAllCOTSServerListeners: failed to create listener for local
>>
>> Are your /tmp permissions messed up?
>
> /tmp is (still) a symlink to /private/tmp, the way Apple originally intended;
> I haven't change this.
>
> $ ls -al /tmp
> lrwxr-xr-x 1 root wheel 11 Dec 26 07:50 /tmp -> private/tmp
>
> $ ls -al /private
> total 0
> drwxr-xr-x 6 root wheel 204 Dec 26 08:01 .
> drwxrwxrwt 24 root wheel 1258 Apr 22 06:43 ..
> drwxr-xr-x 26 root wheel 4658 Apr 25 08:30 etc
> drwxr-xr-x 2 root wheel 68 May 18 2009 tftpboot
> drwxrwxrwt 11 root wheel 544 Apr 26 00:00 tmp
> drwxr-xr-x 26 root wheel 884 Dec 26 08:01 var
>
> (I think, not sure, that /tmp is checked with the 'diskutil repairPermissions
> /' facility? I run it after most-any system update.)
>
>> 1) Any user should be able to mkdir(/tmp/.X11-unix) if it isn't present.
>> 2) root should be creating and sanitizing /tmp/.X11-unix via
>> org.macosforge.xquartz.privileged_startx
>
> Thanks for these pointers -- I now know the real problem.
>
>
>> [snip]
>>
>>> Was this suppose to have been automatically done during another phase,
>>> somehow?
>>
>> The org.macosforge.xquartz.privileged_startx LaunchDaemon, which is
>> triggered by running /opt/X11/lib/X11/xinit/privileged_startx from
>> /opt/X11/bin/startx from the org.macosforge.xquartz.startx LaunchAgent.
>>
>>> What should we do in this case, please?
>>
>> My guess is fix your /tmp permissions.
>
> I am sure the /tmp permissions are okay (see above).
> But I am thankful for pointing me to where the real problem is, here on my
> system.
>
> When I peeked into the files under /opt/X11/lib/X11/xinit/privileged_startx.d,
> I found the problem is with using 'mktemp' in the 10-tmpdirs script.
> The system here is picking up my $PATH, finding them first in /usr/local/bin,
> where I placed my own builds of the GNU-coreutils version of these tools,
> which sometimes have distinctly different usage patterns --
> when I ran those three dir's in that for-loop in 10-tmpdirs,
> GNU's mktemp says it needs at least 3 X's in the template
> and that is where we are failing.
>
> I'm going to hard-code these tools, when they differ so much in usage,
> to use Apple's *BSD versions in the {,/usr}/bin tree,
> rather than any $PATH version.
>
> That should fix everything with your new Xquartz I hope. ;)
>
> Unless you would rather go back with the previous/older way of creating these
> tmpdirs i.e. by not using mktemp. ;)
>
> Thank you again very much for taking time.
>
>
>
> _______________________________________________
> Xquartz-dev mailing list
> Xquartz-dev@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>
_______________________________________________
Xquartz-dev mailing list
Xquartz-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
