topic Re: Help! Locked up X server in Operating System - HP-UX

Help! Locked up X server

Blake Garretson — Thu, 05 Oct 2000 16:11:49 GMT

I just locked up my workstation and I need it back. I was running a couple of the OpenGL demos found in /opt/graphics/OpenGL/demos/ when I was foolish enough to run "threads-64". It locked up my display and mouse, but I can still telnet/rlogin into it. I need to regain control of the station, WITHOUT rebooting it because I'm running a number crunching process that has been going for 17 hours and I'd hate to start it over.

How can I log myself off, or reset the X server, or something similar to regain control? I already killed the dtterm from which I ran the "threads-64". No luck.

The other processes that I'm considering killing are:
"dtwn"
"/usr/dt/bin/dtsession"
"/usr/dt/bin/ttsession -s"

Please help or advise! Thanks.

Re: Help! Locked up X server

Blake Garretson — Thu, 05 Oct 2000 16:22:12 GMT

I forgot to add that I already tried to kill the offending process with no success. I did a "ps -ef" then a:
kill 9491 9487
which did nothing so I tried a:
kill -9 9491 9487
which resulted in the process ID changing to "9491 1". I'm afraid to do a:
kill 9491 1
since process 1 is init!

Re: Help! Locked up X server

Alex Glennie — Thu, 05 Oct 2000 18:31:46 GMT

Try on the local keyboard to kill the Xserver or

/sbin/init 2 will also do the trick but may disrupt some services started at run level 3/4

or if using CDE : /sbin/init.d/dtlogin.rc [stop/start] may work or

ps -ef ? grep X : ..... kill -9 (-9 if required) X= Xserver

Re: Help! Locked up X server

Steve Sauve — Thu, 05 Oct 2000 18:48:00 GMT

When you kill the process just kill the PID, not the PPID (as in the 9xxx number not the 1). So it would look something like this:
kill -9 9431
Question for you though, if the number crunching is continuing could you just wait for it to finish?

Hope this helps,
Steve

Re: Help! Locked up X server

Blake Garretson — Thu, 05 Oct 2000 19:04:33 GMT

I could just wait, but that could be another 10 hours. I really needed to use my workstation for other things in the meantime. (I have a 2 CPU J-5600 so I can do other stuff on one cpu and not slow down the calculations on the other cpu.)

The CTRL-SHIFT-BREAK does nothing. I'm leary about doing a "dtlogin stop" or a kill on the X server process because I'm not sure what the screen will do. Will I be able to start it back up and login like normal? Please advise before I do something dangerous.

Thanks again...

Re: Help! Locked up X server

Alex Glennie — Thu, 05 Oct 2000 19:23:38 GMT

dtlogin.rc runs the CDE & Xserver, starts at run level 3 see : /sbin/rc3.d/S990dtlogin.rc

It will basically start X:0 then dtlogin which will wait till a users logs in , spawn a child dtlogin along with dtgreet,dthello and dtsession : ie the screens associated with login,copyright and then the users session.

killing dtlogin will stop everything related to the users session and any other users remotely logged on under the control of CDE (xterminals & Pc's etc), if you started your job via a dtterm or xterm and did not run the command in the background you could find it terminated.

My advise is to try and kill the OpenGl processes first, if you really need to get in then kill X or my suggestions, changing the run level being the last option in the list.

Re: Help! Locked up X server

Alex Glennie — Thu, 05 Oct 2000 19:26:56 GMT

and yes you should be able to start over as normal once you've run dtlogin.rc stop followed by dtlogin.rc start.... if all goes as planned.

Re: Help! Locked up X server

Mike Stroyan — Thu, 05 Oct 2000 19:36:39 GMT

The next target would be the ogld process. It is closely involved with OpenGL programs. The X server can continue to run when ogld is killed.
I am not very optimistic of getting the screen back without killing the X server if the threads-64 demo is unkillable.

If you started the computation from a dtterm on the X server then it may get a SIGHUP when you restart the X server. You just might be able to spare the process by adopting it with gdb and using 'handle sighup nopass' to prevent the process from seeing the signal.