[feisty] Slow gnome application startup due to /etc/hosts misconfiguration

[Conn O Griofa]

System Info: Dell Inspiron 510m, Intel Pentium M processor 1500MHz, 256mb ram, Feisty with latest updates.

Having used Feisty as my primary desktop, I noticed that applications take some time to load, even when another instance is already open; for example, gnome-terminal would take 5-10 seconds to load a new window even if another is already open, and without significant application load. Having done some research*, I modified /etc/hosts, changing this line:

127.0.0.1 localhost

to this ('inspiron' being my hostname):

127.0.0.1 localhost inspiron

After this little modification, most gnome applications seem to load much faster and persist in cache longer, so opening another gnome-terminal take usually ~1sec rather than 10 seconds, and other application follow the same pattern.

Steps to reproduce (best noticed with ~256mb ram):
1. On an unmodified Feisty installation, open a gnome-terminal, firefox, totem.
2. Do some moderate browsing to increase firefox memory usage.
3. Open another instance of gnome-terminal & totem, noticing application startup.
4. Edit /etc/hosts as above, repeat steps 1-3.

After this little tweak, applications seem to open much faster and share the system cache more efficiently (with less disk thrashing noticeable). Even my second system (using 1gig of ram) works more efficiently. This issue should be fixed before Feisty's release.

*See here: http://forums.gentoo.org/viewtopic-t-494659-highlight-.html
Also reported on Ubuntu Forums, user experiences of tweak and explanation can be seen here: http://www.ubuntuforums.org/showthread.php?t=388765

[Sebastien Bacher (seb128)]

Thanks for the bug report. This particular bug has already been reported, but feel free to report any other bugs you find.

That's similar to bug #26419, the system expects the lo interface being correctly configured

[Alex Launi (alexlauni)]

verified here as well. after adding my hostname 127.0.0.1 gnome apps are much quicker.

[Sebastien Bacher (seb128)]

not a gnome-desktop bug

[Sebastien Bacher (seb128)]

do you have "ping localhost" working correctly?

[Conn O Griofa (psyke83)]

Hi Sebastien,

Yep, it works. Here's my output:

conn@inspiron:~$ cat /etc/hosts
127.0.0.1 localhost inspiron
127.0.1.1 inspiron

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
conn@inspiron:~$ ping localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.038 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.036 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.036 ms
64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0.036 ms

--- localhost ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2997ms
rtt min/avg/max/mdev = 0.036/0.036/0.038/0.006 ms
conn@inspiron:~$ ping inspiron
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.038 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.038 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.037 ms
64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0.039 ms

--- localhost ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2997ms
rtt min/avg/max/mdev = 0.037/0.038/0.039/0.000 ms
---

Note that all I changed was the first line of /etc/hosts, by default it was:

127.0.0.1 localhost
127.0.1.1 inspiron

...etc.

I didn't know what package to file against as I wasn't sure what generates /etc/hosts, and that it's apparently a gnome-centric problem.

[houstonbofh (leesharp)]

I too have noticed a significant difference in both Feisty and Edgy. Boot times seem slightly quicker as well, but that my be wishful thinking. :) The only difference in mine is I added FQDN. (And the intellitext filter)

127.0.0.1 localhost boat.dnsalias.net boat nasioc.us.intellitxt.com toms.us.intellitxt.com
127.0.1.1 boat.dnsalias.net boat

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

[DRs endRs (hydroxic)]

This also speeds up my applications--even with 1GB of memory.

[Frank Niedermann (fbn)]

why was this bug rejected? will it be fixed in feisty as many users (according to the ubuntu forums) have performance increase after adding the described changes?

[John Dong (jdong)]

https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/26419

Because it has been marked as a duplicate of another bug.

[sam tygier (samtygier)]

launchpad didn't seem to think it was a duplicate, hence people being confused. i mark it (again?)

[sam tygier (samtygier)]

sorry, did not read all the way down the suposed dupe. this shouldn't be a dupe anymore. should it not be rejected anymore?

[deathbyswiftwind (deathbyswiftwind)]

I to can confirm this. My comp with 1gig of ram was taking firefox 10+ seconds to load everytime. By using this firefox opens instantly and without all the disk thrashing

[Sebastien Bacher (seb128)]

need to be debugged by somebody getting the problem, the bug has no useful information at the moment and doesn't happen to most of people

