Lazyness pays back

Today I've finally solved an issue that had hurt me quite much awhile back.

In short, I had no internet connection at home for literally three months... but that's another story. I've noticed that my login GNOME session starts very very slow. A bit of investigation and I've learned that this was caused by DNS calls at the start of nearly every GNOME app. The network is basically down, so it takes about a minute to `complete' the request--of course it ends with error.

I've even used the following trick: boot my Debian box in single user mode, enter root password to get to recovery shell, shutdown networking (ifdown eth0), Ctrl+D to proceed to multi-user runlevel. This also helped to skip another one-minute hang when MTA (exim4) was starting.

This lasted for quite a while. But then, hooray, the internet was back and I totally forgot about the issue. Well, almost. I've added a reminder to file a bug about this somewhere. It's been nearly 5 months now since that reminder was added. ;-)

So today I've finally got to it. I've armed with tcpdump and tried to reproduce the problem--tcpdump showed two DNS calls at the start of e.g. gnome-terminal and gedit but not gcalctool (who knows why). Then I tried to search if such bug already filed at bugzilla.gnome.org. Browsed some bugs and this gave me a hint to use strace to figure out what calls are coming from the app being launched.

Plain strace gnome-terminal produces a lot of junk, so `man strace' and a-ha! we can reduce the output to network related calls by strace -e trace=network, sweet! :-)

Uh... a bit of head-scratching. Hey, there's only local Un*x sockets for Orbit and the like...

Finally a more close look on tcpdump output and I'm doing

# vi /etc/hosts

and... Hey! There's clearly a bug here at line

192.168.1.2 zrbite.localdomain zrbite.localdomain

it should read

192.168.1.2 zrbite.localdomain zrbite

OK, :w Now let's try this again. Great! No more DNS calls! :-)