Comment 3 for bug 269188

Maybe the following observation gives a hint for solving the bug:

System: 1 primary server with dhcp, ltsp boot user identification (NIS), and homedirs (NFS).

I deleted all firefox profiles and let 26 students login and start firefox simultanously. Students had the advice to click firefox only once and had wait and observe. The result was as described above: 6 users got firefox immedeately, 15 users got firefox after more than 5 Minutes, and 3 users had no success in starting firefox.

The pending firefox start show that the creation of the firefox profile is quick but the creation of the lock file is delayed. I guess that the programm is delayed by the process setting the profile lock.

3 days later and later on the same class could start firefox without delay. All administrators who are claiming the delay were in the situation starting firefox 3.01 for the first time after new installation or upgrade from firefox 2. I suppose that the bug also has a cause in creating a firefox profile and updating a profile from firefox 2 respectively.