{"id":102,"date":"2008-10-17T17:47:02","date_gmt":"2008-10-18T00:47:02","guid":{"rendered":"http:\/\/www.smallersystems.com\/people\/mar\/blog\/?p=84"},"modified":"2008-10-17T17:47:02","modified_gmt":"2008-10-18T00:47:02","slug":"problems-with-the-os-x-1055-update-and-x11","status":"publish","type":"post","link":"https:\/\/michaelrichmond.net\/blog\/2008\/10\/17\/problems-with-the-os-x-1055-update-and-x11\/","title":{"rendered":"Problems with the OS X 10.5.5 update and X11"},"content":{"rendered":"

After upgrading to OS X 10.5.5 I ran into an issue with X11 refusing to start. I first noticed this issue as a problem with ssh<\/span> hanging while trying to establish a connection. When I dug into this problem I noticed that ssh<\/span> was hanging immediately after some X11 related operations were performed. I have ssh<\/span> configured to set up X11 forwarding unless otherwise specified on the ssh command line. By explicitly disabling X11 forwarding (using ssh -x<\/span>) the connection would connect normally. Unfortunately this means that the very cool auto-start of X11 that Apple implemented with OS X 10.5 is lost.<\/p>\n

With X11 being the suspected cause of the ssh<\/span> problem I tried launching X11.app<\/span> manually by double clicking the X11 application in \/Applications\/Utilities\/X11.app<\/span>. I noticed that X11 did not bounce in the Dock. In fact X11 did not appear in the Dock at all. That’s odd…<\/p>\n

I noticed the following lines repeating in the system logs:
\nOct 17 10:25:34 macBook com.apple.launchd[113] (org.x.startx): Throttling respawn: Will start in 10 seconds
\nOct 17 10:26:04 macBook com.apple.launchd[113] (org.x.startx): Throttling respawn: Will start in 10 seconds<\/code><\/p>\n

At least these log entries confirm that X11 is unhappy.<\/p>\n

The machine on which I first noticed this problem may have had the XQuartz<\/a> updates to X11 installed at some point. To eliminate this third-party code as a contributor to the problem I attempted to reproduce the problem a few configurations:<\/p>\n

<\/p>\n\n\n\n\n\n\n
Before upgrade<\/th>\nAfter upgrade<\/th>\nExhibits problem?<\/th>\n<\/tr>\n
OS X 10.5.4 (PPC)
XQuartz not installed<\/td>\n		OS X 10.5.5 (PPC)
XQuartz not installed<\/td>\n		yes<\/td>\n<\/tr>\n
OS X 10.5.4 (Intel)
Apple X11 installed
XQuartz not installed<\/td>\n		OS X 10.5.5 (Intel)
XQuartz not installed<\/td>\n		yes<\/td>\n<\/tr>\n
OS X 10.5.4 (Intel)
XQuartz not installed<\/td>\n		OS X 10.5.5 (Intel)
XQuartz installed (updated to 2.3.1)<\/td>\n		yes<\/td>\n<\/tr>\n
OS X 10.5.4 (Intel)
XQuartz installed<\/td>\n		OS X 10.5.5 (Intel)
XQuartz installed (updated to 2.3.1)<\/td>\n		yes<\/td>\n<\/tr>\n<\/table>\n

<\/center><\/p>\n

Since the problem can be reproduced on machines that have never had XQuartz installed I can rule out XQuartz as contributing to the problem.<\/p>\n

Based on a tip found on the Apple support forums I investigated whether any of my shell start-up scripts had any impact on the problem. It appears that Apple has made a change to the way that X11 starts in 10.5.5. These changes make X11 start-up brittle in the face of the common shell start-up idiom of using the exec<\/span> command to replace the current shell process with another process.<\/p>\n

I have used my old .profile<\/span> start-up script for bash has been in use on various machines since OS X 10.2 without problems. This old script was:<\/p>\n

\n
if [ -e \/sw\/bin\/tcsh ]; then\n    # We prefer to use the fink installed version of tcsh..\n    exec \/sw\/bin\/tcsh\nelif [ -e \/bin\/tcsh ]; then\n    # ... but we will use the OS X installed version if it exists\n    echo \"warning: using Apple version of tcsh from \/bin\/tcsh\"\n    exec \/bin\/tcsh\nelse\n    echo \"error: could not find a version of tcsh to exec!\"\n    echo \"       dropping to default bash setup (no fink environment)\"\nfi<\/pre>\n<\/blockquote>\n
Nothing exciting there other than the exec<\/span>. exec<\/span> is commonly used in this manner to dynamically change the user’s shell for typically one of two reasons:<\/p>\n