[Sebastien Bacher (seb128)]

not a GNOME bug

[Martin Bergner (martin-bergner)]

Can someone please provide the output of "hostname" and "hostname -f"?

[Frank Niedermann (fbn)]

there is more information in this thread: http://ubuntuforums.org/showthread.php?t=388765

and I some (many?) people have replied that they have the same behavior.

I can not test it or provide information as I'm not on Feisty yet and it seems only to occur on Feisty.

[Conn O Griofa (psyke83)]

conn@inspiron:~$ hostname
inspiron
conn@inspiron:~$ hostname -f
localhost

[Clemens (clast)]

clemens@clemens-desktop:~$ hostname
clemens-desktop
clemens@clemens-desktop:~$ hostname -f
localhost

seemed to work for me too! (on edgy, that is)

[houstonbofh (leesharp)]

I am willing to debug, but I am not sure what you need. No actual error occurs. I believe it is more an application timeout issue. With a stock feisty hosts file, some applications take a little longer to start than if you changed the hosts file as described. I timed it with Firefox, and it was a significant change. (About %60 reduction in startup time) It had not occurred to me that there was a problem before this "fix." I also noted similar behavior on Edgy. I have not tested this on Dapper, which has a different default hosts file. (It has the short name in both places)

Dapper hosts

127.0.0.1 localhost server
127.0.1.1 server.dnsalias.net server

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

[Martin Bergner (martin-bergner)]

I need that output from "hostname" and "hostname -f" when you are actually having the problem.

[Conn O Griofa (psyke83)]

Martin,

conn@inspiron:~$ cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 inspiron

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
conn@inspiron:~$ hostname
inspiron
conn@inspiron:~$ hostname -f
inspiron

I think this bug will be very difficult to diagnose, because a lot of this is about perception. I noticed that the cache is used more efficiently since changing the hosts file, meaning less delay/thrashing of the disk to load multiple gnome-terminals, for example. But having changed my hosts file back to defaults, it's just as fast...

I'd prefer a better way to benchmark the system rather than rely on subjective measurements (I thought of strace -c, but it waits for you to close the application and so wouldn't be a good benchmark, perhaps).

[Martin Bergner (martin-bergner)]

I had this problem myself and I also knew this workaround. I even had the problem that at some point I couldn't start any application. I know that it is at least related to this bug.

So Conn, if you run ping $(hostname) with the "failing" settings, what does it give you?

[Conn O Griofa (psyke83)]

Using default /etc/hosts:

conn@inspiron:~$ ping $(hostname)
PING inspiron (127.0.1.1) 56(84) bytes of data.
64 bytes from inspiron (127.0.1.1): icmp_seq=1 ttl=64 time=0.037 ms
64 bytes from inspiron (127.0.1.1): icmp_seq=2 ttl=64 time=0.040 ms

Using modified /etc/hosts:

conn@inspiron:~$ ping $(hostname)
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.038 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.040 ms

If you mean to ping while applications are "slowing down", I'll try, but as I said it's quite erratic and difficult to reproduce.

Thanks,
Conn

[Jarmo Ilonen (trewas)]

First of all, gnome apps are starting fine and fast on my two feisty installations without this modification.

Anyway, I think strace should show where the slowdown happens quite clearly. If for example gnome-terminal is one of the apps that start slowly, strace can be used like this (when using bash):

strace -r gnome-terminal -x echo &> /tmp/log

With option -r, strace counts the time for each syscall, and gnome-terminal will quit immediately after executing the echo command. The log will be in /tmp/log, each line starts with a number telling how long executing the call took, and most of them will be close to zero. When the slowdown happens there should be one or maybe few lines with abnormally high values (probably several seconds, if the app really is taking 5-10s to start).

Maybe someone with the slowdown could attach the log here, or maybe just few lines around the "slow" call? A quick way to check if there are some offending lines in the log is

grep -v '^\ *0' /tmp/log

