phenix gui freezes
Dear All A little while ago I posted a message about the GUI freezing on linux systems, either run remotely (centos) or locally (ubuntu system). I never received a solution and I'm still having this problem despite upgrading to version 1.6. On my ubuntu system the GUI seems to freeze either when the screen saver comes on (set to turn the screen off) or I switch desktop - although not everytime I do this. The freezing GUI means that I have to force quit phenix after every refinement run (I haven't tried other tasks) and that the freeR is not reported to the GUI (not a major problem). Thankfully in version 1.6 the configuration and results for each refinement run are recorded and I can retrieve this information by loading a job through job history - a big improvement over version 1.5. Anyone else having this problem and does anyone know a solution? Thanks John -- John Berrisford Medical Research Council Mitochondrial Biology Unit Wellcome Trust / MRC Building Hills Road Cambridge CB2 0XY WEB: www.mrc-mbu.cam.ac.uk TEL: +44 (01223) 252918
On Mar 11, 2010, at 7:28 AM, John Berrisford wrote:
A little while ago I posted a message about the GUI freezing on linux systems, either run remotely (centos) or locally (ubuntu system). I never received a solution and I'm still having this problem despite upgrading to version 1.6.
On my ubuntu system the GUI seems to freeze either when the screen saver comes on (set to turn the screen off) or I switch desktop - although not everytime I do this. The freezing GUI means that I have to force quit phenix after every refinement run (I haven't tried other tasks) and that the freeR is not reported to the GUI (not a major problem). Thankfully in version 1.6 the configuration and results for each refinement run are recorded and I can retrieve this information by loading a job through job history - a big improvement over version 1.5.
Anyone else having this problem and does anyone know a solution?
I'm basically out of ideas right now. One of my colleagues (Rob Oeffner) demonstrated the same problem (after running a long job and - I think - sleeping the computer) on a virtual machine-based Linux installation yesterday, and I was able to confirm that the program itself is freezing and it isn't just a display problem. I'll try running some more tests when I get back to Berkeley, but even if I can reproduce it (dubious), I'm not sure how to track down the problem. I have already tested the reaction to the screen saver and desktop switching (also on Ubuntu) and couldn't reproduce that. There appear to be a variety of bizarre and unpredictable interactions with the display software and libraries on Linux, and possibly with the graphics drivers as well. Have you (or anyone else) noticed similar problems with other programs? The only suggestion I can think of offhand is to run the GUI with the argument "--debug", which will direct bug reports to the console instead of popping up a window. Let me know if this produces anything informative, but I'm not holding my breath. The good news is that I now have detached processes mostly working for the big programs, which means that the GUI can be closed or killed or crashed and the running job won't even notice. It should still preserve and report the same information. We are still trying to make an installer good enough to release version 1.6.1, but in your case I'd recommend just downloading the latest nightly build now and switching to that (it will probably be an improvement over 1.6 anyway). The Run button should now display a menu instead of immediately starting the job, and from there you can decide how to run the process. Nat -------------------- Nathaniel Echols Lawrence Berkeley Lab 510-486-5136 [email protected]
Hello John,
I have seen exactly this problem after running phenix.validate . Not only
does the GUI freeze , but it seems to take the windowing system down with
it. The window manager gets unresponsive. Remote shelling into the system
was possible , but there was no active python process that I could kill to
get control back. In the end I had to restart-X to log back in loosing what
I was doing in other windows.
I have seen this at-least 2 or 3 times on two 64 bit ubuntu hardy running
machines with phenix 1.6.289. Both boxes have 4 to 8 cores and 8 to 16 GB of
ram.
On mac OSX running 10.6.2 , on a core duo , so probably everything is
running in 32 bit mode . Things are relatively very stable. Other than a few
times where phenix said it was launching coot and just sat there, I have
been using it without incident, so much so I have switched to using my slow
laptop because of something I thought was wrong at my end.
Looking forward to troubleshooting instructions . Thanks
Hari
On Thu, Mar 11, 2010 at 7:28 AM, John Berrisford
Dear All
A little while ago I posted a message about the GUI freezing on linux systems, either run remotely (centos) or locally (ubuntu system). I never received a solution and I'm still having this problem despite upgrading to version 1.6.
On my ubuntu system the GUI seems to freeze either when the screen saver comes on (set to turn the screen off) or I switch desktop - although not everytime I do this. The freezing GUI means that I have to force quit phenix after every refinement run (I haven't tried other tasks) and that the freeR is not reported to the GUI (not a major problem). Thankfully in version 1.6 the configuration and results for each refinement run are recorded and I can retrieve this information by loading a job through job history - a big improvement over version 1.5.
Anyone else having this problem and does anyone know a solution?
Thanks
John
-- John Berrisford
Medical Research Council Mitochondrial Biology Unit Wellcome Trust / MRC Building Hills Road Cambridge CB2 0XY WEB: www.mrc-mbu.cam.ac.uk TEL: +44 (01223) 252918
_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb
Hi,
Same problem here with Ubuntu 8.04 and Ubuntu 9.10
Not sure whether it is linked to anything, but leaving the GUI open
while a job is running, usually means I have to kill and restart the
GUI because it is frozen. I only run the GUI locally.
I have not been able to work out why this happens. It only affects
Phenix, and it does not cause anything else to crash at the same time.
Johan
Dr. Johan P. Turkenburg X-ray facilities manager
York Structural Biology Laboratory
University of York Phone (+) 44 1904 328251
York YO10 5DD UK Fax (+) 44 1904 328266
On 11 March 2010 12:28, John Berrisford
Dear All
A little while ago I posted a message about the GUI freezing on linux systems, either run remotely (centos) or locally (ubuntu system). I never received a solution and I'm still having this problem despite upgrading to version 1.6.
On my ubuntu system the GUI seems to freeze either when the screen saver comes on (set to turn the screen off) or I switch desktop - although not everytime I do this. The freezing GUI means that I have to force quit phenix after every refinement run (I haven't tried other tasks) and that the freeR is not reported to the GUI (not a major problem). Thankfully in version 1.6 the configuration and results for each refinement run are recorded and I can retrieve this information by loading a job through job history - a big improvement over version 1.5.
Anyone else having this problem and does anyone know a solution?
Thanks
John
-- John Berrisford
Medical Research Council Mitochondrial Biology Unit Wellcome Trust / MRC Building Hills Road Cambridge CB2 0XY WEB: www.mrc-mbu.cam.ac.uk TEL: +44 (01223) 252918
_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb
I have one other thought - the GUI listens on a socket for incoming commands from Coot (this isn't used very much at present). Apparently this caused problems on Linux with the old GUI, which also used Python sockets. If something goes wrong here, it could certainly take down the entire program. To fix this, edit the file $PHENIX/phenix/wxGUI2/App.py, and comment out this line (in 1.6): self.start_xmlrpc_server() (if you're new to python, a comment starts with '#'.) I will add a preferences setting to do this. I can also try slowing down the GUI updates while a process is running (using detached processes should also take care of this). On Mar 11, 2010, at 7:28 AM, John Berrisford wrote:
Dear All
A little while ago I posted a message about the GUI freezing on linux systems, either run remotely (centos) or locally (ubuntu system). I never received a solution and I'm still having this problem despite upgrading to version 1.6.
On my ubuntu system the GUI seems to freeze either when the screen saver comes on (set to turn the screen off) or I switch desktop - although not everytime I do this. The freezing GUI means that I have to force quit phenix after every refinement run (I haven't tried other tasks) and that the freeR is not reported to the GUI (not a major problem). Thankfully in version 1.6 the configuration and results for each refinement run are recorded and I can retrieve this information by loading a job through job history - a big improvement over version 1.5.
Anyone else having this problem and does anyone know a solution?
Thanks
John
-- John Berrisford
Medical Research Council Mitochondrial Biology Unit Wellcome Trust / MRC Building Hills Road Cambridge CB2 0XY WEB: www.mrc-mbu.cam.ac.uk TEL: +44 (01223) 252918
_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb
-------------------- Nathaniel Echols Lawrence Berkeley Lab 510-486-5136 [email protected]
Hello Nat,
I am assuming that commenting the
self.start_xmlrpc_server()
Will sever the connection with coot right. So is the option then for a
phenix.validate talking to coot session for molprobity assisted rebuilding
to have phenix write out the external gui ..and then just close or kill the
phenix session?
Hari
On Thu, Mar 11, 2010 at 9:48 AM, Nathaniel Echols
I have one other thought - the GUI listens on a socket for incoming commands from Coot (this isn't used very much at present). Apparently this caused problems on Linux with the old GUI, which also used Python sockets. If something goes wrong here, it could certainly take down the entire program.
To fix this, edit the file $PHENIX/phenix/wxGUI2/App.py, and comment out this line (in 1.6):
self.start_xmlrpc_server()
(if you're new to python, a comment starts with '#'.)
I will add a preferences setting to do this. I can also try slowing down the GUI updates while a process is running (using detached processes should also take care of this).
On Mar 11, 2010, at 7:28 AM, John Berrisford wrote:
Dear All
A little while ago I posted a message about the GUI freezing on linux systems, either run remotely (centos) or locally (ubuntu system). I never received a solution and I'm still having this problem despite upgrading to version 1.6.
On my ubuntu system the GUI seems to freeze either when the screen saver comes on (set to turn the screen off) or I switch desktop - although not everytime I do this. The freezing GUI means that I have to force quit phenix after every refinement run (I haven't tried other tasks) and that the freeR is not reported to the GUI (not a major problem). Thankfully in version 1.6 the configuration and results for each refinement run are recorded and I can retrieve this information by loading a job through job history - a big improvement over version 1.5.
Anyone else having this problem and does anyone know a solution?
Thanks
John
-- John Berrisford
Medical Research Council Mitochondrial Biology Unit Wellcome Trust / MRC Building Hills Road Cambridge CB2 0XY WEB: www.mrc-mbu.cam.ac.uk TEL: +44 (01223) 252918
_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb
-------------------- Nathaniel Echols Lawrence Berkeley Lab 510-486-5136 [email protected]
_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb
On Thu, Mar 11, 2010 at 3:59 PM, hari jayaram
Hello Nat,
I am assuming that commenting the
self.start_xmlrpc_server()
Will sever the connection with coot right. So is the option then for a phenix.validate talking to coot session for molprobity assisted rebuilding to have phenix write out the external gui ..and then just close or kill the phenix session?
Oh dear, I forgot about this. Sorry, you need to use the latest nightly build for this - commenting out that line should not affect communication with Coot in the current code (but it will in 1.6). I thought of an unrelated "feature" that may also lead to problems; the next available installer will have the fix, although I'm not sure if it will actually fix anything. -Nat
participants (5)
-
hari jayaram -
Johan Turkenburg -
John Berrisford -
Nathaniel Echols -
Nathaniel Echols