Solved "Can't open display"

After running for about a week, attempts to open X applications on my work station all result in the same error:
Code:
 ** ericx@milicent ** ~ ** Tue Mar 03 20:44:44
$ xterm
No protocol specified
xterm: Xt error: Can't open display: :0.0
[Exit 1 ]
All existing, previously started X-apps continue to work fine.

At any X-app started remotely via ssh works fine.

However, if I open a new ssh session to yet another server and attempt to start an X-app, I get a similar error:
Code:
 ** ericx@fw ** ~ ** Wed Mar 04 09:29:58
$ xterm
Invalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyInvalid MIT-MAGIC-COOKIE-1 keyxterm: Xt error: Can't open display: localhost.foobar.not:10.0
[Exit 1 ]
/tmp/.X11-unix/X0 appears to be alive and well (it's there, but I don't know how to poke at it meaningfully).

According to sockstat I appear to be using about 50 streams off the X0 socket (which doesn't seem excessive? Is there a limit?):
Code:
 ** ericx@milicent ** ~ ** Wed Mar 04 09:35:36
$ netstat -x | grep X0 | wc -l
  54
This has happened before. It takes a week or two to reappear. Rebooting makes the problem go away. ~something~ is dieing; but I haven't been able to suss which.

~/.xsession-errors is ~choked~ with 2500 lines of spurious noise from KDE; so while I imagine the answer is buried in there, it may be no help until I replace KDE with something less vociferous (WindowMaker?).

I find this very weird and very disturbing.

I am running: 10.1-RELEASE-p5 (however, problem first appeared before using freebsd-update to bump up from 10.0-RELEASE-p[mumble]. Xorg was recompiled at the same time as the OS and is currently:
Code:
 ** ericx@milicent ** ~ ** Wed Mar 04 10:28:30
$ pkg info | grep xorg
linux-c6-xorg-libs-7.4_1  Xorg libraries (Linux CentOS 6.6)
xorg-7.7_1  X.Org complete distribution metaport
xorg-apps-7.7_2  X.org apps meta-port
xorg-cf-files-1.0.5_1  X.org cf files for use with imake builds
xorg-docs-1.7,1  X.org documentation files
xorg-drivers-7.7_2  X.org drivers meta-port
xorg-fonts-7.7  X.org fonts meta-port
xorg-fonts-100dpi-7.7  X.Org 100dpi bitmap fonts
xorg-fonts-75dpi-7.7  X.Org 75dpi bitmap fonts
xorg-fonts-cyrillic-7.7  X.Org Cyrillic bitmap fonts
xorg-fonts-miscbitmaps-7.7  X.Org miscellaneous bitmap fonts
xorg-fonts-truetype-7.7_1  X.Org TrueType fonts
xorg-fonts-type1-7.7  X.Org Type1 fonts
xorg-libraries-7.7_2  X.org libraries meta-port
xorg-macros-1.19.0  X.Org development aclocal macros
xorg-server-1.14.7_1,1  X.Org X server and related programs
Thank you for your time; but please note that the failure interval is measured in weeks; so I may not respond to suggestions quickly.
 
It's late, so this will [regrettably] be short. But it might help to open an xterm right after you start your X session, and issue (as root)
ps waux | grep xterm
then record the pid number(s). When (and if) the errors regarding "xterm MAGIC-COOKIE" start showing up. You can issue that same command again
( ps waux | grep xterm)
and see if any of the pids have disappeared. Sorry this is short. I have some other probable causes. But I'll have to expand on this tomorrow. I've got to go to bed.

Best wishes.

--Chris
 
I had a similar problem some time ago using KDE. Increasing shared memory seemed to fix my issue. I can't remember where I got this information from off hand, but these are the values I've been using:
Code:
kern.ipc.shmmni=1024
kern.ipc.shmseg=1024
kern.ipc.shmall=32768
 
OK Let's try that again. :)
I ran into this [similar] problem years ago, back in the xf[free]86 days. I couldn't remember how I cured it. But near as I can figure, you're running into a randomness issue, where "cookies" ([individual] sessions) are concerned. Additional research indicates this is a common issue, where KDE is concerned. Couple of things you could try that will at least isolate where the problem stems, if not cure it altogether.
1) Before starting X; rm ~/.Xauthority
2) Assuming you're connecting to the first display (0:0), in your shell, export the following:
export DISPLAY=:0.0
If it were me, in an effort to completely isolate the cause; I would try the first suggestion, and if it failed, try the second. Failing on either, I would do both.

That should cure it for you. :)

All the best.

--Chris
 
I had a similar problem some time ago using KDE. Increasing shared memory seemed to fix my issue. I can't remember where I got this information from off hand, but these are the values I've been using:
Code:
kern.ipc.shmmni=1024
kern.ipc.shmseg=1024
kern.ipc.shmall=32768

