Re: [Xquartz-dev] Getting bad DISPLAY value during use of 2.6.1-2.6.2 (not with 2.6.0 & before).
On 04/24/2011 at 11:44 AM, Jeremy Huddleston <jeremyhu@apple.com> wrote:On Apr 24, 2011, at 09:31, sci-fi@hush.ai wrote:
Hello,
I think DISPLAY is getting a weird value on my system here.
We've completely rebooted, and this is still occurring on my system with any of the 2.6.1-2.6.2 incarnations of Xquartz. (IIRC this didn't happen with 2.6.0 and earlier.) Presently I have the beta1 of 2.6.2 installed and trying to get it started-up here. (Yes I did re-run the installer for 2.6.2_beta1 after the 10.6.7/etc system updates.)
The user's env-var matches what launchctl returns:
$ launchctl getenv DISPLAY /tmp/launch-s9kPWX/org.x:0
You should have /Library/LaunchAgents/org.macosforge.xquartz.startx.plist
What is the output of "launchctl list org.macosforge.xquartz.startx"
$ launchctl list org.macosforge.xquartz.startx { "Label" = "org.macosforge.xquartz.startx"; "LimitLoadToSessionType" = "Background"; "OnDemand" = true; "LastExitStatus" = 0; "TimeOut" = 30; "ProgramArguments" = ( "/opt/X11/bin/startx"; ); "EnableTransactions" = true; "TransactionCount" = -1; "Sockets" = { "org.macosforge.xquartz:0" = ( file-descriptor-object; ); }; };
<snip/>
(There is no critter named /tmp/.X11-unix (shown via ls -al) presently on my system. The /tmp dir itself does have root:wheel ownership with "drwxrwxrwt" flags.)
It should be created by /Library/LaunchDaemons/org.macosforge.xquartz.privileged_startx.plist
What is the output of "sudo launchctl list org.macosforge.xquartz.privileged_startx"
$ sudo launchctl list org.macosforge.xquartz.privileged_startx Password: { "Label" = "org.macosforge.xquartz.privileged_startx"; "LimitLoadToSessionType" = "System"; "OnDemand" = true; "LastExitStatus" = 0; "TimeOut" = 120; "ProgramArguments" = ( "/opt/X11/lib/X11/xinit/privileged_startx"; "-d"; "/opt/X11/lib/X11/xinit/privileged_startx.d"; ); "EnableTransactions" = true; "TransactionCount" = -1; "MachServices" = { "org.macosforge.xquartz.privileged_startx" = mach-port-object; }; };
[…]
During these lists, none of the X (sub)tasks are running now. BTW I dug a bit and found: $ ls -al /tmp/launch-34Cqdu total 0 drwx------ 2 scifi wheel 102 Apr 24 10:25 . drwxrwxrwt 11 root wheel 544 Apr 24 11:56 .. srwx------ 1 scifi wheel 0 Apr 24 10:25 org.macosforge.xquartz:0 so _something_ was trying to work right. But the timestamps might tell something -- the "wrong" one might've been created during when we rebooted, 19-minutes earlier: $ ls -al /tmp/launch-s9kPWX total 0 drwx------ 2 scifi wheel 102 Apr 24 10:06 . drwxrwxrwt 11 root wheel 544 Apr 24 11:56 .. srwx------ 1 scifi wheel 0 Apr 24 10:06 org.x:0 Another BTW -- I don't have anything like ~/.x* critters either, nor in /etc . ;) Thanks again.
On Apr 24, 2011, at 10:22, sci-fi@hush.ai wrote:
You should have /Library/LaunchAgents/org.macosforge.xquartz.startx.plist
What is the output of "launchctl list org.macosforge.xquartz.startx"
$ launchctl list org.macosforge.xquartz.startx { "Label" = "org.macosforge.xquartz.startx"; "LimitLoadToSessionType" = "Background"; "OnDemand" = true; "LastExitStatus" = 0; "TimeOut" = 30; "ProgramArguments" = ( "/opt/X11/bin/startx"; ); "EnableTransactions" = true; "TransactionCount" = -1; "Sockets" = { "org.macosforge.xquartz:0" = ( file-descriptor-object; ); }; };
<snip/>
(There is no critter named /tmp/.X11-unix (shown via ls -al) presently on my system. The /tmp dir itself does have root:wheel ownership with "drwxrwxrwt" flags.)
It should be created by /Library/LaunchDaemons/org.macosforge.xquartz.privileged_startx.plist
What is the output of "sudo launchctl list org.macosforge.xquartz.privileged_startx"
$ sudo launchctl list org.macosforge.xquartz.privileged_startx Password: { "Label" = "org.macosforge.xquartz.privileged_startx"; "LimitLoadToSessionType" = "System"; "OnDemand" = true; "LastExitStatus" = 0; "TimeOut" = 120; "ProgramArguments" = ( "/opt/X11/lib/X11/xinit/privileged_startx"; "-d"; "/opt/X11/lib/X11/xinit/privileged_startx.d"; ); "EnableTransactions" = true; "TransactionCount" = -1; "MachServices" = { "org.macosforge.xquartz.privileged_startx" = mach-port-object; }; };
[…]
During these lists, none of the X (sub)tasks are running now.
BTW I dug a bit and found: $ ls -al /tmp/launch-34Cqdu total 0 drwx------ 2 scifi wheel 102 Apr 24 10:25 . drwxrwxrwt 11 root wheel 544 Apr 24 11:56 .. srwx------ 1 scifi wheel 0 Apr 24 10:25 org.macosforge.xquartz:0
so _something_ was trying to work right.
And I bet if you do 'export DISPLAY="/tmp/launch-34Cqdu/org.macosforge.xquartz:0"', it'll work as well... Did you create a separate LaunchAgent for org.x.startx (like in /Library/LaunchAgents or ~/Library/LaunchAgents)? launchd should prefer /Library over /System/Library when determining the environment. What is the output of: ls -l {~,/System,}/Library/Launch*/org.*startx*
But the timestamps might tell something -- the "wrong" one might've been created during when we rebooted, 19-minutes earlier:
No. /tmp is cleared at boot.
$ ls -al /tmp/launch-s9kPWX total 0 drwx------ 2 scifi wheel 102 Apr 24 10:06 . drwxrwxrwt 11 root wheel 544 Apr 24 11:56 .. srwx------ 1 scifi wheel 0 Apr 24 10:06 org.x:0
Another BTW -- I don't have anything like ~/.x* critters either, nor in /etc . ;)
(I see Hushmail still has their bug: their own editor won't follow the Reply email thread properly. Let me try their IMAP interface via Apple-Mail.) On Apr 24, 2011, at 18:27, Jeremy Huddleston wrote:
On Apr 24, 2011, at 10:22, sci-fi@hush.ai wrote:
You should have /Library/LaunchAgents/org.macosforge.xquartz.startx.plist
What is the output of "launchctl list org.macosforge.xquartz.startx"
$ launchctl list org.macosforge.xquartz.startx { "Label" = "org.macosforge.xquartz.startx"; "LimitLoadToSessionType" = "Background"; "OnDemand" = true; "LastExitStatus" = 0; "TimeOut" = 30; "ProgramArguments" = ( "/opt/X11/bin/startx"; ); "EnableTransactions" = true; "TransactionCount" = -1; "Sockets" = { "org.macosforge.xquartz:0" = ( file-descriptor-object; ); }; };
<snip/>
(There is no critter named /tmp/.X11-unix (shown via ls -al) presently on my system. The /tmp dir itself does have root:wheel ownership with "drwxrwxrwt" flags.)
It should be created by /Library/LaunchDaemons/org.macosforge.xquartz.privileged_startx.plist
What is the output of "sudo launchctl list org.macosforge.xquartz.privileged_startx"
$ sudo launchctl list org.macosforge.xquartz.privileged_startx Password: { "Label" = "org.macosforge.xquartz.privileged_startx"; "LimitLoadToSessionType" = "System"; "OnDemand" = true; "LastExitStatus" = 0; "TimeOut" = 120; "ProgramArguments" = ( "/opt/X11/lib/X11/xinit/privileged_startx"; "-d"; "/opt/X11/lib/X11/xinit/privileged_startx.d"; ); "EnableTransactions" = true; "TransactionCount" = -1; "MachServices" = { "org.macosforge.xquartz.privileged_startx" = mach-port-object; }; };
[…]
During these lists, none of the X (sub)tasks are running now.
BTW I dug a bit and found: $ ls -al /tmp/launch-34Cqdu total 0 drwx------ 2 scifi wheel 102 Apr 24 10:25 . drwxrwxrwt 11 root wheel 544 Apr 24 11:56 .. srwx------ 1 scifi wheel 0 Apr 24 10:25 org.macosforge.xquartz:0
so _something_ was trying to work right.
And I bet if you do 'export DISPLAY="/tmp/launch-34Cqdu/org.macosforge.xquartz:0"', it'll work as well...
Did you create a separate LaunchAgent for org.x.startx (like in /Library/LaunchAgents or ~/Library/LaunchAgents)? launchd should prefer /Library over /System/Library when determining the environment.
What is the output of:
ls -l {~,/System,}/Library/Launch*/org.*startx*
But the timestamps might tell something -- the "wrong" one might've been created during when we rebooted, 19-minutes earlier:
No. /tmp is cleared at boot.
$ ls -al /tmp/launch-s9kPWX total 0 drwx------ 2 scifi wheel 102 Apr 24 10:06 . drwxrwxrwt 11 root wheel 544 Apr 24 11:56 .. srwx------ 1 scifi wheel 0 Apr 24 10:06 org.x:0
Another BTW -- I don't have anything like ~/.x* critters either, nor in /etc . ;)
$ pwd /Users/scifi $ ls -l {~,/System,}/Library/Launch*/org.*startx* ls: cannot access /Users/scifi/Library/Launch*/org.*startx*: No such file or directory -rw-r--r-- 1 root wheel 627 Apr 24 10:12 /Library/LaunchAgents/org.macosforge.xquartz.startx.plist -rw-r--r-- 1 root wheel 696 Apr 24 10:12 /Library/LaunchDaemons/org.macosforge.xquartz.privileged_startx.plist -rw-r--r-- 1 root wheel 592 Apr 24 10:31 /System/Library/LaunchAgents/org.x.startx.plist -rw-r--r-- 1 root wheel 631 Jul 6 2009 /System/Library/LaunchDaemons/org.x.privileged_startx.plist I had tried to "disable" the Apple-provided entries (reason for its modified timestamp) but I can't remember if I had this marked during the reboot (this iMac machine is quite busy sometimes, many schedules going on): $ cat /System/Library/LaunchAgents/org.x.startx.plist <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Disabled</key> <true/> <key>Label</key> <string>org.x.startx</string> <key>ProgramArguments</key> <array> <string>/usr/X11/bin/startx</string> </array> <key>Sockets</key> <dict> <key>org.x:0</key> <dict> <key>SecureSocketWithKey</key> <string>DISPLAY</string> </dict> </dict> <key>ServiceIPC</key> <true/> <key>EnableTransactions</key> <true/> </dict> </plist> But I didn't know about the other plist, it is still the original file and timestamp: $ cat /System/Library/LaunchDaemons/org.x.privileged_startx.plist <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>org.x.privileged_startx</string> <key>ProgramArguments</key> <array> <string>/usr/X11/lib/X11/xinit/privileged_startx</string> <string>-d</string> <string>/usr/X11/lib/X11/xinit/privileged_startx.d</string> </array> <key>MachServices</key> <dict> <key>org.x.privileged_startx</key> <true/> </dict> <key>TimeOut</key> <integer>120</integer> <key>EnableTransactions</key> <true/> </dict> </plist> $ _ I have some ideas to try, now. I'll also try the "forced" spelling for DISPLAY as you indicated, for the X-app-user's shell, if needed. But how do we "force" the launchd/launchctl change at _that_ level for DISPLAY? (Review my first email in this thread, please.) It seems a user cannot alter that particular env-var with a simple launchctl line, yes I have tried several different ways (unsetenv included). See, _that_ is the level seen by the Xquartz start-up system, IIUC, and is the crux of this problem -- in essence, my system has the "misspelled" DISPLAY string at this level, which affects the start-up of Xquartz & company, and I *cannot* change it prior to *re*-starting Xquartz.app. The only thing I can think of, is to be sure the X-related Apple plists are actually "disabled", while the Xquartz plists are the only ones "active". (irregardless of your "placement" scheme, see) Even if I must "move away" the Apple plists, I want to be sure the Xquartz ones are left. Then I'll reboot to be sure the correct ones are loaded, etc etc etc. ;) All this is a hunch of mine, now. ;) (I have EyeTV running, it is busy recording now, its schedule is open in a few hours.) Thank you again.
Got it working, but I don't know it'll survive a reboot. Worried that after booting we will lose /tmp/.X11-unix (the actual problem now). Let me try to explain. While logged-on under root, I ended-up moving the two plists under /System/Library/Launch* for Apple's X11, to related "(Disabled)" subdirs. That effectively cleared 'em out completely. We still have the two plists for Xquartz under /Library/Launch*. I.e. it's like this now: $ ls -l {~,/System,}/Library/Launch*/org.*startx* ls: cannot access /Users/scifi/Library/Launch*/org.*startx*: No such file or directory -rw-r--r-- 1 root wheel 627 Apr 24 10:12 /Library/LaunchAgents/org.macosforge.xquartz.startx.plist -rw-r--r-- 1 root wheel 696 Apr 24 10:12 /Library/LaunchDaemons/org.macosforge.xquartz.privileged_startx.plist -rw-r--r-- 1 root wheel 592 Apr 24 10:31 /System/Library/LaunchAgents(Disabled)/org.x.startx.plist -rw-r--r-- 1 root wheel 661 Apr 25 07:07 /System/Library/LaunchDaemons(Disabled)/org.x.privileged_startx.plist Rebooted. The first thing I checked, after logging back on as me (not root), is to be sure DISPLAY has the new-fangled string. It did: $ set […] DISPLAY=/tmp/launch-8jWL7Z/org.macosforge.xquartz:0 […] $ launchctl getenv DISPLAY /tmp/launch-8jWL7Z/org.macosforge.xquartz:0 Started-up Xquartz.app. Oh it definitely could see the correct DISPLAY now, but it still errored-out, and would loop-de-loop wanting to keep attempting to start the server: -- snip from system.log -- […] Apr 25 08:45:06 scifi [0x0-0x2d02d].org.macosforge.xquartz.X11[522]: X11.app: do_start_x11_server(): argc=4 Apr 25 08:45:06 scifi [0x0-0x2d02d].org.macosforge.xquartz.X11[522]: argv[0] = /opt/X11/bin/X Apr 25 08:45:06 scifi [0x0-0x2d02d].org.macosforge.xquartz.X11[522]: argv[1] = :0 Apr 25 08:45:06 scifi [0x0-0x2d02d].org.macosforge.xquartz.X11[522]: argv[2] = -nolisten Apr 25 08:45:06 scifi [0x0-0x2d02d].org.macosforge.xquartz.X11[522]: argv[3] = tcp Apr 25 08:45:06 scifi org.macosforge.xquartz.startx[535]: Xquartz: Handoff connection established (try 1 of 5) on fd 6, "/var/tmp/tmp.0.xgqSx8". Sending message. Apr 25 08:45:06 scifi org.macosforge.xquartz.startx[535]: Xquartz: Message sent. Closing handoff fd. Apr 25 08:45:06 scifi [0x0-0x2d02d].org.macosforge.xquartz.X11[522]: Xquartz starting: Apr 25 08:45:06 scifi [0x0-0x2d02d].org.macosforge.xquartz.X11[522]: X.Org X Server 1.10.0.902 Apr 25 08:45:06 scifi [0x0-0x2d02d].org.macosforge.xquartz.X11[522]: Build Date: 20110411 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 Apr 25 08:45:06 scifi [0x0-0x2d02d].org.macosforge.xquartz.X11[522]: Fatal server error: Apr 25 08:45:06 scifi [0x0-0x2d02d].org.macosforge.xquartz.X11[522]: Cannot establish any listening sockets - Make sure an X server isn't already running Apr 25 08:45:06 scifi [0x0-0x2d02d].org.macosforge.xquartz.X11[522]: OsVendorFatalError Apr 25 08:45:06 scifi [0x0-0x2d02d].org.macosforge.xquartz.X11[522]: AbortDDX [… and so on …] -- end snip -- Yes the subsystem kept looping this, kept wanting to (re)start the server, kept getting the little "abort" panel flashed on the Desktop (getting in my way, it wants focus every time), etc. Turns out we did *not* have /tmp/.X11-unix built. I quickly logged-in as root, and did a mkdir for it. Then the next server-start loop saw it, but griped about permissions: -- snip from system.log later-on -- […] Apr 25 08:51:02 scifi org.macosforge.xquartz.startx[50616]: Build Date: 20110411 Apr 25 08:51:02 scifi org.macosforge.xquartz.startx[50616]: _XSERVTransmkdir: ERROR: Mode of /tmp/.X11-unix must be set to 1777 Apr 25 08:51:02 scifi org.macosforge.xquartz.startx[50616]: _XSERVTransSocketUNIXCreateListener: mkdir(/tmp/.X11-unix) failed, errno = 1 Apr 25 08:51:02 scifi org.macosforge.xquartz.startx[50616]: _XSERVTransMakeAllCOTSServerListeners: failed to create listener for local […] -- end snip -- Okay, fine, I quickly did a $ chmod 01777 /tmp/.X11-unix (while still root) and -voila- on the next server-start loop, it finally came up. (and stopped looping) -- snip from system.log later-later-on -- […] Apr 25 08:51:53 scifi org.macosforge.xquartz.startx[56901]: Xquartz starting: Apr 25 08:51:53 scifi org.macosforge.xquartz.startx[56901]: X.Org X Server 1.10.0.902 Apr 25 08:51:53 scifi org.macosforge.xquartz.startx[56901]: Build Date: 20110411 Apr 25 08:51:54 scifi org.macosforge.xquartz.startx[56901]: (EE) Error loading keymap /tmp/server-0.xkm Apr 25 08:51:54 scifi org.macosforge.xquartz.startx[56901]: (EE) XKB: Failed to load keymap. Loading default keymap instead. Apr 25 08:51:54 scifi org.macosforge.xquartz.startx[56901]: /opt/X11/bin/xinit: XFree86_VT property unexpectedly has 0 items instead of 1 Apr 25 08:51:56 scifi org.macosforge.xquartz.startx[56901]: X11.app Handing off fd to server thread via DarwinListenOnOpenFD(6) Apr 25 08:51:56 scifi org.macosforge.xquartz.startx[56901]: DarwinListenOnOpenFD: 6 Apr 25 08:51:56 scifi org.macosforge.xquartz.startx[56901]: Calling ListenOnOpenFD() for new fd: 6 Apr 25 08:51:56 scifi [0x0-0x2d02d].org.macosforge.xquartz.X11[0]: X11.app: Launching /opt/X11/bin/xterm: Apr 25 08:51:56 scifi [0x0-0x2d02d].org.macosforge.xquartz.X11[0]: argv[0] = /bin/sh Apr 25 08:51:56 scifi [0x0-0x2d02d].org.macosforge.xquartz.X11[0]: argv[1] = -c Apr 25 08:51:56 scifi [0x0-0x2d02d].org.macosforge.xquartz.X11[0]: argv[2] = /opt/X11/bin/xterm Apr 25 08:52:02 scifi org.macosforge.xquartz.privileged_startx[541]: font_cache: Updating FC cache Apr 25 08:52:04 scifi org.macosforge.xquartz.privileged_startx[541]: font_cache: Done […] -- end snip -- … Now, as I relax and catch my breath, I think we will still have a problem. (I am thinking this had been our earlier problem, too, actually.) You said the /tmp stuff gets cleared-out on a reboot (earlier in this thread). This means we will lose the .X11-unix subdir there, and will need to manually mkdir it all over again after booting-up. Was this suppose to have been automatically done during another phase, somehow? What should we do in this case, please? Thank you for spending time on this.
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? 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
…
Now, as I relax and catch my breath, I think we will still have a problem.
Yes.
(I am thinking this had been our earlier problem, too, actually.) You said the /tmp stuff gets cleared-out on a reboot (earlier in this thread). This means we will lose the .X11-unix subdir there, and will need to manually mkdir it all over again after booting-up.
It should be done automatically.
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 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.
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
Hello, Apparently the only thing I need to change in your newer Xquartz versions is to do this patch: $ cd /opt/X11/lib/X11/xinit/privileged_startx.d --- start patch --- --- ../original/10-tmpdirs 2011-04-25 18:48:26 -0500 +++ ./10-tmpdirs 2011-04-26 01:00:36 -0500 @@ -30,7 +30,7 @@ for dir in /tmp/.ICE-unix /tmp/.X11-unix /tmp/.font-unix ; do # Use mktemp rather than mkdir to avoid possible security issue # if $dir exists and is a symlink - if mktemp -d ${dir} >& /dev/null ; then + if /usr/bin/mktemp -d ${dir} >& /dev/null ; then chmod 1777 $dir chown root:wheel $dir fi --- end patch --- i.e. hard-code the path for mktemp to use Apple's *BSD version. I could not see any other usage differences between *BSD's tools and GNU-coreutils's. (I think I scanned all of your /bin/sh scripts, but other types of scripts I could not tell, nor the compiled binaries.) However, this patch _did_ fix the 2nd problem I was having. Making this simple change would likely prevent your -DFAIL_HARD from occurring so much. (After al, almost all other scripts you have, are using similar full paths. ;) ) To refresh: The 1st problem was having to "fix" the mis-spelled DISPLAY string that I was having for some reason. I ended-up moving-away Apple's Launch* plists for its version of X11, leaving the Xquartz plists to insert the "correct" DISPLAY string. I would think a "launchctl unload -w" of Apple's plists might do the same trick -- if you would consider adding such lines to the Xquartz (installer?) scripts in the correct place, then we could test it. (If you want something de-activated, then do it! Don't leave it up to some "I am first" type trick. ;) ) As for removing Xquartz and re-enabling Apple's X11, a "launchctl load -w" of Apple's plists should be run, I would think. I need to ask if you would rather me open a bug-report along these lines, then we could officially keep track of these modifications? Thank you.
On Apr 27, 2011, at 5:24 PM, SciFi wrote:
The 1st problem was having to "fix" the mis-spelled DISPLAY string that I was having for some reason. I ended-up moving-away Apple's Launch* plists for its version of X11, leaving the Xquartz plists to insert the "correct" DISPLAY string. I would think a "launchctl unload -w" of Apple's plists might do the same trick -- if you would consider adding such lines to the Xquartz (installer?) scripts in the correct place, then we could test it. (If you want something de-activated, then do it! Don't leave it up to some "I am first" type trick. ;) ) As for removing Xquartz and re-enabling Apple's X11, a "launchctl load -w" of Apple's plists should be run, I would think.
I don't think that's necessary. The fact that /Library/Launch* takes precedence over /System/Library/Launch* isn't a "trick"; it's well-documented, and I'm sure Jeremy would be among the first to hear if it were ever going to change. (In fact I'd bet he works on the same floor of the same building as the person who would be responsible for changing it.)
On 04/27/2011 07:24 PM, SciFi wrote:
Hello,
Apparently the only thing I need to change in your newer Xquartz versions is to do this patch:
$ cd /opt/X11/lib/X11/xinit/privileged_startx.d
--- start patch --- --- ../original/10-tmpdirs 2011-04-25 18:48:26 -0500 +++ ./10-tmpdirs 2011-04-26 01:00:36 -0500 @@ -30,7 +30,7 @@ for dir in /tmp/.ICE-unix /tmp/.X11-unix /tmp/.font-unix ; do # Use mktemp rather than mkdir to avoid possible security issue # if $dir exists and is a symlink - if mktemp -d ${dir}>& /dev/null ; then + if /usr/bin/mktemp -d ${dir}>& /dev/null ; then chmod 1777 $dir chown root:wheel $dir fi --- end patch ---
I don't understand what this is trying to do, in no case will $dir contain XXXXXX for mktemp to replace with randomness, so in all cases Mac OS X mktemp behaves the same as mkdir ${dir}. Coreutils's mktemp correctly says: mktemp: too few X's in template `/tmp/.ICE-unix' proper use of mktemp(1): dir=`mktemp -d /tmp/foo.XXXXXX` ... do stuff with $dir Peter
On Apr 30, 2011, at 10:36, Peter O'Gorman wrote:
# Use mktemp rather than mkdir to avoid possible security issue # if $dir exists and is a symlink
I don't understand what this is trying to do, in no case will $dir contain XXXXXX for mktemp to replace with randomness, so in all cases Mac OS X mktemp behaves the same as mkdir ${dir}.
I refer you to the comment in the script. Using mkdir can lead to a man-in-the-middle attack on those sockets. That issue was specifically addressed in XQuartz 2.2.0, three years ago (and also a Leopard update at some point... either SecUpdate2008-002 or 10.5.5): http://xquartz.macosforge.org/trac/wiki/X112.2.0 http://xquartz.macosforge.org/trac/wiki/Releases --Jeremy
participants (5)
-
Jeremy Huddleston
-
Peter O'Gorman
-
sci-fi＠hush.ai
-
SciFi
-
Will Mortensen