campbell@redsox.bsw.com (Larry Campbell) (02/16/90)
(System: 386/ix running ISC X11R3 V1.1 on vanilla VGA) Inevitably, after using X for a while,I lose the ability to open new connections to my server. When I try to start a new application, I get, for example: /usr2/campbell> xrdb -query xrdb: No such device or address xrdb: Can't open display 'unix:0' /usr2/campbell> I suspect I'm running out of some resource, because if I reboot my system I can successfully start all the applications I was originally trying and failing to. I have checked streams resources with /etc/crash -- I've never run out of any stream buffers. Here's the strstat output: ITEM CONFIG ALLOC 425788 90 0 data block size 4 128 0 128 169046 5 0 data block size 16 256 26 230 32667 32 0 data block size 64 256 0 256 144056 51 0 data block size 128 128 0 128 47583 62 0 data block size 256 64 0 64 16875 15 0 data block size 512 32 0 32 8806 10 0 data block size 1024 32 0 32 2684 4 0 data block size 2048 32 0 32 3978 7 0 data block size 4096 4 0 4 93 3 0 Count of scheduled queues: 0 I'm not using very many ptys -- three or four typically, and I'm configured for 16. I have 10MB of memory and have configured the kernel appropriately. I'm the only user. No console messages are appearing. How can I figure out what I'm short of so I can bump it up? -- Larry Campbell The Boston Software Works, Inc. campbell@redsox.bsw.com 120 Fulton Street wjh12!redsox!campbell Boston, MA 02109
elaine@uc.msc.umn.edu (Elaine Larson) (02/20/90)
>Inevitably, after using X for a while,I lose the ability to open new >connections to my server. When I try to start a new application, I get, for >example: > /usr2/campbell> xrdb -query > xrdb: No such device or address > xrdb: Can't open display 'unix:0' > /usr2/campbell> This sounds just like the problem we were having with our SparcStations. It turned out that our problem was caused by having our diskless SparcStations configured so that they all shared the same /tmp. We eventually discovered (it took a while!) that X11 creates the file /tmp/.X11-unix/X0 (the 0 is for the screen number) on server start-up when using unix sockets. When someone started up their server, things worked just fine. But because we were sharing /tmp between workstations, when someone else started up a server on another workstation, the first person would no longer be able to open new connections as his or her /tmp/.X11-unix/X0 file had been over written. Check out server/os/4.2bsd/connection.c. This comment is located in that file: #ifdef UNIXCONN /* * sites should be careful to have separate /tmp directories for diskless nodes */ We ended up making separate /tmp space for each workstation, and that solved the problem. I'm not sure that this is the same problem you're having, but it sure sounds similar. - Elaine Larson Minnesota Supercomputer Center elaine@msc.umn.edu
mike@antel.uucp (Michael Borza) (02/21/90)
In article <1537@redsox.bsw.com> campbell@redsox.bsw.com (Larry Campbell) writes: >(System: 386/ix running ISC X11R3 V1.1 on vanilla VGA) > >Inevitably, after using X for a while,I lose the ability to open new >connections to my server. When I try to start a new application, I get, for >example: > > /usr2/campbell> xrdb -query > xrdb: No such device or address > xrdb: Can't open display 'unix:0' > /usr2/campbell> > >I suspect I'm running out of some resource, because if I reboot my system >I can successfully start all the applications I was originally trying and >failing to. > >I have checked streams resources with /etc/crash -- I've never run out >of any stream buffers. Here's the strstat output: Nonetheless, streams is what you're running out of. There is a bug in the ISC X-Server Xvga which eats one stream each time the server dies. (Actually, I can't say with authority that the problem is with Xvga, but it manifests itself when the Xvga server dies.) A simple experiment will suffice to convince yourself that this is the case: run `netstat -imn' and node the number of streams `inuse'; then by hand with xinit, or with xdm, start Xvga, then kill it; re-run `netstat -imn'. The number of streams `inuse' should increase by one each time you start a new server. I know that this is the case with Xvga from the ISC X Runtime 1.0.0 release. I can't comment on any other server as I've never run them (except Xhrc too briefly to observe this problem). This cost us a substantial amount of effort to isolate here. I've never run crash to try to isolate this. It's now been a long time since we encountered this-- we bumped NSTREAM in mtune, and now take our systems down every two weeks or so to avoid it. At any rate, from what I recall about this problem from when we did isolate it, you won't actually be out of stream buffers, there just won't be enough to start the server. (We figured it out by looking at the difference between inuse streams with and without the X-Server running.) Could it be that the server looks for the number of streams it needs prior to trying to allocate them, then fails if it wouldn't get them? Anyone at ISC care to comment on this layman's guess at what's going on here? mike borza. -- Michael Borza Antel Optronics Inc. (416)335-5507 3325B Mainway, Burlington, Ont., Canada L7M 1A6 work: mike@antel.UUCP or uunet!utai!utgpu!maccs!antel!mike home: mike@boopsy.UUCP or uunet!utai!utgpu!maccs!boopsy!mike
guy@auspex.auspex.com (Guy Harris) (02/24/90)
>>I have checked streams resources with /etc/crash -- I've never run out >>of any stream buffers. Here's the strstat output: > >Nonetheless, streams is what you're running out of. Which is consistent with his statement; "streams" and "streams buffers" are different beasts.
mike@antel.uucp (Michael Borza) (03/06/90)
In article <2963@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: > > >>I have checked streams resources with /etc/crash -- I've never run out > >>of any stream buffers. Here's the strstat output: > > > >Nonetheless, streams is what you're running out of. > >Which is consistent with his statement; "streams" and "streams buffers" >are different beasts. Astute, as usual, Guy. Nonetheless:-), I believe my own observations of, and workaround for, a problem with similar or identical symptoms was relevant to the issue at hand, even if hasty in my formulation of a reply. I've not heard back from the original poster, so I don't know whether this is in fact his problem. I have, however, heard from ISC that they do not observe the behaviour I reported. I've since reproduced the reported behaviour at my site under both 1.0.6 and 2.0.2, each running the 1.0.0 release of the VGA X-Server. The interested party at ISC should by now have a complete description of my software configuration and a short procedure to reproduce the problem. If I hear anything else, I'll report back here (names removed to protect the innocent). mike borza. -- Michael Borza Antel Optronics Inc. (416)335-5507 3325B Mainway, Burlington, Ont., Canada L7M 1A6 work: mike@antel.UUCP or uunet!utai!utgpu!maccs!antel!mike home: mike@boopsy.UUCP or uunet!utai!utgpu!maccs!boopsy!mike