which will show if there are lines in the log which took >= 1 second (lines which don't start with a zero).

[eppy 1 (choppy121212)]

I saw what looked like some sort of an explanation on (...don't laugh :P) Digg. I'm guessing you already have this info, but just in case..: http://www.digg.com/linux_unix/Performance_tip_for_Ubuntu_Edgy_and_Feisty_users

"
I have a celeron 2ghz cpu and 256 MB of ram and the difference is really noticeable.

Here is an explanation why it works by Kerry_s from ubuntuforums :

http://ubuntuforums.org/showpost.php?p=2324914&postcount=6
"This is a fix for the new system that was started back in edgy where the host name was split off to 127.0.1.1, the problem is that some applications still look for the host name @ 127.0.0.1, so to keep those applications happy and running smoothly you simple need to add the host name where those applications expect it to be."
"

[Florian Zeitz (florian-zeitz)]

I get some "interresting" behaviour, when I do hostname and hostname -f:
hostname:
"myHostName"
hostname -f:
"hostname: Unknown host"

In my /etc/hosts I have:
"127.0.0.1 localhost
127.0.1.1 myHostName.localdomain.xx

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts"

It seems the system is not able to resolve the short hostname myHostName (a ping shows this behaviour too).
Adding myHostName to either the 127.0.0.1 or the 127.0.1.1 line makes it possible to resolve the hostname.

[Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen)]

Wow. Gnome-terminal and nautilus launch within a second now. They use to take at least 2 seconds.

If I read the comments here 'correctly' this is not a bug, but a workaround for bugs in _some_ applications. Nevertheless, it might be a good idea to apply this patch by default, just for Feisty. As a sort of short-term 'fix'.

[Conn O Griofa (psyke83)]

Ralf,

Although it seems to increase startup speed of applications for a lot of
users, there is the possibility that this change is breaking things
elsewhere. For example, "hostname -f" now reports "localhost" instead of my
hostname (as it did before the change to the hosts files). This needs to be
investigated by someone knowledgeable enough before it's committed.

On 3/25/07, Ralf Nieuwenhuijsen <email address hidden> wrote:
>
> Wow. Gnome-terminal and nautilus launch within a second now. They use to
> take at least 2 seconds.
>
> If I read the comments here 'correctly' this is not a bug, but a
> workaround for bugs in _some_ applications. Nevertheless, it might be a
> good idea to apply this patch by default, just for Feisty. As a sort of
> short-term 'fix'.
>

[ropers (ropers)]

"This needs to be investigated by someone knowledgeable enough before it's committed."

man hosts

sudo vi /etc/hosts
ji# ESC$bywk$a ESCp:x

(DISCLAIMER: I'm a BSD guy. If this, for whatever weird and wonderful reason, breaks shit in Linux, don't blame me.)

[Sebastien Bacher (seb128)]

could anybody get concrete numbers with the strace command describer before, the explanation about applications using hostname on 127.0.0.1 does't really makes sense and that would happen for everybody anyway which is not the case.

[Matt Sicker (jvz)]

Does anyone know how to time how long it takes for an application to launch? I know how to test how much CPU time an application takes to execute and halt, but nothing about "measure the CPU time until the program spikes down in CPU usage" or similar.

Also, is this a problem with KDE applications as well? I doubt this is just a GNOME problem, so we need more applications tested. Since this was recently dugg on digg, that should help us get like 3000 more Ubuntu users to try this out. ;)

[Matt Sicker (jvz)]

OK, this bug deals more with hostname than it does with anything else as far as I can tell. I need some debugging info, so someone needs to run "/usr/bin/time -o fx-old -v /usr/bin/firefox" before the change, and "/usr/bin/time -o fx-new -v /usr/bin/firefox" after the change, then attach those two files here. Also, if anyone knows how to run strace to debug this, please go ahead and attach any info you can get about it.

[Vipul Delwadia (vipul-delwadia)]

Ok, so after reading through this entire thread, I've run the various things people have suggested in order to help debug this.

Attached is the output, as follows:
hosts-* - the hosts file before and after
hostname-* - the output of hostname, hostname -f and ping -c 4 $(hostname) before and after
strace-*.log - the output of the strace command suggested above before and after (two logs for each). Run on gnome-terminal, and the first run was the first time I launched gnome-terminal after booting into feisty.
time-*.log - the output of the time command suggested above before and after (two logs for each). Run on gnome-terminal, and in each case <ctrl>-<d> was sent as soon as the terminal launched.

Hope this helps,
Vipul

[Jarmo Ilonen (trewas)]

Vipul,

