Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#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)

xinit_76737.spindump.txt (472.6 KB) - added by ballapete (Peter "Pete" Dyballa) 9 years ago.
X11.bin_76656.spindump.txt (586.7 KB) - added by ballapete (Peter "Pete" Dyballa) 9 years ago.

Download all attachments as: .zip

Change History (26)

comment:1 Changed 9 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 9 years ago by jeremyhu (Jeremy Huddleston Sequoia)

I can't reproduce this.

Can you elaborate? What happens when you try?

Can you take a spindump when in this state?

comment:3 Changed 9 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 9 years ago by ballapete (Peter "Pete" Dyballa)

Attachment: xinit_76737.spindump.txt added

Changed 9 years ago by ballapete (Peter "Pete" Dyballa)

Attachment: X11.bin_76656.spindump.txt added

comment:4 Changed 9 years ago by jeremyhu (Jeremy Huddleston Sequoia)

In your spindump, X11 looks idle.

comment:5 Changed 9 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 9 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Resolution: worksforme
Status: newclosed

Ok, please report that fluxbox crash separately.

As for the X11 issue in particular, I don't see any issues here.

comment:7 Changed 9 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 Changed 9 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 in reply to:  8 ; Changed 9 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 in reply to:  9 ; Changed 9 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 in reply to:  10 Changed 9 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 Changed 9 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Then I suggest you do a little sleuthing. Look at /tmp, check lsof, etc.

comment:13 in reply to:  12 Changed 9 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 Changed 9 years ago by jeremyhu (Jeremy Huddleston Sequoia)

No, it should be removed. You should investigate why it's not getting removed.

comment:15 in reply to:  14 ; Changed 9 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 in reply to:  15 ; Changed 9 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 in reply to:  16 ; Changed 9 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 in reply to:  16 Changed 9 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 in reply to:  17 Changed 9 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 Changed 9 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 in reply to:  20 Changed 9 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 9 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 9 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 9 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.

Note: See TracTickets for help on using tickets.