Sloooow OOo? This could be the answer!
One
of the residual issues from my
troubled Kubuntu 10.4 upgrade was a
puzzling OpenOffice.org problem.
Last week I finally got a chance to
investigate it. The solution may surprise you!(If you can't be bothered with the dissertation and just want to try the solution, click here.)
The problem
Package developers like tinkering with other people's code. I'm not sure why, especially when suites like OpenOffice.org come tried and tested for all flavours of operating system direct from the home website. In the case of 10.4, OOo was still at version 3.1 when I'd been using 3.2 for months.
The Ubuntu version started speedily enough, but every time I clicked to open a file it would freeze for 20 seconds. Every time.
I checked running processes, I checked
top,
I checked memory usage -- nothing out of the ordinary. Just 20 seconds
lock-up for each and every File / Open. Damned annoying!So I ditched it, downloaded version 3.2.1 from OpenOffice.org and tried that. The file opening problem vanished, to be replaced by sluggish start up. Hit go, up pops the splash screen and -- yes, 20 seconds later -- the program opens. Once running however, everything was fine. It was just that initial startup.
I've never suffered with sluggish OOo before and, as I said, last week I finally got round to a thorough investigation.
The Clues
The first clue came from unplugging the network lead. No network = instant start. Ah-ha!
There are tons of references to networked printers causing slow OOo, and yes, I run a networked printer. But none of the suggested solutions -- such as setting the default printer to fax or PDF -- made any difference, and none explained the reason why this should affect start-up.
So I kicked off Wireshark and watched the network traffic. That was when I spotted what was happening.
My PC's name is "asok" (I'm a Dilbert fan). Every time I started OOo, a DNS request was sent seeking the IP address of "asok.(none)" -- which doesn't exist. So the request would time out, another would be sent, that too would time out ... until eventually the seeker gave up trying and the start-up continued.
Now "asok" is associated to IP address 192.168.1.100 in my
/etc/hosts
file...
192.168.1.100
asok |
...so adding another name resolution in the form of ...
192.168.1.100
asok asok.(none) |
... made my problem vanish. Yay!
But why is OOo seeking "asok.(none)" in the first place?
The Reasons
Having nailed the problem -- and therefore my precise search terms -- it was easy to find and explanation. Here is it, from a 2003 forum post by Lars Oppermann, a StarOffice (OOo's predecessor) Software Engineer:
For each user, OOo keeps a set of configuration files. Those files may
only be accessed by one instance of OOo at a given time.
One user can only run one single instance of OOo on a single given host
- but in a networked environment with transparently mounted
home-directories, two sessions on different hosts could be started
accessing the same configuration (oh the horror!).
In order to prevent this kind of simultaneous access, OOo will create a
lock-file in the root of the configuration direcory (e.g.
$HOME/OpenOffice1.1/.lock) in which it saves the starting-time,
username and hostname for the instance that has locked the
configuration. Now, if another instance is started on another host, it
sees the lockfile and warns the user.
The reason why we keep the hostname, is that in case of abnormal
termination and stale lockfile we can notice that the lockfile was
created on the same host we are running on. If that is the case, we can
take over the lockfile and don't need to display a warning, since only
one instance per user/host can run; any additional instance on the same
host would connect to the socket of the first instance and just hand
over it's commandline.
In short, it's all to do with preventing simultaneous access to the same user configuration files on a network. My guess -- though I haven't confirmed this -- is that if I'd selected the "single user" option in OOo's setup, this wouldn't have happened.
The solution
Well that's investigation and the reason. How can you try a DIY fix with resorting sniffing network traffic? After all, my solution won't work for your machine -- unless you happen to have a PC called "asok" on address 192.168.1.100 -- so here's a simple way to determine exactly what should be in your
/etc/hosts...1. Start OOo.
2. When it's running, drop into a console session and type
cd ~/.openoffice.org/3
and list all the contents of this folder
ls -la
You'll get something like this...
total 20
drwx------ 4 geoff geoff 4096 2010-06-23 17:04 .
drwxr-xr-x 3 geoff geoff 4096 2010-01-09 11:33 ..
-rw-r--r-- 1 geoff geoff 132 2010-06-23 17:04 .lock
drwxr-xr-x 18 geoff geoff 4096 2010-01-10 17:25 user
drwxr-xr-x 8 geoff geoff 4096 2009-09-21 21:09 user_backup
3. The .lock file is the one we're after. Print out its contents with
cat .lock
Here's mine...
[Lockdata]
User=geoff
Host=asok.(none)
Stamp=4BF3169071E73BF7D70...
Time=Wed Jun 28 17:04:48 2010
IPCServer=true
4. And there you have it; the host name that OOo searches for on start-up. Tack it to the end of the appropriate line in
/etc/hosts,
and you're away!
192.168.1.100
asok |
192.168.1.100
asok asok.(none) |
So, did that work for you? Leave me a comment and let me know.
A footnote for Windows users: You'll typically find OOo's .lock file in the folder
C:\Documents and Settings\USER NAME\Application
Data\OpenOffice.org\3
Compromised 
