OpenOffice insert graphics, print and sometimes save=frozen client

Jim Kronebusch jim at
Mon Sep 17 04:19:03 UTC 2007

On Sun, 16 Sep 2007 23:38:54 -0400, Todd O'Bryan wrote
> But that doesn't explain the hard freezes a few of us reported when
> students pasted several images into Impress even without printing.

I think that is a different issue than what I am seeing.  I did notice that when I tried
playing several graphic or audio intense PowerPoints in Impress I froze the clients. 
But I assumed that was a conversion problem.  I don't think our students get heavy into
PowerPoints until after Christmas break (after the 1st of the year), so I have time to
work out bugs there.  Have you tried monitoring RAM and CPU usage on both the client and
the server while this happens?

If not try a few of these things.  First on the server copy your apt sources from the
server into the client root with "sudo cp /etc/apt/sources.list
/opt/ltsp/i386/etc/apt/sources.list" then "sudo chroot /opt/ltsp/i386" to work in the
client directory.  Then "sudo apt-get update" and then "sudo apt-get install htop" for
monitoring processes on the client and then "sudo adduser support" and then "sudo
visudo" and at the bottom of the file add in "support    ALL=(ALL) ALL" (change the
support user to whatever you want to call it).  This will allow you to log into the
Screen1 on the client and monitor client usage and give that user sudo privileges if
needed.  Now reboot your client and log into screen1 with ctrl+alt+f1.  Then run "free"
and see what a baseline of memory usage is, then run htop as well and see your baseline.
 Then on the server install xrestop and htop with "sudo apt-get install xrestop htop". 
This will allow you to monitor X memory usage on the client and give you a better tool
to monitor resource usage on the server.  Now you are set up to test.

Log into your client and run xrestop in a terminal, you can see a baseline of what
resources X is using just when logged in.  Now be prepared to spend some time freezing
your client while seeing what is going on.  Set up a test Impress document that will be
sure to freeze your client, and start running it.  Do this with a combination of
watching xrestop while running, see the last thing xrestop recorded before freeze (may
take some playing around to be able to see this while Impress is running, may even need
a script to record the output to a file).  When it freezes reboot and test again.  This
time log into screen1 and then crtl+atl+f7 to return to your graphical session.  Now log
in and run the Impress file again, quickly switch back to screen 1 and keep running
"free" over and over until the client freezes, note the changes.  Then repeat but use
htop this time and note the changes.  Every time keep htop running on the server and see
how the server responds.

If nothing else, the results of all this will tell you what isn't happening, which is
also handy.  But it may also show a spike in some type of usage which will give a clue
where to start.  When finished post your results.

Also if you haven't already installed Matt Oquist's xterminator, you will have to
manually kill all user processes after the freeze or you'll have trouble when you try
and log in again.  I recommend anyone else having freeze problems in any application
trying these steps and post the results along with detailed information on your setup. 
This seems to be a good start to finding where the problem may lie in relation to client

If someone has a good method to track network activity along with this please post.  As
as a way to see a spike or a flat line in network activity might be helpful as well. (I
know I've seen this posted before)

Scott Balnaeves, Jim McQuillan and Oliver Grawert (I'm sure there are others sorry to
leave you out) are pretty busy, and the more information we can collect on our own
before submitting issues to them will help them better tackle them.

If you could get this figured out before I run into it that would be great :-)


This message has been scanned for viruses and
dangerous content by the Cotter Technology 
Department, and is believed to be clean.

More information about the edubuntu-devel mailing list