Unfortunately there does not seem to be any clear difference between starting times before or after the change. Looking at the strace logs the total times are before 1.71s and 0.76s, and after 0.61 and 0.65. The only one that stands out of those is is strace-before-1.log and looking at it seems that normal file handling operations etc were a bit slower, it was probably the first run and files were not yet cached. Also time-* logs show 1-1.5s elapsed times for all runs, so in this case the /etc/hosts modification does not seem to make a difference.

Strace log would be interesting from a case where the startup of gnome-terminal is significantly slower than it is after the /etc/hosts modification, for example, from a ~10s startup like the original bug reporter mentions.

[sam tygier (samtygier)]

would
time gnome-terminal -e "exit"
be a good benchmark?

[Jarmo Ilonen (trewas)]

Command

time gnome-terminal -e "exit"

is ok for checking if there is a difference in startup times before and after /etc/hosts modification. The startup time alone does not tell anything useful even if there is a clear difference, so the strace log should be attached from the slow startup case. The command for getting the strace log is (copy&paste from above)

strace -r gnome-terminal -x echo &> /tmp/log

which stores the log to /tmp/log

[Ricardo Arguello (ricardo-arguello)]

Read this blog, it has some very interesting info:

Debian and localhost.localdomain
http://www.oreillynet.com/linux/blog/2007/01/debian_and_localhostlocaldomai.html

[Wenzhuo Zhang (wenzhuo)]

I am experiencing exactly the same problem. For details, please read https://launchpad.net/ubuntu/+bug/69941/comments/7

[Jan Bendtsen (dimon)]

Hi,

Just wanted to add a "me too" - I have a newly installed Feisty Beta on a desktop PC with 2 GB RAM. It was consistently slower with just about everything (or so it seems) than my earlier Edgy install. Also, I use DHCP at our in-house LAN, and my box would quite consistently lose its IP address after a few minutes (claiming there were no more DHCP slots available, although this was clearly not the case, given the network configuration). Since I included the hostname after localhost in /etc/hosts , everything is working much faster and I haven't lost my IP address so far (at least three hours).

[Julius Bloch (jbloch)]

Hi,
I have this problem on an Athlon Xp 2400+ with 758MB RAM. I am running feisty with all updates.
Here some Output from my system:
time gcalctool

** (gcalctool:6656): CRITICAL **: failed to load icon 'lpi-bug': Symbol »lpi-bug« nicht im Thema vorhanden

real 0m16.155s
user 0m9.301s
sys 0m0.484s
juliux@seeler:~$

So gcaltool needs 9,3sekunds to start. That is very very slow.
strace log attached:

I changed the settings in /etc/hosts but nothing changed.

juliux@seeler:~$ hostname
seeler
juliux@seeler:~$ hostname -f
localhost
juliux@seeler:~$ cat /etc/hosts
127.0.0.1 localhost seeler
127.0.1.1 seeler
172.23.42.130 volkspark
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

[Sebastien Bacher (seb128)]

Do you have a /usr/share/icons/hicolor/16x16/apps/lpi-bug.png? What version of liblaunchpad-integration0 is installed?

[Julius Bloch (jbloch)]

Yes I have /usr/share/icons/hicolor/16x16/apps/lpi-bug.png
liblaunchpad-integration0 ist 0.1.13

[Sebastien Bacher (seb128)]

The icon is correctly installed then, likely an outdated icon cache, not causing the slow GNOME

[Jarmo Ilonen (trewas)]

JuliusBloch,

Doesn't look like network related (as could be guessed from /etc/hosts not changing start up time). Gcalctool seems to be doing something weird with the fonts, first 27000 lines of the strace log are mostly stuff like

stat64("/usr/share/fonts/truetype/ttf-arabeyes/ae_AlYermook.ttf", {st_mode=S_IFREG|0644, st_size=121972, ...}) = 0
open("/usr/share/fonts/truetype/ttf-arabeyes/ae_AlYermook.ttf", O_RDONLY) = 15
fcntl64(15, F_SETFD, FD_CLOEXEC) = 0
fstat64(15, {st_mode=S_IFREG|0644, st_size=121972, ...}) = 0
mmap2(NULL, 121972, PROT_READ, MAP_PRIVATE, 15, 0) = 0xb600f000
close(15) = 0
munmap(0xb600f000, 121972) = 0

