I'm hitting a problem whereby X prevents processes from creating windows, uttering something like the following into ~/.xsession-errors
:
cannot open display: :0.0
Maximum number of clients reached
Searching around there are lots of examples of people facing this problem, and sometimes people identify which program they are running is using up all the client slots. See e.g. LP 70872 (Firefox), LP 263211 (gnome-screensaver).
For what it's worth, I run gnome-terminal, thunderbird, chromium-browser, empathy, tomboy and virtualbox nearly all the time, on top of the normal stuff you get with the GNOME desktop, and occasionally some other bits and pieces.
However my question is not "which of my programs is causing this problem" but rather, how can one go about diagnosing this problem?
In the above (and other) bugs, forum reports, etc., a number of tools are suggested:
xlsclients
- lists the client applications for the given display, but I don't think that corresponds to 'X clients'xrestop
- a top-style X resources tool, one row per X client. Lots of '' clients, not shown inxlsclients
outputxwininfo -root -children
lists X window objects
From what I can gather, the problem might not be too many clients at all, but rather resources kept around in the X server for clients who have long-since detached. But it would also appear that you cannot (easily?) relate X resources back to their client. Can one effectively diagnose this issue once it has started to occur, or is a tedious divide-and-conquer approach for the apps I run the only approach open to me?
Update Jan 2011: I think I have resolved this issue. For the benefit of anyone stumbling across this, nautilus and/or compiz or something in that chain of software was segfaulting due to a wallpaper I had. I had chosen an XML file as my wallpaper, which defined a rotating gallery of images. It was hand-made, but based on /usr/share/backgrounds/contest/background-1.xml or similar. Disabling the wallpaper and I have not had a crash since.
I'm not marking this as answered yet, since the actual specific problem was not my question, but how to diagnose it was. Unfortunately this was mostly trial-and-error which sucks.
I managed to resolve this "deadlock", where none of the x-tools worked since they too need to connect to the X server, by using
lsof -U
which lists the processes that are using socket files.In this example it was a bad startup script that spawned new "badproc" processes out of bounds.
Example output from
lsof -U
:I have the same question, because I think this issue is significant for anyone who does not reboot their computer often. One thing I've really liked about UNIX/Linux/Ubuntu over the years is that I can reliably run my laptop for months without rebooting (suspending only), except when I install a new kernel. Since upgrading to the "suite" that is Maverick (Ubuntu 10.10), I've encountered this and can only run for a week.
I've tried 'xrestop', too; stopped the compiz window effects (that slowed down the resource leak), but still cannot find out why this is happening. It's almost like being back on a WinXP machine... :-(
So yes! Better X debugging tools would be good. One problem with 'xrestop' is that it requires resources, too, so once you hit the wall, even it won't run.
As a tip to others who get stuck by this (eg: when resuming from Standby and waiting for the password window that will never appear because there are no resources to create it), switching to a frame buffer terminal and back (Ctrl-Alt-F1, then Ctrl-Alt-F7) seems to free a few of the critical resources.
Doug
Here are some experiences from debugging this problem on Ubuntu 16.04.
Indeed
xlsclients
appears to report incorrect numbers: even when the debugger shows that Xorg hits the MaxClients limit (eg. 256),xlsclients | wc -l
reports a much lower number (eg. 164 clients). I'm not sure which clients are left out byxlsclients
, but its output is not useful for detecting the cause of "Maximum number of clients reached" errors.lsof -U
also appears give incomplete results: it only reports some of the client connections, but not all. It only reports the connections that use the abstract@/tmp/.X11-unix/X0
socket file; but there are lots more connections (displayed as typesock
with description "protocol: UNIX") which don't show up inlsof -U
. I haven't found anylsof
flag that limits display to these sockets; but at least they are displayed if you list all open files for a process.So this command appears to give a pretty good count of client connections:
lsof -p $(pgrep Xorg) | grep -E 'X11-unix|(protocol: UNIX)' | wc -l
Only partially related: it looks like latest Firefox (72) will for each new instance open 2 connections that show up as
@/tmp/.X11-unix/X0
, and 6 additional ones that will show up asprotocol: UNIX
. And every new tab will open 2 more sockets of theprotocol: UNIX
type. So with many Firefox instances and tabs you can reach the 256 MaxClients limit pretty reliably.Chromium/Chrome has some known issues which result in this error message. Do you use the Lastpass extension?
ref: http://www.ngohaibac.com/how-to-solve-maximum-number-of-clients-reached-gtk-warning-cannot-open-display-in-ubuntu-9-10-64-bit/
lsof -U
show a huge number of xcape instances.kill xcape
solve the problem.Now I can use rofi and tor-browser again.
I make:
lsof -U
and I observe a lot of vlc instances.For resolve my problem I execute:
Was facing the same issue with openoffice,its because of memory(RAM) ,
Try shutting all the terminals (including apps), If that didnt work Try
sudo reboot now