If you’re not a Linux geek, feel free to ignore this post. <\/span> <\/p>\n
I started OpenOffice today, and soon found that it was pegging my CPU. This had happened a previous time I started it, but I just killed it and didn’t investigate. I needed to get my paper written this time, so I investigated. I attached to the offending thread with strace, and saw that it was in a busy loop of connecting to port 631 (ipp) on localhost, sending a request, and immediately failing on a Broken Pipe. A quick check of \/etc\/services revealed that this port belongs to the Internet Printing Protocol (IPP). I have no printing installed on my machine, so this seemed strange, along with the fact that this is only the second time I’ve seen this happen. I found the process listening on that port with “lsof -i :631”. It turned out to be rpc.mountd, which I then recalled was also showing activity at the same time. This didn’t make sense, as this process helps with NFS, not printing. I hypothesized that this was one of the RPC protocols that allocated a random port at startup, and it just happened to pick that one this time around. (I recently had to reboot my machine.) I thought auto port numbers started at 1024, though, so I wasn’t sure. Regardless, I caused it to reallocate its port by invoking “\/etc\/rc.d\/rc.nfsd restart” (Slackware). Sure enough, it picked a different port this time, and OpenOffice now works fine. <\/p>\n
This was a rather strange coincidental conflict between two disparate programs that just happened to have both undesirable and noticable consqeuences. I’d say it’s the fault of both programs: RPC services should pick unreserved ports above 1024 to avoid collisions, and OpenOffice shouldn’t be busy-looping on a network connection. <\/p>\n","protected":false},"excerpt":{"rendered":"
If you’re not a Linux geek, feel free to ignore this post. I started OpenOffice today, and soon found that it was pegging my CPU. This had happened a previous time I started it, but I just killed it and … Continue reading