So it opens a font file, mmaps it, then closes and munmaps, presumably doing something with the font data in between. And it does that a lot. Grepping for "stat.*usr.*fonts" gives 2823 hits, and the font stuff takes most of the time in strace log. I straced galctool myself and the same grep gave only 39 hits and starts in under one second. I have no idea why it's doing that with the fonts in your case, maybe someone with more knowledge of gnome font handling has some idea... It's a separate bug to this /etc/hosts case anyway.

[Julius Bloch (jbloch)]

Hi Jarmon,
thxs for your replay.
gcaltool is not the only programm which starts so slow. It is every programm under GNOME.

[Conn O Griofa (psyke83)]

Hi Julius,

Perhaps your font cache is corrupt? Run "sudo fc-cache -f -v" and if there's no errors in the output, reboot and see if GNOME apps load any faster.

[Gareth Fitzworthington (mapping-gp-deactivatedaccount)]

This is a long shot, but perhaps this bug is related to Bug #110187. This bug primarily concerns wireless connectivity but one of the side effects when there is no working network connection is that login from gdm is very slow and then once the desktop is loaded, the desktop is slow. This maybe related to avahi (not sure)???

[Gareth Fitzworthington (mapping-gp-deactivatedaccount)]

The slow login/desktop bug appears to have been around for a while. The bug is reported in edgy & feisty and they are mostly unconfirmed and mostly of undecided importance. Although I'm very happy with feisty, I am finding this bug a bit bothersome so I thought I'd do some research through the bug archives.

I think this bug has been reported numerous times. The bug list that follows, I think are reports of effectively the same bug.

Bug #78263 - claims workaround (feisty)
Bug #78493 (edgy)
Bug #79466 (edgy)
Bug #80827 - claims workaround (edgy)
Bug #92997 - claims workaround (feisty)
Bug #94048 (feisty)
Bug #110616 (feisty?)
Bug #110775 (feisty)
Bug #110187 - reports slow desktop as a side effect of other network config issues. (feisty)
---------------
Bug #95264 - Maybe related (not clear) (feisty)
Bug #93447 - Maybe related (not clear) (edgy)
---------------
It seems most discussions are blaming this bug on one or more of:
Network-manager
avahi
hosts file
resolve file
static IP addresses
no network connection.

I can't vouch for the claimed workarounds - but I intend on investigating them further.

The person who solves this one will likely 'kill a number of bugs with one stone'.

I hope I'm not being too forward by presenting such a list but I am rather keen to see this bug solved. I hope this list helps to unify further discussion & prompts some further thought on the matter.

(note: I have posted it to all above bug reports so that all are in the loop)

[Gareth Fitzworthington (mapping-gp-deactivatedaccount)]

Add Bug #79661 to above list.

[Heine Andersen (heine-andersen)]

I did have a similar problem, turn out to me a fontproblem, fc-cache did'nt update the fontcache
because of a timestamp issue, try to touch the font dirs, and run fc-cache again.

sudo fc-cache -fv 2>&1 | grep failed | cut -f1 -d":" | xargs -i sudo touch {} && sudo fc-cache -fv

[lolziac (labinoth)]

I got a Fujitsu Siemens AMILO PI 1536.
With Edgy i didn't have a slow application performance, but by installing Feisty I encountered problems of this nature.

editing /etc/hosts in Feisty as described, helped me with the problem.
Just to open a Gnome-Terminal it was taking 10-15 sec, same for other applications (it was driving me crazy :P).
But now it only takes 1-2 sec.

Thank you

[toutatis (bijbelenos)]

Fixed my problem on Feisty too.

[John Wells (jfw)]

Same problem here. Feisty 32bit. Using Network manager. AMD Turion x2 laptop. Atheros wireless.

The problem manifests itself for me as incredible desktop slowness when connected to some wireless networks. Top shows no excessive CPU use or any problem processes. Nothing interesting in the system log.

When I launch programs, they simply don't show up -- the panel shows "Starting xxxxx", and the application may load up after 30 seconds or so, or even longer (sometimes not showing up at all). Right-clicking network manager in Notification Area, and selecting "Disable Wireless", or changing to a different wireless Access Point, causes the applications I am waiting for to suddenly appear!

"slowness" is a misnomer here -- "uselessness" is more like it. Everything -- even gnome-terminal is affected. Firefox seems to have connectivity -- but waiting for 30 seconds just for URLs to resolve makes it pointless.

