Re: [Xquartz-dev] Xquartz-dev post from n8gray@n8gray.org requires approval
On Thu, Oct 1, 2009 at 1:12 AM, Jeremy Huddleston <jeremyhu@apple.com> wrote:
subscribe to the list and resend.
Oops, sent from the wrong account. Should work this time.
You said you verified DISPLAY is being set correctly, but you failed to mention what it was being set to.
Yes, it was set correctly and I didn't feel the need to copy/paste it.
Also, I mentioned in the release notes that this would cause the system X11.app to fail to function.
Ok, but that wasn't the problem. I wasn't trying to run the system X11.app at all. I was trying to get XQuartz to launch in response to an X client.
Running launchctl through sudo causes it to run as root. You want to manage your launch agent, not the launch daemons, so you don't want to use sudo.
Yes, eventually I figured that out. It would help if launchctl actually mentioned *why* unloading failed, and if "launchctl list" indicated some difference between daemons and agents.
The version issue is known and fixed. Just launch XQuartz.app manually.
Ok, I'll try again with the next release then. Cheers, -n8
From: Nathan Gray <n8gray@n8gray.org> Date: September 30, 2009 17:36:12 PDT To: Developer talk about Xquartz <xquartz-dev@lists.macosforge.org> Subject: Re: [Xquartz-dev] 2.4.1_alpha1 for SnowLeopard
Hi guys,
This release doesn't auto-launch XQuartz on my Snow Lep system when I start an X client. I've verified that DISPLAY is set properly (i.e. it's set by launchd). It looks like the system X11 is getting mixed into things, because after launching an X client I end up with processes like this (note the /usr/X11/bin/fc-cache):
[n8gray@golux]% allps | grep X11 root 49459 0.0 0.0 31 /opt/X11/lib/X11/xinit/privileged_startx -d /opt/X11/lib/X11/xinit/privileged_startx.d n8gray 53007 3.1 0.0 31 /bin/sh /opt/X11/bin/startx n8gray 53012 1.9 0.0 31 /bin/bash /opt/X11/bin/font_cache root 53029 2.7 0.0 31 /bin/bash /opt/X11/bin/font_cache -s n8gray 53045 13.1 0.1 33 /usr/X11/bin/fc-cache n8gray 53091 0.6 0.0 31 /opt/X11/bin/xinit /opt/X11/lib/X11/xinit/xinitrc -- /opt/X11/bin/X :0 -nolisten tcp -auth /Users/n8gray/.serverauth.53007 n8gray 53102 0.0 0.0 31 grep --color=auto X11
Do I have to disable the system's X11 launch agent? I've tried the following:
[n8gray@golux]% launchctl list | grep startx - 0 org.x.startx - 1 org.macosforge.xquartz.startx [n8gray@golux]% sudo launchctl unload -w /System/Library/LaunchAgents/org.x.startx.plist Password: launchctl: Error unloading: org.x.startx
Ok, I just randomly discovered that the key is to NOT use sudo when unloading that launch agent, no thanks to launchctl's lame error non-messages. Still, it doesn't seem to help. I've even tried moving /usr/X11 aside and symlinking it to /opt/X11. Nothing works. Console reports these messages:
9/30/09 5:25:54 PM org.macosforge.xquartz.privileged_startx[1697] font_cache: Done 9/30/09 5:26:02 PM org.macosforge.xquartz.startx[3609] font_cache: Scanning user font directories to generate X11 font caches 9/30/09 5:26:02 PM org.macosforge.xquartz.privileged_startx[1697] font_cache: Scanning system font directories to generate X11 font caches 9/30/09 5:26:02 PM org.macosforge.xquartz.startx[3609] font_cache: Updating FC cache 9/30/09 5:26:02 PM defaults[3646] The domain/default pair of (org.macosforge.xquartz.X11, dpi) does not exist 9/30/09 5:26:02 PM org.macosforge.xquartz.startx[3609] xauth: creating new authority file /Users/n8gray/.serverauth.3609 9/30/09 5:26:02 PM org.macosforge.xquartz.startx[3609] Xquartz: Could not find a new enough X11.app LSFindApplicationForInfo() returned 9/30/09 5:26:02 PM org.macosforge.xquartz.startx[3609] X11.app = /Applications/Utilities/XQuartz.app 9/30/09 5:26:02 PM org.macosforge.xquartz.startx[3609] Version = 2.4.10 (0), Expected Version > 2.3.0 or 2.1.6 9/30/09 5:26:02 PM org.macosforge.xquartz.privileged_startx[1697] font_cache: Updating FC cache 9/30/09 5:26:04 PM org.macosforge.xquartz.startx[3609] font_cache: Done 9/30/09 5:26:04 PM org.macosforge.xquartz.startx[3609] giving up. 9/30/09 5:26:04 PM org.macosforge.xquartz.startx[3609] /opt/X11/bin/xinit: Connection refused (errno 61): unable to connect to X server 9/30/09 5:26:04 PM org.macosforge.xquartz.startx[3609] /opt/X11/bin/xinit: No such process (errno 3): Server error. 9/30/09 5:26:04 PM com.apple.launchd.peruser.504[255] (org.macosforge.xquartz.startx[3609]) Exited with exit code: 1 9/30/09 5:26:05 PM org.macosforge.xquartz.privileged_startx[1697] font_cache: Done 9/30/09 5:26:12 PM org.macosforge.xquartz.startx[3771] font_cache: Scanning user font directories to generate X11 font caches 9/30/09 5:26:12 PM org.macosforge.xquartz.privileged_startx[1697] font_cache: Scanning system font directories to generate X11 font caches 9/30/09 5:26:12 PM org.macosforge.xquartz.startx[3771] font_cache: Updating FC cache 9/30/09 5:26:12 PM defaults[3807] The domain/default pair of (org.macosforge.xquartz.X11, dpi) does not exist 9/30/09 5:26:12 PM org.macosforge.xquartz.startx[3771] xauth: creating new authority file /Users/n8gray/.serverauth.3771 9/30/09 5:26:12 PM org.macosforge.xquartz.startx[3771] Xquartz: Could not find a new enough X11.app LSFindApplicationForInfo() returned 9/30/09 5:26:12 PM org.macosforge.xquartz.startx[3771] X11.app = /Applications/Utilities/XQuartz.app 9/30/09 5:26:12 PM org.macosforge.xquartz.startx[3771] Version = 2.4.10 (0), Expected Version > 2.3.0 or 2.1.6 9/30/09 5:26:12 PM org.macosforge.xquartz.privileged_startx[1697] font_cache: Updating FC cache 9/30/09 5:26:14 PM org.macosforge.xquartz.startx[3771] font_cache: Done 9/30/09 5:26:14 PM org.macosforge.xquartz.startx[3771] giving up. 9/30/09 5:26:14 PM org.macosforge.xquartz.startx[3771] /opt/X11/bin/xinit: Connection refused (errno 61): unable to connect to X server 9/30/09 5:26:14 PM org.macosforge.xquartz.startx[3771] /opt/X11/bin/xinit: No such process (errno 3): Server error. 9/30/09 5:26:14 PM com.apple.launchd.peruser.504[255] (org.macosforge.xquartz.startx[3771]) Exited with exit code: 1
Any suggestions? Thanks, -n8
On Wed, Sep 16, 2009 at 6:47 PM, Jeremy Huddleston <jeremyhu@apple.com> wrote:
So, I finally resolved my build issues. Here's 2.4.1_alpha1 for
SnowLeopard.
It makes that ptty resize option on by default to workaround the bug in
xterm/ptty.
It installs in /opt/X11, /Library/Launch*,
/Applications/Utilities/XQuartz.app
This release is the first to allow differnt X11 servers to "own" $DISPLAY.
You can pick which X11 server will actually "own" it by disabling the
others' startx LaunchAgents. You will notice (after logout/login) that
$DISPLAY now has "org.macosforge.xquartz" in its filename which identifies
XQuartz.app as the owner.
That being said, SL's X11 assumes that it owns $DISPLAY. If you run X11.app
while it's not the owner, it will actually trigger XQuartz.app to start and
wait forever for its own startup notification. Hopefully I can get X11 a
SoftwareUpdate in a future dot release of OSX to update this (or you can do
it on your own by copying over a new X11.bin into X11.app).
X11 servers that don't "own" DISPLAY will unset DISPLAY and their children
will continue to use the traditional DISPLAY values (":1", ":2", etc).
I did not update the release notes in the .pkg, so you'll need to check the
site for a full changelog:
http://xquartz.macosforge.org/trac/wiki/ChangeLog
Here's the dmg:
http://static.macosforge.org/xquartz/downloads/SL/X11-2.4.1_alpha1.dmg
Note:
X11 alpha/beta updates will only be released for SL. rcs will be rolled for
both Leo and SL. It's just not worth the extra overhead.
Thanks,
Jeremy
_______________________________________________
Xquartz-dev mailing list
Xquartz-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
From: xquartz-dev-request@lists.macosforge.org Date: September 30, 2009 17:36:15 PDT Subject: confirm 5fb143db8ff0484d999a59ab4db01aa83baaa344
If you reply to this message, keeping the Subject: header intact, Mailman will discard the held message. Do this if the message is spam. If you reply to this message and include an Approved: header with the list password in it, the message will be approved for posting to the list. The Approved: header can also appear in the first line of the body of the reply.
On Oct 1, 2009, at 09:42, Nathan Gray wrote:
On Thu, Oct 1, 2009 at 1:12 AM, Jeremy Huddleston <jeremyhu@apple.com> wrote:
subscribe to the list and resend.
Oops, sent from the wrong account. Should work this time.
You said you verified DISPLAY is being set correctly, but you failed to mention what it was being set to.
Yes, it was set correctly and I didn't feel the need to copy/paste it.
Yes, well, could you please humor me and copy/paste it? As mentioned in the release notes, DISPLAY is now different in this version than it was before. It should look something like: /tmp/launch-hzV273/org.macosforge.xquartz:0
Also, I mentioned in the release notes that this would cause the system X11.app to fail to function.
Ok, but that wasn't the problem. I wasn't trying to run the system X11.app at all. I was trying to get XQuartz to launch in response to an X client.
Yes, that is not functioning properly in 2.4.1_alpha1 because of CFBundleGetVersionNumber being so restrictive. I nuked that check since I doubt anyone will try using /usr/X11/bin/XQuartz from these new releases with an old server. http://cgit.freedesktop.org/xorg/xserver/commit/?id=a2cd21177859eb45320a94c9...
Running launchctl through sudo causes it to run as root. You want to manage your launch agent, not the launch daemons, so you don't want to use sudo.
Yes, eventually I figured that out. It would help if launchctl actually mentioned *why* unloading failed, and if "launchctl list" indicated some difference between daemons and agents.
launchctl list will list your LaunchAgents sudo launchctl list will list the system's LaunchDaemons Check out 'man launchctl'
On Thu, Oct 1, 2009 at 11:24 AM, Jeremy Huddleston <jeremyhu@apple.com> wrote:
On Oct 1, 2009, at 09:42, Nathan Gray wrote:
On Thu, Oct 1, 2009 at 1:12 AM, Jeremy Huddleston <jeremyhu@apple.com> wrote:
You said you verified DISPLAY is being set correctly, but you failed to mention what it was being set to.
Yes, it was set correctly and I didn't feel the need to copy/paste it.
Yes, well, could you please humor me and copy/paste it? As mentioned in the release notes, DISPLAY is now different in this version than it was before. It should look something like: /tmp/launch-hzV273/org.macosforge.xquartz:0
Yes, I know that. As I said, it was set correctly. It's not set that way anymore because I went back to the standard X11.app for now.
Also, I mentioned in the release notes that this would cause the system X11.app to fail to function.
Ok, but that wasn't the problem. I wasn't trying to run the system X11.app at all. I was trying to get XQuartz to launch in response to an X client.
Yes, that is not functioning properly in 2.4.1_alpha1 because of CFBundleGetVersionNumber being so restrictive. I nuked that check since I doubt anyone will try using /usr/X11/bin/XQuartz from these new releases with an old server.
http://cgit.freedesktop.org/xorg/xserver/commit/?id=a2cd21177859eb45320a94c9...
Ok, glad to hear it.
Running launchctl through sudo causes it to run as root. You want to manage your launch agent, not the launch daemons, so you don't want to use sudo.
Yes, eventually I figured that out. It would help if launchctl actually mentioned *why* unloading failed, and if "launchctl list" indicated some difference between daemons and agents.
launchctl list will list your LaunchAgents sudo launchctl list will list the system's LaunchDaemons
Check out 'man launchctl'
I have RTFM many, many times, and that is a complete surprise to me. Sorry, that's definitely not in the man page: list [-x] [label] With no arguments, list all of the jobs loaded into launchd in three columns. ... In fact, the entire man page makes no mention of *any* difference between running as root and as a user, except obliquely as a mention that LaunchAgent config files must be owned by the user loading them. This behavior is very strange, very unexpected. Looking back, it probably explains why nearly every interaction I've had with launchctl has ended in failure and frustration. I'm sure I was using sudo, or not using it, at the wrong moment. Sorry, I know this is off topic but I can't tell you how many times launchctl has spoiled my afternoon. So you can't even get a list of the running LaunchDaemons without superuser access? Is there some security reason for that? Cheers, -n8 -- http://n8gray.org
participants (2)
-
Jeremy Huddleston
-
Nathan Gray