Sounds like a good idea; but it seems I'm already running those same amounts. I don't know whether the defaults for 10.1 were pushed up from 9.x; but I have made no adjustments as yet.

Code:
 ** ericx@milicent ** ~ ** Mon Mar 23 10:51:25
$ sysctl -a | grep kern.ipc.shm   
kern.ipc.shmmax: 67108864
kern.ipc.shmmin: 1
kern.ipc.shmmni: 1024
kern.ipc.shmseg: 1024
kern.ipc.shmall: 32768
kern.ipc.shm_use_phys: 0
kern.ipc.shm_allow_removed: 0
 
Hmm... The only thing I can think of off the top of my head is /tmp getting automatically cleaned, therefore possibly deleting sockets, or dbus connection errors.(which seem to be common when dbus is updated, however the behavior is present after reboot so...). I would probably just start grokking the logs myself at this point. Otherwise I'm really not sure what else to offer, sorry.
 
OK Let's try that again. :)
I ran into this [similar] problem years ago, back in the xf[free]86 days. I couldn't remember how I cured it. But near as I can figure, you're running into a randomness issue, where "cookies" ([individual] sessions) are concerned. Additional research indicates this is a common issue, where KDE is concerned. Couple of things you could try that will at least isolate where the problem stems, if not cure it altogether.
1) Before starting X; rm ~/.Xauthority
2) Assuming you're connecting to the first display (0:0), in your shell, export the following:
export DISPLAY=:0.0
If it were me, in an effort to completely isolate the cause; I would try the first suggestion, and if it failed, try the second. Failing on either, I would do both.
I think you've got me in the right direction.

$DISPLAY is not the issue; but xauth is clearly screwed up:
Code:
** ericx@milicent ** ~/etc ** Mon Mar 23 11:40:40
$ echo $XAUTHORITY
/tmp/kde-ericx/xauth-105-_0
** ericx@milicent ** ~/etc ** Mon Mar 23 11:42:13
$ l /tmp/kde-ericx/
total 64
drwx------  2 ericx  wheel  2 Mar 23 11:40 .
drwxrwxrwt  14 root  wheel  21 Mar 23 11:49 ..
Not clear what is responsible for creating the xauth info in /tmp/kde-ericx dir. Or why it disappears after a week or so.
 
I think it's solved.
Found in my logs:
Code:
Removing old temporary files:
  /tmp/qipc_sharedmemory_qtsingleapplicationbfd226eec8217264ad14f2874ef82cdad0689049411
  /tmp/ksocket-ericx/KSMserver__0
  /tmp/qtsingleapp-clemen-b61d-69-lockfile
  /tmp/qtsingleapplication-3576-69-lockfile
  /tmp/kde-ericx/xauth-105-_0

I've been using the periodic script 110.clean_tmps for decades (it was more important when /tmp was an md; less important now that it's tmpfs) periodic.conf has been:
Code:
# 110.clean-tmps
daily_clean_tmps_enable="YES"                           # Delete stuff daily
daily_clean_tmps_days="7"                               # If not accessed for
I've changed it to:
Code:
# 110.clean-tmps
daily_clean_tmps_enable="YES"                           # Delete stuff daily
#daily_clean_tmps_dirs="/tmp"                           # Delete under here
daily_clean_tmps_days="7"                               # If not accessed for
#daily_clean_tmps_ignore=".X*-lock .X11-unix .ICE-unix .font-unix .XIM-unix"
#daily_clean_tmps_ignore="$daily_clean_tmps_ignore quota.user quota.group .snap"
#daily_clean_tmps_ignore="$daily_clean_tmps_ignore .sujournal"
daily_clean_tmps_ignore="$daily_clean_tmps_ignore kde-*/* xauth-*"
                                                        # Don't delete these
daily_clean_tmps_verbose="YES"                          # Mention files deleted
 
OK Let's try that again. :)
I ran into this [similar] problem years ago, back in the xf[free]86 days. I couldn't remember how I cured it. But near as I can figure, you're running into a randomness issue, where "cookies" ([individual] sessions) are concerned. Additional research indicates this is a common issue, where KDE is concerned. Couple of things you could try that will at least isolate where the problem stems, if not cure it altogether.
1) Before starting X; rm ~/.Xauthority
2) Assuming you're connecting to the first display (0:0), in your shell, export the following:
export DISPLAY=:0.0
If it were me, in an effort to completely isolate the cause; I would try the first suggestion, and if it failed, try the second. Failing on either, I would do both.

That should cure it for you. :)

All the best.

--Chris

Before starting X;

How is this to be made permanent?

Thanks
 
Back
Top