From: Homan, Charles (NE) (Charles.Homan@GDC4S.Com)
Date: Tue Jun 03 2003 - 16:57:27 EDT
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
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:26:31 EDT