Thanks to Henrik Mortensen, Darren Dunham, and Klaus Heinz. Darren and Klaus both gently pointed out that how to change the max number of X11 clients is in the FAQ. (Well, I had looked there but not after Henrik clued me in to the X11 client issue - my bad!) For Solaris 7 you need patch 108376 at a minimum rev of -11, which we do. I have added the "-clients 1024" option as suggested in the FAQ, and that seems to take care of the issue - or at least defer it until a truly *ridiculous* number of windows is spawned. Thanks, guys! Charles > -----Original Message----- > From: Homan, Charles (NE) > Sent: Tuesday, June 03, 2003 4:57 PM > To: 'sunmanagers@sunmanagers.org' > Subject: UPDATE: Command line vs. CDE resource utilization difference > for dtterm? > > > Thanks to the lightning reply from Henrik Mortensen! He writes: > > > he runs out of X11 clients, which to my knowledge > > cannot be changed. Every dtterm "click-started" > > is owned by a dtexec which is also an X11 client. > > Not sure what they do; you seem to be able to whack > > them without affecting the spawned dtterm. > > Anyone know if it is possible to change the number of X11 > clients in Solaris > 7 (CDE)? Does anyone know what the dtexecs do after spawning > the dtterms? > I can in fact kill them with no obvious harm to my dtterm, > but I'm leery of > doing that on a regular basis - particularly since I had to > "kill -9" the > one I tried to get it to die. > > Thanks again, > Charles > > > -----Original Message----- > > From: Homan, Charles (NE) > > Sent: Tuesday, June 03, 2003 4:09 PM > > To: 'sunmanagers@sunmanagers.org' > > Subject: Command line vs. CDE resource utilization difference for > > dtterm? > > > > > > Fellow managers: > > > > I have a weird one for you. One of our engineers has noticed > > that when he > > starts a bunch of dtterms on the command line by running > > "dtterm&" over and > > over he eventually gets a warning dialog saying "unable to > > get pty". Fair > > enough - that's what we would expect. > > > > However, when he does the same thing via the CDE GUI > > (clicking on "This > > Host" in the CDE task bar instead of typing "dtterm") he does > > not get the > > same error dialog (or any error in any log I have found) and he gets > > significantly fewer dtterms. They just stop appearing: the > > cursor goes to > > the wait state and the globe above the exit button spins, but > > no window > > appears. In my testing, I was able to bring up 19 dtterms > > (on a semi-loaded > > system) using the command line method but only 11 using the > > GUI method. > > > > The question is: why the difference? I would have thought > > that the result > > would be the same in both cases. Certainly the windows seem > > exactly the > > same, and the process looks to be the same. The engineer > > also noticed that > > certain of the inter-process communication routines he wrote > > still work when > > he runs out of ptys using the command line method, but fail > > when he can no > > longer bring up more dtterms using the GUI. This would tend > > to indicate > > that the GUI method is hogging some resource other than ptys, > > but I haven't > > been able to figure out what. Memory and swap remain high, > > and I should > > still have 8 ptys free (based on the command line test, which > > I have run > > back-to-back-to-back with the GUI test to verify that the > > numbers remain > > consistent.) What else could it be? > > > > I have tried "truss -fp" on the ttsession process in an > > attempt to debug > > this. This is the beginning of the truss when clicking on > > the "This Host" > > button and getting a dtterm: > > > > 10401: poll(0xFFBEC0D8, 74, -1) = 1 > > 10401: getmsg(257, 0xFFBEDC24, 0xFFBEDC14, 0xFFBEDC54) = 0 > > 10401: write(9, " s", 1) = 1 > > 10401: poll(0xFFBEE0D0, 0, 0) = 0 > > 10401: poll(0xFFBEC0D8, 74, -1) = 1 > > 10401: getmsg(257, 0xFFBEDC24, 0xFFBEDC14, 0xFFBEDC54) = 0 > > 10401: write(257, "80\0\0E4 >B0 Q\b\0\0\001".., 232) = 232 > > 10401: poll(0xFFBEE0D0, 0, 0) = 0 > > 10401: poll(0xFFBEC0D8, 74, -1) = 1 > > 10401: ioctl(5, I_PEEK, 0xFFBEDE44) = 1 > > 10401: getmsg(5, 0xFFBEDEB0, 0xFFBEDEA0, 0xFFBEDEDC) = 0 > > 10401: open("/dev/tcp", O_RDWR) = 46 > > 10401: fstat64(46, 0xFFBEDC90) = 0 > > 10401: stat64("/dev/pts/55937", 0xFFBEDBF8) Err#2 ENOENT > > 10401: ioctl(46, I_FIND, "timod") = 0 > > 10401: ioctl(46, I_PUSH, "timod") = 0 > > 10401: ioctl(46, I_STR, 0xFFBEDC70) = 0 > > 10401: ioctl(46, I_STR, 0xFFBEDC70) = 0 > > 10401: ioctl(46, I_FLUSH, FLUSHRW) = 0 > > 10401: fcntl(46, F_DUPFD, 0x00000100) = 291 > > 10401: close(46) = 0 > > 10401: ioctl(291, I_FIND, "timod") = 1 > > 10401: ioctl(291, I_STR, 0xFFBEDC10) = 0 > > .... > > > > and this is everything printed out after a click of the "This > > Host" button > > which fails to bring up a dtterm: > > > > 10401: poll(0xFFBEC0D8, 78, -1) = 1 > > 10401: getmsg(257, 0xFFBEDC24, 0xFFBEDC14, 0xFFBEDC54) = 0 > > 10401: write(9, " s", 1) = 1 > > 10401: poll(0xFFBEE0D0, 0, 0) = 0 > > 10401: poll(0xFFBEC0D8, 78, -1) = 1 > > 10401: getmsg(257, 0xFFBEDC24, 0xFFBEDC14, 0xFFBEDC54) = 0 > > 10401: write(257, "80\0\0E4 >B0 PFE\0\0\001".., 232) = 232 > > 10401: poll(0xFFBEE0D0, 0, 0) = 0 > > 10401: poll(0xFFBEC0D8, 78, -1) (sleeping...) > > 10401: signotifywait() (sleeping...) > > 10401: lwp_sema_wait(0xFE30DE78) (sleeping...) > > 10401: lwp_cond_wait(0xFF2E3F08, 0xFF2E3F18, 0xFEFB3C90) > > (sleeping...) > > > > I can see that where the one that works follows a "poll" with > > an "ioctl" the > > other is following with "signotifywait", but I'm not sure > > what to make of > > that. > > > > > > The systems are Ultra 2s and 10s running Solaris 7. > > > > Any troubleshooting advice on this would be welcome. > > > > Thanks, > > Charles > > > > ObDisclaimer: My views are mine and not those of my employers. > > _______________________________________________ > > sunmanagers mailing list > > sunmanagers@sunmanagers.org > > http://www.sunmanagers.org/mailman/listinfo/sunmanagers > _______________________________________________ > sunmanagers mailing list > sunmanagers@sunmanagers.org > http://www.sunmanagers.org/mailman/listinfo/sunmanagers _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Wed Jun 4 09:42:30 2003
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:11 EST