Interestingly, if I right-click and choose "Disable networking", without selecting "disable wireless", the slowness usually does not stop.

It seems to be somewhat random -- it affects about 70% of APs I try to connect to. (Invariably, only affecting the ones I *want* to connect to). These are all unsecured, public access points.

Network Manager is managing all my connections -- the only change over default I have made is adding some DNS server to the prepend list in /etc/dhcp3/dhclient.conf, as my router's DHCP/my ISP at home is flaky, and I get DNS timeouts unless I statically configure DNS servers. (problem has existed for years).

I notice that in my case, the loopback interface also didn't have a hostname assigned in /etc/hosts. Will try adding and will report back as to whether this fixes the problem.

*PLEASE* decide on an importance for this bug. Nothing more irritating/embarrassing than taking your laptop to a coffee shop and spending the entire time trying to figure out why everything is slow as molasses.

[Bryce (bryce-white)]

Editing /etc/hosts solved my problem.

127.0.1.1 was xxx.brycewhite.com (which wasnt resolving)

By changing this line the slow down of application launching was immediately resolved.

It seems that if you have a 127.0.1.1 that doesnt immediatly resolve (firewall/router/invalid dns entry) then this causes the problem.

[Sebastien Bacher (seb128)]

not a gnome-desktop bug

[Bogdan Costea (bogdanco)]

Solved my Feisty problem too. My laptop was experiencing this startup latency issue when i had no network connection.
It seems that it's trying to resolve the hostname. Adding the hostname to 127.0.0.1 solves the problem.

[Gareth Fitzworthington (mapping-gp-deactivatedaccount)]

I can also confirm that editing /etc/hosts solved this for me (by adding the host name to 127.0.0.1).
I have Ubuntu7.04.

[Aaron C. de Bruyn (darkpixel2k)]

I had two lines in hosts set as 127.0.0.1:
127.0.0.1 localhost
127.0.0.1 mylaptop

I changed it to:
127.0.0.1 localhost mylaptop

My issues disappeared.
My issue popped up when I'd try to shutdown the box.
Go to System->Quit and it would take about 10 seconds to pop up the shutdown dialog.

[Launchpad Janitor (janitor)]

[Expired for hostname (Ubuntu) because there has been no activity for 60 days.]

[noddeat (noddeat)]

This issue is in Gutsy too. So will the developers someday include this fix in the default distro configuration? If not, why?

[Sebastien Bacher (seb128)]

The bug has lot of random comments and is not clear, if there is still an issue somebody should do a clear summary on how to trigger it and the suggested change

[Hans Deragon (deragon)]

Here is a bug that has an impact on Gnome's bootup speed, with a fix that awaits to be accepted:

[/etc/auto.net must abort if computer is not connected to a network.]
https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/184475

Maybe some of the users following this bug have the same problem as the one listed as #184475?

[Andres Mujica (andres.mujica)]

Hi, i was hit by his bug after changing the hostname for my machine.

Steps to reproduce it:

1. Fresh install
2. Test everything works ok the start up, etc.
3. change the hostname for the machine
4. You'll get slowdown mostly starting up desktop
5. Apply the workaround
6. System became responsive again.

I've got this line from .xsession-errors.

** (x-session-manager:6199): WARNING **: Host name lookup failure on localhost.

I'll try to test this more throughly in order to find the items involved.

[Andres Mujica (andres.mujica)]

i'm on gutsy by the way

[bigredradio (dhuffman)]

Editing the /etc/hosts entry is a terrible workaround. The xserver should be using 127.0.0.1 or localhost. Adding the hostname of the system to 127.0.0.1 is incorrect as far as I understand. Your hostname is what your ip address is on the network. Unless you have a system that is not connected to a network, then there will be a confusion because users will also have an entry in /etc/hosts or with their DNS servers that conflicts.

127.0.0.1 localhost myhostname
192.168.1.1 myhostname

In this case, which is correct? The loopback address should be reserved for localhost. The window manager or xserver should be using only that address. Not trying to resolve the hostname to an address. Maybe someone can enlighten me here. I work with software that relies on correct name resolution to ensure network connections between client/servers. How does this "fix" effect the host command?

