#49394 closed defect (worksforme)
xorg-server @1.17.2_0 on Snow Leopard, Mac OS X 10.6.8, launches the X clients when launched the second time
| Reported by: | ballapete (Peter "Pete" Dyballa) | Owned by: | jeremyhu (Jeremy Huddleston Sequoia) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.3.4 |
| Keywords: | Cc: | ||
| Port: | xorg-server |
Description
XQuartz 2.7.7 (xorg-server 1.17.2) form package xorg-server @1.17.2_0 does not launch the X clients when launched the first time. Shutting it down and launching it again it now launches the X clients. Accordingly on third launch no X client is launched, I have to launch the X server for a fourth time. And so on…
This version also does not accept text pasted when trying to customise its applications menu.
Attachments (2)
Change History (26)
comment:1 Changed 8 years ago by mf2k (Frank Schima)
| Cc: | jeremyhu@… removed |
|---|---|
| Owner: | changed from macports-tickets@… to jeremyhu@… |
| Port: | xorg-server added; xorg-server-devel @1.9.2 blackbox @0.70.1 Revision 1 removed |
comment:2 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
comment:3 Changed 8 years ago by ballapete (Peter "Pete" Dyballa)
Right now I have X11 in this state:
pete 108 /\ sudo spindump 76737
Password:
Sampling all processes for 10 seconds with 10 milliseconds of run time between samples
Focusing on xinit [76737]
Sampling completed, processing symbols...
Sample analysis written to file /tmp/xinit_76737.spindump.txt
Time spent in user mode (CPU seconds) : 1.906s
Time spent in kernel mode (CPU seconds) : 6.103s
Total time : 0:18.26s
CPU utilisation (percentage) : 43.8%
pete 109 /\ pstree -w -p 76737
-+= 00001 root /sbin/launchd
\-+- 76682 pete /bin/tcsh -c /opt/local/bin/startx
\-+- 76691 pete /bin/sh /opt/local/bin/startx
\-+- 76737 pete xinit /Users/pete/.xinitrc -- /Users/pete/.xserverrc :5 -dpi 133 -auth /Users/pete/.serverauth.76691
\-+= 76738 pete sh /Users/pete/.xserverrc :5 -dpi 133 -auth /Users/pete/.serverauth.76691
\--- 76739 pete X -dpi 133 -nolisten tcp
pete 110 /\ l /tmp/xinit_76737.spindump.txt
-rw------- 1 root wheel 483959 26. Nov 21:06 /tmp/xinit_76737.spindump.txt
pete 112 /\ sudo spindump 76656
Password:
Sampling all processes for 10 seconds with 10 milliseconds of run time between samples
Focusing on X11.bin [76656]
Sampling completed, processing symbols...
Sample analysis written to file /tmp/X11.bin_76656.spindump.txt
Time spent in user mode (CPU seconds) : 1.814s
Time spent in kernel mode (CPU seconds) : 5.713s
Total time : 0:17.86s
CPU utilisation (percentage) : 42.1%
pete 113 /\ pstree -w -p 76656
-+= 00001 root /sbin/launchd
\-+= 00221 pete /sbin/launchd
\--= 76656 pete /Applications/MacPorts/X11.app/Contents/MacOS/X11.bin -psn_0_12377037
pete 114 /\ l /tmp/X11.bin_76656.spindump.txt
-rw------- 1 root wheel 600774 26. Nov 21:13 /tmp/X11.bin_76656.spindump.txt
Nothing is happening on the screen. The X11 icon in Dock has a blue dot below can be clicked. The appearing menu allows to quit the application. Afterwards I can launch X11 as normal. Console shows:
Nov 26 21:16:00 sumac org.macports.X11.stub[77558]: launch_msg("CheckIn") IPC failure: Operation not permitted
Nov 26 21:16:20 sumac org.freedesktop.dbus-session[31035]: Activating service name='org.gnome.GConf'
Nov 26 21:16:20 sumac org.freedesktop.dbus-session[31035]: Successfully activated service 'org.gnome.GConf'
I am using XQuartz 2.7.7 (xorg-server 1.17.4) with xinit @1.3.4_1 (active).
Changed 8 years ago by ballapete (Peter "Pete" Dyballa)
| Attachment: | xinit_76737.spindump.txt added |
|---|
Changed 8 years ago by ballapete (Peter "Pete" Dyballa)
| Attachment: | X11.bin_76656.spindump.txt added |
|---|
comment:4 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
In your spindump, X11 looks idle.
comment:5 Changed 8 years ago by ballapete (Peter "Pete" Dyballa)
While trying to solve #49465 I had to switch between different xorg-server packages (and later xorg-server-devel packages). Some launch all clients at once, some need a relaunch:
XQuartz 2.7.7 (xorg-server 1.16.3) from xorg-server @1.16.3_0; started OK, became 2 × XQuartz 2.7.7 (xorg-server 1.16.4) from xorg-server @1.16.4_0, xorg-server @1.16.4_1 XQuartz 2.7.7 (xorg-server 1.17.4) from xorg-server @1.16.4_0, xorg-server @1.16.4_1 XQuartz 2.7.7 (xorg-server 1.17.99.901) from xorg-server-devel @1.17.99.901_0 OK XQuartz 2.7.7 (xorg-server 1.17.99.902) from xorg-server-devel @1.17.99.902_0; started 2 ×, became OK
When launching with all X clients:
Nov 28 10:59:42 sumac org.macports.X11.stub[94937]: launch_msg("CheckIn") IPC failure: Operation not permitted
Nov 28 11:00:03 sumac org.freedesktop.dbus-session[31035]: Activating service name='org.gnome.GConf'
Nov 28 11:00:03 sumac org.freedesktop.dbus-session[31035]: Successfully activated service 'org.gnome.GConf'
Nov 28 11:00:16 sumac /usr/local/bin/emacs-23.4[94982]: BUG in libdispatch: 10K549 - 1986 - 0x4
When quitting with all X clients:
Nov 28 11:03:36 sumac com.apple.launchd.peruser.502[221] ([0x0-0xc6bc6b].org.macports.X11[94854]): Exited with exit code: 1
When launching without any X client:
Nov 28 11:05:18 sumac org.macports.X11.stub[96183]: launch_msg("CheckIn") IPC failure: Operation not permitted
When quitting without any X client:
Nov 28 11:06:29 sumac org.macports.X11.stub[96183]: Xquartz: start_x11_server: (ipc/mig) server died
A problem with DBus? Following is a list of my usual X clients. I prefer Fink's gkrellm because it offers some krells I want (and seems to allow me to add plug-ins, but I should check this once).
pete 132 /\ pstree -w -p 5823
-+= 00001 root /sbin/launchd
\-+- 05767 pete /bin/tcsh -c /opt/local/bin/startx
\-+- 05776 pete /bin/sh /opt/local/bin/startx
\-+- 05823 pete xinit /Users/pete/.xinitrc -- /Users/pete/.xserverrc :0 -dpi 133 -auth /Users/pete/.serverauth.5776
|-+= 05824 pete sh /Users/pete/.xserverrc :0 -dpi 133 -auth /Users/pete/.serverauth.5776
| \--- 05825 pete X -dpi 133 -nolisten tcp
\-+= 05861 pete /sw/bin/fluxbox
|--- 05870 pete /sw/bin/gkrellm
|-+- 05871 pete /usr/local/bin/emacs-25.0.50 -geometry 100x55+1221+167 -T 25.X.50 --debug-init -fn Lucida Sans Typewriter:autohint=true:antialias=true:size=9
| \--= 05902 pete -bin/tcsh -i
\-+- 05872 pete /usr/local/bin/emacs-23.4 -geometry 99x75+27+210 -T 23.4x --debug-init -fn Lucida Sans Typewriter:autohint=true:antialias=true:size=9
\--= 05901 pete -bin/tcsh -i
pete 133 /\ pstree -w -p 5742
-+= 00001 root /sbin/launchd
\-+= 00221 pete /sbin/launchd
\--= 05742 pete /Applications/MacPorts/X11.app/Contents/MacOS/X11.bin -psn_0_13163661
I prefer Fink's fluxbox because it does not crash as Macports' one when quitting:
Process: fluxbox [8147]
Path: /opt/local/bin/fluxbox
Identifier: fluxbox
Version: ??? (???)
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Date/Time: 2015-11-28 12:37:16.192 +0100
OS Version: Mac OS X 10.6.8 (10K549)
Report Version: 6
Interval Since Last Report: 97287 sec
Crashes Since Last Report: 5
Per-App Crashes Since Last Report: 4
Anonymous UUID: B98EE308-F5B2-4632-9B82-ECEF2D42D0B9
Exception Type: EXC_BAD_ACCESS (SIGABRT)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000023
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Application Specific Information:
abort() called
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 libSystem.B.dylib 0x00007fff85e5c0b6 __kill + 10
1 libSystem.B.dylib 0x00007fff85efc9f6 abort + 83
2 fluxbox 0x00000001000630f6 (anonymous namespace)::handleSignal(int) + 756
3 libSystem.B.dylib 0x00007fff85e6e1ba _sigtramp + 26
4 fluxbox 0x00000001000a9a62 std::_Rb_tree<FbTk::Timer*, FbTk::Timer*, std::_Identity<FbTk::Timer*>, (anonymous namespace)::TimerCompare, std::allocator<FbTk::Timer*> >::erase(FbTk::Timer* const&) + 42
5 fluxbox 0x00000001000a9c41 FbTk::Timer::~Timer() + 39
6 fluxbox 0x0000000100099a3e FbTk::Menu::~Menu() + 244
7 fluxbox 0x0000000100082e3d XineramaHeadMenu<Toolbar>::~XineramaHeadMenu() + 41
8 fluxbox 0x000000010009727f FbTk::Menu::removeItem(FbTk::MenuItem*) + 143
9 fluxbox 0x0000000100097518 FbTk::Menu::removeAll() + 32
10 fluxbox 0x000000010007f1a9 Toolbar::~Toolbar() + 117
11 fluxbox 0x00000001000404f7 std::auto_ptr<Toolbar>::reset(Toolbar*) + 41
12 fluxbox 0x000000010003ebfa BScreen::~BScreen() + 68
13 fluxbox 0x0000000100061f9e void FbTk::STLUtil::destroyAndClear<std::list<BScreen*, std::allocator<BScreen*> > >(std::list<BScreen*, std::allocator<BScreen*> >&) + 30
14 fluxbox 0x000000010006093a Fluxbox::~Fluxbox() + 92
15 libSystem.B.dylib 0x00007fff85e20374 __cxa_finalize + 203
16 libSystem.B.dylib 0x00007fff85e2028c exit + 18
17 fluxbox 0x000000010005c11a Fluxbox::validateClient(WinClient const*) const + 0
18 libX11.6.dylib 0x000000010039605d _XIOError + 86
19 libX11.6.dylib 0x0000000100394a42 _XEventsQueued + 127
20 libX11.6.dylib 0x0000000100387e17 XPending + 58
21 fluxbox 0x000000010005dc02 Fluxbox::eventLoop() + 58
22 fluxbox 0x00000001000634c5 main + 961
23 fluxbox 0x000000010000c834 start + 52
Thread 0 crashed with X86 Thread State (64-bit):
rax: 0x0000000000000000 rbx: 0x000000000000000b rcx: 0x00007fff5fbfda28 rdx: 0x0000000000000000
rdi: 0x0000000000001fd3 rsi: 0x0000000000000006 rbp: 0x00007fff5fbfda40 rsp: 0x00007fff5fbfda28
r8: 0x00007fff5fbfdf48 r9: 0x000000010012c928 r10: 0x00007fff85e580fa r11: 0xffffff80002e4730
r12: 0x00000001007ac518 r13: 0x000000010012c7f0 r14: 0x000000010012c920 r15: 0x000000010012c928
rip: 0x00007fff85e5c0b6 rfl: 0x0000000000000206 cr2: 0x0000000000000023
Binary Images:
0x100000000 - 0x10011afef +fluxbox ??? (???) <CF310F8E-9CA2-0B29-35D1-624C0A7EAC07> /opt/local/bin/fluxbox
0x1001ed000 - 0x100220fef +libfontconfig.1.dylib 10.0.0 (compatibility 10.0.0) <D4ED8DD8-4419-531F-EC2E-230CED44B240> /opt/local/lib/libfontconfig.1.dylib
0x10022c000 - 0x1002afff7 +libfreetype.6.dylib 19.1.0 (compatibility 19.0.0) <0C974685-FFB8-3403-BAEC-570B35717E54> /opt/local/lib/libfreetype.6.dylib
0x1002c8000 - 0x10030aff7 +libImlib2.1.dylib 6.7.0 (compatibility 6.0.0) <F40C935B-B930-614E-4074-C05AFD03AD73> /opt/local/lib/libImlib2.1.dylib
0x100329000 - 0x100331ff7 +libXrandr.2.dylib 5.0.0 (compatibility 5.0.0) <83C2945D-AEF4-3FED-913B-E18A1017C5C1> /opt/local/lib/libXrandr.2.dylib
0x100335000 - 0x100341ff7 +libXext.6.dylib 11.0.0 (compatibility 11.0.0) <33F81AA6-EBBD-F883-7DE5-7C766BC526B5> /opt/local/lib/libXext.6.dylib
0x100347000 - 0x100357ff7 +libXft.2.dylib 6.2.0 (compatibility 6.0.0) <C1528539-E687-6224-DDBC-E27C7EE3ACC6> /opt/local/lib/libXft.2.dylib
0x10035d000 - 0x10035eff7 +libXinerama.1.dylib 2.0.0 (compatibility 2.0.0) <1E639285-74C1-3B76-77F7-C1096A2D9160> /opt/local/lib/libXinerama.1.dylib
0x100361000 - 0x10036efe7 +libXpm.4.dylib 16.0.0 (compatibility 16.0.0) <1DB11324-9F98-1B08-E261-F11A459D4C88> /opt/local/lib/libXpm.4.dylib
0x100372000 - 0x100480fe7 +libX11.6.dylib 10.0.0 (compatibility 10.0.0) <91B1A3A4-0B7D-7AC4-E01A-EE6888FE48CA> /opt/local/lib/libX11.6.dylib
0x1004a3000 - 0x1004aafff +libXrender.1.dylib 5.0.0 (compatibility 5.0.0) <AF5E27D3-F6EB-3CF9-A0A6-658A17CF3594> /opt/local/lib/libXrender.1.dylib
0x1004ae000 - 0x1005acfef +libiconv.2.dylib 8.1.0 (compatibility 8.0.0) <065A36D7-5F15-7B4C-C3F4-D9B23DFC36A3> /opt/local/lib/libiconv.2.dylib
0x1005ba000 - 0x1005d9fef +libexpat.1.dylib 8.0.0 (compatibility 8.0.0) <E5DCF28A-CE24-1AC4-81AA-D8538A479E63> /opt/local/lib/libexpat.1.dylib
0x1005e0000 - 0x1005f2ff7 +libz.1.dylib 1.2.8 (compatibility 1.0.0) <A07EE7AE-FDB1-F5E8-8B12-06B7B616DA94> /opt/local/lib/libz.1.dylib
0x1005f6000 - 0x100604fff +libbz2.1.0.dylib 1.0.6 (compatibility 1.0.0) <32DDD005-5216-7E11-F287-4C818B579A0F> /opt/local/lib/libbz2.1.0.dylib
0x100609000 - 0x100631fff +libpng16.16.dylib 36.0.0 (compatibility 36.0.0) <7C4C5EB9-6D38-34CA-B540-B8453358EDAE> /opt/local/lib/libpng16.16.dylib
0x10063a000 - 0x10064eff7 +libxcb.1.dylib 3.0.0 (compatibility 3.0.0) <DC206811-67B1-3A26-82A4-C4232FD2162B> /opt/local/lib/libxcb.1.dylib
0x10065b000 - 0x10065cff7 +libXau.6.dylib 7.0.0 (compatibility 7.0.0) <5CC8358C-C7E2-43CE-8A96-C4B9ADF645B0> /opt/local/lib/libXau.6.dylib
0x10065f000 - 0x100663ff7 +libXdmcp.6.dylib 7.0.0 (compatibility 7.0.0) <F7482296-7579-B8E2-AA24-3897685EE15B> /opt/local/lib/libXdmcp.6.dylib
0x100666000 - 0x10066fff7 +libintl.8.dylib 10.4.0 (compatibility 10.0.0) <DF739973-F3C7-33B8-A2BF-49D8E7F98F17> /opt/local/lib/libintl.8.dylib
0x7fff5fc00000 - 0x7fff5fc3be0f dyld 132.1 (???) <DD3F7F3E-8612-A7BD-F508-9EF29132C419> /usr/lib/dyld
0x7fff835a6000 - 0x7fff835b7ff7 libz.1.dylib 1.2.3 (compatibility 1.0.0) <5BAFAE5C-2307-C27B-464D-582A10A6990B> /usr/lib/libz.1.dylib
0x7fff84420000 - 0x7fff84597fe7 com.apple.CoreFoundation 6.6.6 (550.44) <BB4E5158-E47A-39D3-2561-96CB49FA82D4> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x7fff8510a000 - 0x7fff85187fef libstdc++.6.dylib 7.9.0 (compatibility 7.0.0) <35ECA411-2C08-FD7D-11B1-1B7A04921A5C> /usr/lib/libstdc++.6.dylib
0x7fff8542a000 - 0x7fff855e8fff libicucore.A.dylib 40.0.0 (compatibility 1.0.0) <97A75BFB-0DB6-6F44-36B0-97B7F7208ABB> /usr/lib/libicucore.A.dylib
0x7fff85e0d000 - 0x7fff85fcefef libSystem.B.dylib 125.2.11 (compatibility 1.0.0) <9AB4F1D1-89DC-0E8A-DC8E-A4FE4D69DB69> /usr/lib/libSystem.B.dylib
0x7fff88544000 - 0x7fff88590fff libauto.dylib ??? (???) <328CCF97-091D-C529-E576-C78583445711> /usr/lib/libauto.dylib
0x7fff8865f000 - 0x7fff88663ff7 libmathCommon.A.dylib 315.0.0 (compatibility 1.0.0) <95718673-FEEE-B6ED-B127-BCDBDB60D4E5> /usr/lib/system/libmathCommon.A.dylib
0x7fff8a132000 - 0x7fff8a1e8ff7 libobjc.A.dylib 227.0.0 (compatibility 1.0.0) <03140531-3B2D-1EBA-DA7F-E12CC8F63969> /usr/lib/libobjc.A.dylib
0x7fffffe00000 - 0x7fffffe01fff libSystem.B.dylib ??? (???) <9AB4F1D1-89DC-0E8A-DC8E-A4FE4D69DB69> /usr/lib/libSystem.B.dylib
comment:6 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
| Resolution: | → worksforme |
|---|---|
| Status: | new → closed |
Ok, please report that fluxbox crash separately.
As for the X11 issue in particular, I don't see any issues here.
comment:7 Changed 8 years ago by ballapete (Peter "Pete" Dyballa)
Now using xorg-server-devel @1.17.99.902_0, which as well needs two launches to open all X clients, I performed after the first launch:
pete 211 /\ pstree -w -p 51293
-+= 00001 root /sbin/launchd
\-+- 51237 pete /bin/tcsh -c /opt/local/bin/startx
\-+- 51246 pete /bin/sh /opt/local/bin/startx
\-+- 51291 pete xinit /Users/pete/.xinitrc -- /Users/pete/.xserverrc :1 -dpi 133 -auth /Users/pete/.serverauth.51246
\-+= 51292 pete sh /Users/pete/.xserverrc :1 -dpi 133 -auth /Users/pete/.serverauth.51246
\--- 51293 pete X -dpi 133 -nolisten tcp
and later:
pete 223 /\ pstree -w -p 51730
-+= 00001 root /sbin/launchd
\-+- 51670 pete /bin/tcsh -c /opt/local/bin/startx
\-+- 51679 pete /bin/sh /opt/local/bin/startx
\-+- 51728 pete xinit /Users/pete/.xinitrc -- /Users/pete/.xserverrc :0 -dpi 133 -auth /Users/pete/.serverauth.51679
\-+= 51729 pete sh /Users/pete/.xserverrc :0 -dpi 133 -auth /Users/pete/.serverauth.51679
\--- 51730 pete X -dpi 133 -nolisten tcp
So it's obvious that the first time the wrong X display, :1, is used. In that case the execution of my .xinitrc seems to stall because of this line:
xrdb -all -merge ${HOME}/.Xresources
so that no X client is started on any display.
The question is: What causes the use of the wrong display?
comment:8 follow-up: 9 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
It's not *wrong*. It's perfectly *correct* for it to use :1 because :0 is locked and unavailable.
The use of :1 should not cause problems unless you are hardcoding :0 somewhere and expecting that to be the DISPLAY. Don't do that.
comment:9 follow-up: 10 Changed 8 years ago by ballapete (Peter "Pete" Dyballa)
Replying to jeremyhu@…:
It's not *wrong*.
Yes, it just means another display. Which does not exist …
It's perfectly *correct* for it to use :1 because :0 is locked and unavailable.
Why is it locked? I shut down the previous X.Org server a minute or two ago. Do I have to wait longer? Do I have to reboot? Or log off/log in?
The use of :1 should not cause problems unless you are hardcoding :0 somewhere and expecting that to be the DISPLAY. Don't do that.
I am not hardcoding anything like that. Why should I do that? Make such effort?
comment:10 follow-up: 11 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Replying to Peter_Dyballa@…:
Yes, it just means another display. Which does not exist.
Yes, it does exist. It is created by this process.
It's perfectly *correct* for it to use :1 because :0 is locked and unavailable.
Why is it locked? I shut down the previous X.Org server a minute or two ago. Do I have to wait longer? Do I have to reboot? Or log off/log in?
The lock file is torn down when quitting XQuartz. Check /tmp.
The use of :1 should not cause problems unless you are hardcoding :0 somewhere and expecting that to be the DISPLAY. Don't do that.
I am not hardcoding anything like that. Why should I do that? Make such effort?
You should NOT be doing that. My point is that it should not matter to you what DISPLAY is used.
comment:11 Changed 8 years ago by ballapete (Peter "Pete" Dyballa)
Replying to jeremyhu@…:
Replying to Peter_Dyballa@…:
Yes, it just means another display. Which does not exist.
Yes, it does exist. It is created by this process.
Maybe not properly…
At the second launch of X11, with $DISPLAY set to :0, my ~/.xinitrc is successfully executed so that some X clients open their windows. At the first try, when $DISPLAY is set by whatever to :1, my ~/.xinitrc is not successfully executed so that no X client opens its window(s). The ps command (actually pstree) does not find any process related to these X clients.
comment:12 follow-up: 13 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Then I suggest you do a little sleuthing. Look at /tmp, check lsof, etc.
comment:13 Changed 8 years ago by ballapete (Peter "Pete" Dyballa)
Replying to jeremyhu@…:
Then I suggest you do a little sleuthing. Look at /tmp, check lsof, etc.
Ten minutes after I quit X11.app the socket /tmp/.X11-unix/X0 still exists. Is this correct behaviour?
Lsof does not show any user of the socket.
comment:14 follow-up: 15 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
No, it should be removed. You should investigate why it's not getting removed.
comment:15 follow-up: 16 Changed 8 years ago by ballapete (Peter "Pete" Dyballa)
Replying to jeremyhu@…:
No, it should be removed. You should investigate why it's not getting removed.
How can I do that? It's removal is an automatic built into the X server…
Since the socket still existed after sleep this morning, I launched XQuartz 2.7.7 (xorg-server 1.17.4), xorg-server @1.17.4_1. The first time it found that socket and tried to open windows on :1:
pete 60 /\ pstree -w -p 19623
-+= 00001 root /sbin/launchd
\-+- 19565 pete /bin/tcsh -c /opt/local/bin/startx
\-+- 19574 pete /bin/sh /opt/local/bin/startx
\-+- 19621 pete xinit /Users/pete/.xinitrc -- /Users/pete/.xserverrc :1 -dpi 133 -auth /Users/pete/.serverauth.19574
\-+= 19622 pete sh /Users/pete/.xserverrc :1 -dpi 133 -auth /Users/pete/.serverauth.19574
\--- 19623 pete X -dpi 133 -nolisten tcp
without success, no X client (GNU Emacsen, gkrellm) appeared. And also no /tmp/.X11-unix/X1 socket. When I quit, it at least successfully deleted /tmp/.X11-unix/X0. On next launch all went fine.
comment:16 follow-ups: 17 18 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Replying to Peter_Dyballa@…:
Replying to jeremyhu@…:
No, it should be removed. You should investigate why it's not getting removed.
How can I do that? It's removal is an automatic built into the X server…
No, it is done by the startx script (a shell script).
I'd start by removing your custom /Users/pete/.xinitrc and /Users/pete/.xserverrc scripts.
comment:17 follow-up: 19 Changed 8 years ago by ballapete (Peter "Pete" Dyballa)
Replying to jeremyhu@…:
Replying to Peter_Dyballa@…:
How can I do that? It's removal is an automatic built into the X server…
No, it is done by the startx script (a shell script).
Could it be that /opt/local/lib/X11/xinit/privileged_startx handles this?
BTW, /opt/local/bin/startx uses the pathname /opt/local/etc/X11/xinit/privileged_startx, which does not exist…
comment:18 Changed 8 years ago by ballapete (Peter "Pete" Dyballa)
Replying to jeremyhu@…:
I'd start by removing your custom /Users/pete/.xinitrc and /Users/pete/.xserverrc scripts.
This seems to make the situation worse: X11 is started twice the first time I launch /Applications/MacPorts/X11.app:
pete 74 /\ PS start
UID PID PPID F CPU PRI NI SZ RSS WCHAN S ADDR TTY TIME CMD
502 45006 1 4004 0 31 0 2439400 900 - S ffffff8014eddaa0 ?? 0:00.01 /bin/tcsh -c /opt/local/bin/startx
502 45015 45006 4004 0 31 0 2435544 884 - S ffffff801af6c240 ?? 0:00.01 /bin/sh /opt/local/bin/startx
502 45134 223 4004 0 33 0 2452980 632 - S ffffff80182bc240 ?? 0:00.01 /opt/X11/lib/X11/xinit/launchd_startx /opt/X11/bin/startx -- /opt/X11/bin/Xquartz
502 45135 45134 4004 0 31 0 2435544 884 - S ffffff8017a07b60 ?? 0:00.01 /bin/sh /opt/X11/bin/startx -- /opt/X11/bin/Xquartz
pete 75 /\ pstree -w -p 45015
-+= 00001 root /sbin/launchd
\-+- 45006 pete /bin/tcsh -c /opt/local/bin/startx
\-+- 45015 pete /bin/sh /opt/local/bin/startx
\-+- 45062 pete xinit /opt/local/etc/X11/xinit/xinitrc -- /opt/local/bin/X :0 -dpi 133 -auth /Users/pete/.serverauth.45015
|--= 45063 pete /opt/local/bin/X :0 -dpi 133 -auth /Users/pete/.serverauth.45015
\-+= 45076 pete /opt/local/bin/metacity
|-+- 45104 pete xterm -class UXTerm -title uxterm -u8
| \--= 45171 pete -csh
|--- 45105 pete /sw/bin/gkrellm
|--- 45107 pete emacs-25.0.50 -xrm Emacs*iconName: TeX Live-2013 -T TeX Live 2013@25.0.50 -geometry 133x75+1133+133 --debug-init -fn Lucida Sans Typewriter:autohint=true:antialias=true:size=9
|--- 45108 pete /usr/local/bin/emacs-23.4 -geometry 123x75+27+123 -T 23.4 --debug-init -fn Lucida Sans Typewriter:autohint=true:antialias=true:size=9
\--- 45533 pete libgtop-server
pete 77 /\ la -t /tmp/
insgesamt 16
srwxrwxrwx 1 pete wheel 0 30. Dez 00:23 dbus-K4DfOaRGr2
-r--r--r-- 1 pete wheel 11 30. Dez 00:22 .X1-lock
drwxrwxrwt 2 root wheel 102 30. Dez 00:22 .X11-unix
drwxrwxrwt 2 root wheel 68 30. Dez 00:22 .ICE-unix
drwx------ 3 root wheel 102 30. Dez 00:22 .X11-unix-jZQSAv4i
drwxrwxrwt 2 root wheel 68 30. Dez 00:22 .font-unix
-r--r--r-- 1 pete wheel 11 30. Dez 00:22 .X0-lock
pete 78 /\ la -t /tmp/.X11-unix
insgesamt 0
srwxrwxrwx 1 pete wheel 0 30. Dez 00:23 X1
The situation improves (only one X server gets started), but the number of sockets, locks, and displays increases:
pete 89 /\ pstree -w -p 49699
-+= 00001 root /sbin/launchd
\-+- 49699 pete /bin/tcsh -c /opt/local/bin/startx
\-+- 49708 pete /bin/sh /opt/local/bin/startx
\-+- 49754 pete xinit /opt/local/etc/X11/xinit/xinitrc -- /opt/local/bin/X :2 -dpi 133 -auth /Users/pete/.serverauth.49708
|--= 49755 pete /opt/local/bin/X :2 -dpi 133 -auth /Users/pete/.serverauth.49708
\-+= 49774 pete /sw/bin/fluxbox
|-+- 49793 pete xterm -class UXTerm -title uxterm -u8
| \--= 49828 pete -csh
|--- 49794 pete /sw/bin/gkrellm
|-+- 49796 pete emacs-25.0.50 -xrm Emacs*iconName: TeX Live-2013 -T TeX Live 2013@25.0.50 -geometry 133x75+1133+133 --debug-init -fn Lucida Sans Typewriter:autohint=true:antialias=true:size=9
| \--= 50299 pete -bin/tcsh -i
\-+- 49797 pete /usr/local/bin/emacs-23.4 -geometry 123x75+27+123 -T 23.4 --debug-init -fn Lucida Sans Typewriter:autohint=true:antialias=true:size=9
\--= 49958 pete -bin/tcsh -i
pete 90 /\ la -t /tmp/
insgesamt 20
drwxrwxrwt 2 root wheel 102 30. Dez 00:42 .X11-unix
-r--r--r-- 1 pete wheel 11 30. Dez 00:42 .X2-lock
srwxrwxrwx 1 pete wheel 0 30. Dez 00:23 dbus-K4DfOaRGr2
-r--r--r-- 1 pete wheel 11 30. Dez 00:22 .X1-lock
drwxrwxrwt 2 root wheel 68 30. Dez 00:22 .ICE-unix
drwx------ 3 root wheel 102 30. Dez 00:22 .X11-unix-jZQSAv4i
drwxrwxrwt 2 root wheel 68 30. Dez 00:22 .font-unix
-r--r--r-- 1 pete wheel 11 30. Dez 00:22 .X0-lock
pete 91 /\ la -t /tmp/.X11-unix
insgesamt 0
srwxrwxrwx 1 pete wheel 0 30. Dez 00:42 X2
comment:19 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Replying to Peter_Dyballa@…:
Replying to jeremyhu@…:
Replying to Peter_Dyballa@…:
How can I do that? It's removal is an automatic built into the X server…
No, it is done by the startx script (a shell script).
Could it be that /opt/local/lib/X11/xinit/privileged_startx handles this?
Sorry, I was wrong. startx checks the locks to determine what display to use. The server itself creates (and removes) the lockfile. Look in os/utils.c, specifically at LockServer() and UnlockServer().
BTW, /opt/local/bin/startx uses the pathname /opt/local/etc/X11/xinit/privileged_startx, which does not exist…
Well that would be problematic, since privileged_startx is what sets up permissions in /tmp and your font cache.
comment:20 follow-up: 21 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
The privileged_startx install path issue has been resolved in r144011. Please see if that helps with your issue.
comment:21 Changed 8 years ago by ballapete (Peter "Pete" Dyballa)
Replying to jeremyhu@…:
The privileged_startx install path issue has been resolved in r144011. Please see if that helps with your issue.
I have the new version of xinit active and the only change I can observe is that now xorg-server @1.17.4_1 also leaves the socket and the lock file intact. I could observe that the numbers in the lock file and the socket are incremented and that /tmp/.X11-unix can hold more than one socket.
comment:22 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Yes, all the sockets are in /tmp/.X11-unix, an it's expected that they would increase if not removed.
Not cleaning up after itself was seen before, in http://xquartz.macosforge.org/trac/ticket/823 and was addressed by just waiting a while longer for the server to terminate before falling-back and killing it from the app thread, see ec6007e6f7772a90713c9c51c64359229961ce27.
I suggest you edit -[X11Controller applicationWillTerminate:] to cause the thread to sleep forever instead of just 5 seconds before the exit(1). Then, when you quit X11.app, I suspect it will either not quit or will take more than 5 seconds to quit. Investigate why it's taking so long (spindumps, etc).
comment:23 Changed 8 years ago by ballapete (Peter "Pete" Dyballa)
Is there a way to log to a file output from ~/.xinitrc or the files in ~/.xinitrc.d? Maybe some command inside these shell scripts produces some useful output!
The log file ~/Library/Logs/X11/org.macports.log contains a possible error in the first line and later another possible one when trying to load a keymap file:
X11.app: DISPLAY ("/tmp/launch-7CzJoj/org.macosforge.xquartz:0") does not match our id ("org.macports"), unsetting.
X11.app: main(): argc=2
argv[0] = /Applications/MacPorts/X11.app/Contents/MacOS/X11.bin
argv[1] = -psn_0_6989482
Waiting for startup parameters via Mach IPC.
X11.app: No launchd socket handed off, unsetting DISPLAY
X11.app: do_start_x11_server(): argc=6
argv[0] = /opt/local/bin/X
argv[1] = :0
argv[2] = -dpi
argv[3] = 133
argv[4] = -auth
argv[5] = /Users/pete/.serverauth.87253
[4097348.971] Xquartz starting:
[4097348.971] X.Org X Server 1.17.4
[4097348.971] Build Date: 20151226
[4097348.977] x: 0, y: 0, w: 1920, h: 1178
[4097349.224] (II) GLX: Initialized Core OpenGL GL provider for screen 0
[4097350.523] X11.app: DarwinProcessFDAdditionQueue_thread: Sleeping to allow xinitrc to catchup.
[4097350.585] (EE) Error loading keymap /tmp/server-0.xkm
[4097350.601] (EE) XKB: Failed to load keymap. Loading default keymap instead.
[4097364.742] noPseudoramiXExtension=0, pseudoramiXNumScreens=1
[4097364.960] noPseudoramiXExtension=0, pseudoramiXNumScreens=1
[4097376.256] noPseudoramiXExtension=0, pseudoramiXNumScreens=1
The log file with X.Org X Server 1.18.0 is quite the same.
comment:24 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
stdout and stderr is already directed to syslog by launchd_startx.
If you want to redirect it on your own, go ahead. As you mentioned, they're just shell scripts.
in the first line
Nope, that's not an error. That's expected behavior. Your DISPLAY envvar is setup for XQuartz.app, and that line is telling you as much.
The keymap log is expected as well. We don't use static keymaps. We generate them ourselves.
I can't reproduce this.
Can you elaborate? What happens when you try?
Can you take a spindump when in this state?