[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:STAR::VATNE
Created:Mon Oct 30 1989
Last Modified:Mon Dec 31 1990
Last Successful Update:Fri Jun 06 1997
Number of topics:3726
Total number of notes:19516

1882.0. "losing menu bar on all dxterms" by EMASS::FLETCHER (Robin G. Fletcher, SWS -> WAO) Mon Dec 11 1989 08:15

    A customer is using a DS2100 (served off of a DS3100) with 8Mb of
    memory.  A particular user is running multiple applications on multiple
    windows.  While using DXMAIL (sending a message), all of a sudden each
    of the windows he had lose their menu bars and he can not focus input
    on any of these dxterms.  He has lost communication with them. 
    However, he is able to goto the session manager and create a new
    window.  When he tries to kill -9 each of these comatose dxterms, they
    will not die!  An attempt at rebooting yields troubles because the
    system can not kill those comatose processes...hanging system.  A hard
    reset and reboot is the only workable solution at this time.
    
    What is happening behind the scenes here?
    How can the processes be killed?
    Why is contact lost with all open dxterms?
    
    It seems as all X clients have trouble while the X server is fine.???
    
    Robin
T.RTitleUserPersonal
Name
DateLines
1882.1Window manager crash?HANNAH::MESSENGERBob MessengerMon Dec 11 1989 10:4510
Re: .0

Is it really the menu bars that are lost, or the title bars?  It sounds
like the window manager crashed for some reason, but in that case it's the
title bars that would disappear.

The kill -9 dxterm commands probably failed because dxterm is setuid'ed to
the root, so you'll have to su before killing them.

				-- Bob
1882.2try restarting the window managerSMURF::HOFFMANanywhere in the universeTue Dec 12 1989 22:2853
As Bob stated in .1, your window manager seems to have crashed.
The first thing to do, if you simply want to get going again,
is to restart the window manager via the command  "dxwm".
If you cannot get input focus on your dxterm windows,
here are 2 ways to do it anyway:
	1.  log in over your network to the system, make sure that
		your log in session has (or gets) the display variable
		set to your workstation (typically, for a csh user,
		use the command   "setenv DISPLAY hostname:0" where
		hostname is the name of your workstation),
		then run the dxwm command.
	2.  cut and paste the letters "dxwm" into a dxterm window 
		that is logged in on your worksystem.  This will work
		even when you can't get focus on a dxterm window (or
		an xterm window, for that matter) via clicking your
		mouse button or whatever it is that your favorite
		window manager does to let you control the screen.
		Use a Help file from one of the dxterms to obtain a
		source of letters you can cut if you can't find any
		in the dxterms themselves.  

		This all sounds like weird
		science, but I used this method recently to survive 2 days of
		showing UWS software (in front of many people at
		a very big trade show) with the Motif window manager
		when the window manager would crash often.  I was not
		about to restart the system every time some little
		problem like that came up!!

Bob is also correct regarding dxterms.  Just because you started them
as a normal user does not mean that you can kill them from the command line.
Look at their permissions:  "ls -l /usr/bin/dxterm" -- you'll see 
something like 
	-rwsr-sr-x  5  root    1973248  Oct 22 20:02 /usr/bin/dxterm
The key is the "s" in the "rws" portion of the permissions.  This means
setuid, which dxterm needs in order to grab the tty that it uses.
In other words, for this particular purpose, dxterm is given root
(superuser) privileges even when started by a mere mortal.

Crashes of the window manager, incidentally, occur in most cases as a result of
insufficient swap space when running "vanilla" DECwindows.  Ask your
customer to run the command "/etc/pstat -s" when the normal load
of windows & applications is running, and see if the value just
before "free" (given in kilobytes) is less than around 2000.
If it is, especially on a DS2100, then they're on the ragged edge.
The solution is to run more of the applications from some other system
or to obtain more swap space.

Hope all this was helpful, or at least entertaining.

John Hoffman
UWS V4.0 Project Leader