[xteejx (xteejx)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with latest Ubuntu release? Thanks in advance.

[Heine Andersen (heine-andersen)]

It's not a issue anymore :)

On Thu, Nov 27, 2008 at 8:33 PM, Teej <email address hidden> wrote:

> Thank you for taking the time to report this bug and helping to make
> Ubuntu better. You reported this bug a while ago and there hasn't been
> any activity in it recently. We were wondering is this still an issue
> for you? Can you try with latest Ubuntu release? Thanks in advance.
>
> ** Changed in: ubuntu
> Status: New => Incomplete
>
> --
> [feisty] Slow gnome application startup due to /etc/hosts misconfiguration
> https://bugs.launchpad.net/bugs/94048
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[andso (andso)]

when will you have an other response than
[Expired for hostname (Ubuntu) because there has been no activity for 60 days.]
i' ve experiended this on some machine where i have installed xubuntu, and never an account of "where are learning about this major bug", because it is.
Have a look on the strange behaviour of /root/.gnome2/network-admin-locations/config_files where the "," ";" are an incredible "bazar".
The low reactive response of ubuntu (see the phoronix test) may have a "lien"(french word) to this big bug! "faire le ménage" seem to be the major challenge for us, and have to be, ...
have regards

[Milan Bouchet-Valat (nalimilan)]

This bug is still marked as incomplete because nobody could find precise causes to it, and it seems to have drawn less attention for about one year, maybe meaning that it's been fixed. Developers would need precise informations (procedures, logs...) to do something.

Your comment doesn't help much in that regard. What's the link with the /root/.gnome2 stuff? You should never run GNOME as root, for a start. And XUbuntu is not using GNOME, so that would be another bug.

[andso (andso)]

Two years ago the answer was identical.
"and it seems to have drawn less attention for about one year"
some person touched have applied the "patch" in /etc/hosts

"What's the link with the /root/.gnome2 stuff?"
i don't know but the format of the files seems to be not established
i' have tried, and spent a lot of time, to understand with my "in learning" linux meanings to resolve it.
I'm a user,

"And XUbuntu is not using GNOME, so that would be another bug."
are you serious?: xubuntu is more and more using gnome features (gdm, gtk (obviously) and is slow for the same reasons (and the correct behaviour is solved by 127.0.0.1 localhost hostname))

why do not give to the community a plain view of the files implicated for an eradication of this slow big bug (i use sometimes zenwalk standard (xfce too) and the responsivity is incredible/ xubuntu )

i always will help on ubuntu forums but leave this distrib which walks on the steps of a proprio operating system by his cecity and not take in account the remarks of volontarist users. (hard on this remark)

we are poor lonesome ubuntuboys
amitiés and bye

"Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with latest Ubuntu release? Thanks in advance."
No i do not try, because i want a stable operating system with few helpfull changes on the time: my life is on the planet, not inside a system ( soit-il opérant)

friendly regards

[Andres Mujica (andres.mujica)]

I'm closing this bug report because it lacks a complete and concrete explanation of how to reproduce the issue. Please, if you're being affected by this bug, will be really grateful if you can provide us with a complete test case that can be used to validate and solve this bug.

Please refrain to make unhelpful comments, those wouldn't solve the bug. We need to be able to reproduce the bug in order to solve it.

Thanks in advance

[rcmichelle (wr-michelle001)]

Ha,why not use a software to fix this problem,try to google tuneup360,you can find it.

[houstonbofh (leesharp)]

On 11/18/2010 09:36 PM, rcmichelle wrote:
> Ha,why not use a software to fix this problem,try to google
> tuneup360,you can find it.

Someone whack this SEO spammer.

[Tommy Trussell (tommy-trussell)]

houstonbofh wrote on 2010-11-19: #73

> Someone whack this SEO spammer.

HEY no need to repeat the spam in your comment! I opened Bug #677888 to report the user

[xteejx (xteejx)]

There is actually no need to open a bug report, and I'm guessing it will be closed anyway. The correct procedure AFAIK is to report it directly in #launchpad on irc.freenode.net, so please do so. Also, this bug report was closed and marked Invalid, so please do not send any further messages to this bug report to save spamming all subscribers unless it is *absolutely* necessary, i.e. this bug has reappeared in a supported Ubuntu version. Any further discussion about the spamming should be done on IRC, or on the bug reported by tommy-trussell. Thank you guys.