Extreme slowness, "Firefox is already running" error for >3 users launching Firefox in LTSP environment

Bug #269188 reported by Jordan Erickson on 2008-09-11
16
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
Medium
firefox-3.0 (Ubuntu)
Undecided
Unassigned
Hardy
Undecided
Unassigned
nspr (Ubuntu)
Medium
Unassigned
Hardy
High
Unassigned

Bug Description

Binary package hint: mozilla-firefox

---
Ubuntu Hardy 8.04.1
Firefox 3.0.1
LTSP Environment
Various sites, various thin-clients, same server (HP Proliant ML370 G5, 2x dualcore Xeon 1.6GHz CPU, 8GB RAM, 160GB SAS
---

I'll just paste in what seems to be the common problem here amongst 4 of
my schools, when there is a full class of ~35 students logging on and
trying to launch Firefox (these are all different people sending me
e-mails):

-----
Just had a class in here and they went on Firefox, it took about 4
minutes to get them all on. First 5 popped up right away then it
started to slow down. Had 3 stations that after everyone was in I had
them click on the browser icon and they go right on.
---
Four or five students were able to start working in typingmaster (within
Firefox). For the rest, it told them they were already in Firefox.
---
It took 15 minutes for 20 computers to logon to Firefox. The first one
took 10 seconds, the next 20 seconds, the 6th one to try and come up had
the "Already Open" error. After 20 minutes I went back into
Apps/firefox with the remaining workstations and all but two went in.
Workstations s8, s9 have the error message.
---

Tested Firefox today with a class of 20. About half could get on 1 at
a time, the other half froze up the desktop and kids couldn't even
logoff Ubuntu.

-----

After a ton of research for the past 3 days, I've come up with the
following potential fixes which have sped things up just a bit, but
definitely do not solve the core "Firefox is already running" (and most
of the slowness) issues: http://lns.wikidot.com/firefox3ltspoptimizations

These are all beefy HP Proliant servers, 2xdualcore Xeon CPUs, 8GB RAM,
so horsepower shouldn't be an issue. Gutsy + FF2 worked beautifully,
this only started happening at the beginning of this school year, after
I had upgraded all servers to Hardy+FF3 over Summer break.

Reproducible: Always

Steps to Reproduce:
1. Log 10 different users into separate Ubuntu 8.04.1 LTSP client sessions
2. Launch Firefox 3 in all user sessions at the same time
3.
Actual Results:
Extreme slowness in launching Firefox, random "Firefox is already running"
error message popping up with users, extremely high CPU usage (30-60% usage on
2x dualcore Xeon 1.6GHz CPUs) with all running Firefox processes at idle. Some
users will experience "Starting Firefox" on bottom Gnome panel, and then it
will disappear (no Firefox gets launched)

Expected Results:
Firefox should launch normally for all users, with minimal CPU usage, and no
"Firefox is already running" errors popping up.

Running 'firefox' from a terminal yields no output.

---
"LTSP-Discuss" List thread describing the issue and commented on by others with the same problem:
http://sourceforge.net/mailarchive/message.php?msg_name=48C04301.6060309%40logicalnetworking.net
---
Also reported upstream, here: https://bugzilla.mozilla.org/show_bug.cgi?id=453704
---

Related branches

Alexander Sack (asac) wrote :

ogra, what are your experiences with such ltsp setups and firefox? Are they all seeing similar performance impacts? If not, what could be the problem here?

Changed in firefox:
status: New → Incomplete
Kai Wollweber (wollw) wrote :

I encountered the same problem at our school with a multiple server
setup of ubuntu hardy and Firefox 3.01. No way to keep students working.

We should collect some more information to ensure not to mix different
issues:

1.)
Is this only a problem with Firefox 3.01 or shows Firefox 2 the same in
hardy?

2.)
What kind of lock files do you get in the various situations?
(cd to firefox profile, ls -la | grep lock)
case
a. firefox starts normally
b. firefox start is delayed
c. firefox terminates with message "Firefox is already running"
d. firefox crashes without message

3.)
Are you working on multiple servers with home directories mounted via
nfs?

4.)
What happens if students start the browser from terminal with the
command firefox -save-mode ?

Explanation to Question # 2.):

I have looked at the firefox profile and the profile locking mechanism
where I suppose the cause of our problem. I found out that Firefox 3 has
a different mechanism of profile locking. In the profile folder
(/home/user/.mozilla/firefox/xyz.default/) a symbolic link is created by
the starting firefox:

ls -l shows the link named "lock":

lrwxrwxrwx 1 wollw wollw 15 2008-09-08 20:32 lock -> 127.0.1.1:+6164

The link disappears as firefox exits.

I am not familiar with the strange "->Ip:+Number" syntax, which are the
loopback IP and the process number of the firefox process. Can someone
explain what kind of link this is? Appending text to the file and
reading from it shows that it is a kind of named pipe.

If I remember correctly: Former versions of Firefox had just an ordinary
file named "lock". In consequence to this change a second firefox
process now just opens a new window but gets part of the existing
process while in former versions the second process terminated with the
error message "Firefox already running".

Please have a look at the lock file. In another situation even on the
local machine insted of loopback IP the IP of the interface eth0 is
given:

lrwxrwxrwx 1 wollw wollw 19 2008-09-08 21:58 lock -> 192.168.0.20:+21469

I describe this in fully detail as we have a multiple server environment
with three secondary servers and one primary ltsp server which holds the
home directories (and therefore the users firefox profiles. The
home-directory is mounted by nfs.

There are issues at bugzilla about former versions of firefox with
profiles at nfs mounted locations.

Kai Wollweber (wollw) wrote :

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.

Jordan Erickson (lns) wrote :

wollow, I also see that some users will have more success *after* attempting 2-4 launches that have previously failed (and caused the whole Gnome session to somehow become unstable). By no means a "workaround" or that it makes the bug less relevant, but maybe some useful troubleshooting info. Generally, I have heard from my sites that they have had more success getting entire classes on after 2-4 attempts on different days of failing.

Jordan Erickson (lns) wrote :

Please see IRC log I had today in #firefox (irc.mozilla.org) - Notably the conversation between "Lns" and "mzz", which details a lot about this situation, and possible troubleshooting steps. I will be trying the " toolkit.storage.synchronous " pref at one of my sites on Monday hopefully, and will report the outcome. Others are welcome to test anything in there as well, and please report your outcome.

IRC Log: http://pastebin.com/f8fee9d9

Sincerely,
Jordan

Jordan Erickson (lns) wrote :

Also, here is a blog reference to 'fsync' in FF3 - which mmz (from the IRC log) mentioned might be part of what's going on.

http://shawnwilsher.com/archives/169

Kai Wollweber (wollw) wrote :

I have read the IRC log by Jordan. If I got it right firefox profiles over NFS may be part of the problem. This is not only a problem for those who use firefox as local apps but also for those who are working with multiple server setups as described in the Edubuntu Handbook [1]

I wanted to give "toolkit.storage.synchronous=0" a try, but I cannot access it via about:config in FF 3.0.1. Therefore I think, that it is no valid pref anymore.

[1] http://doc.ubuntu.com/edubuntu/edubuntu/handbook/C/multiple-server-setup.html

Jordan Erickson (lns) wrote :
Download full text (3.9 KiB)

I just updated the Bugzilla Bug 453704 ( https://bugzilla.mozilla.org/show_bug.cgi?id=453704 ) with new information I gathered while troubleshooting one of my problem labs this afternoon. Here is the text I posted there:

******
Ok - here's the scoop after being on-site and testing out a full lab (35
thin-clients) launching Firefox, with no current ~/.mozilla profile (I nuked
them all before testing), with and withOUT pref("toolkit.storage.synchronous",
0); set in /etc/firefox/pref/firefox.js (which will affect ALL users):

----------------------------------------------------------
'toolkit.storage.synchronous' pref NOT set): Running Firefox on local LTSP
server with no profile with the following command:

strace -f -e fsync firefox 2>&1 | fgrep fsync | wc -l

Rendered 99 counts of fsync.
---
'toolkit.storage.synchronous' pref SET): Running Firefox on local LTSP server
with no profile with the following command:

strace -f -e fsync firefox 2>&1 | fgrep fsync | wc -l

Rendered 28 counts of fsync.
---
'toolkit.storage.synchronous' pref NOT set): Running Firefox on local LTSP
server with existing profile (from above) with the following command:

strace -f -e fsync firefox 2>&1 | fgrep fsync | wc -l

And then opening up tabs for slashdot.org, yahoo.com and google.com:

Rendered 48 counts of fsync.
---
'toolkit.storage.synchronous' pref SET): Running Firefox on local LTSP server
with existing profile (from above) with the following command:

strace -f -e fsync firefox 2>&1 | fgrep fsync | wc -l

And then opening up tabs for slashdot.org, yahoo.com and google.com:

Rendered 24 counts of fsync.
----------------------------------------------------------

Ok. So now we have sort of a baseline of how the toolkit pref works for
fsyncing. Now what I did was simulated a full class of students coming in,
logging into Gnome, and, all at the same time, launching Firefox.

Instances of launching a full lab of thin-client firefox sessions, with NO
profile, were pretty different when 'toolkit.storage.synchronous' was set as
opposed to not. Without it set, we waited for about 15 minutes, and only about
1/2 of the thin-clients had launched Firefox. WITH it set, again, with new
profiles (I nuke them every time), it took about 5 minutes for all systems to
launch Firefox. Better, but still really really bad.

I used the following command on 3 different thin-clients to guage where firefox
was hanging. I saw a commonality through all of them - it would hang at this
point in the strace:

---
stat64("/usr/lib/xulrunner-1.9.0.1/components/nsWebHandlerApp.js",
{st_mode=S_IFREG|0644, st_size=6920, ...}) = 0
open("/dev/random", O_RDONLY) = 15
read(15,
---

RIGHT at the "read(15, " it would hang for 3-8 minutes before it proceeded
through and load Firefox. "15" was also "19" and "23" - not sure if this
matters. Sometimes it would proceed through and load the UI, sometimes it would
process a bunch more strace info and then hang on another "read(19, " line.
AND, it wasn't always right after the "nsWebHandlerApp.js" line - a couple of
other times it was here:

---
open ("/dev/random", 0_RDONLY) = 19
(read (19,
---

And it would hang.

AFTER launching the UI ...

Read more...

Jordan Erickson (lns) wrote :

Please see https://bugzilla.mozilla.org/show_bug.cgi?id=453704#c9 - regarding the use of /dev/random and entropy running out, causing all other entropy-consuming applications (such as other instances of FF3 creating and/or loading profiles) to hang and wait for entropy to build back up - which is presumably minimal on LTSP servers, as there is usually no local input events, as well as presumably little/no random input from LTSP clients (other than possibly network related, which I have been told is of minimal influence to gathering entropy compared to local input events).

There is a proposed workaround I have that I'll be testing tomorrow. I'll post my results.

Created attachment 339195
Patch

We've go several people reporting that iceweasel would freeze at startup on some appliances of the web kiosk kind that just boot up to iceweasel almost directly, until some mouse movements occur and/or keys are pressed. This is due to the fact that Linux's /dev/random uses mouse and keys to get some entropy, and /dev/random blocks when it doesn't have enough entropy. /dev/urandom is a (weaker) version that doesn't block. /dev/urandom is actually used in NSS already.

Anyways, I see two possibilities, here, one of which I am sending a patch for. Please tell me if you'd prefer the other approach.
- Use /dev/urandom on Linux (BSD variants have already a non blocking (weak) RNG on /dev/random)
- Use clock_gettime() to get a real high resolution clock response, but that would depend on the resolution (clock_getres()) ; high resolution clock is quite recent in linux iirc.

Changed in firefox:
status: Unknown → New

Comment on attachment 339195
Patch

This fix is good. We should make this change unconditionally,
rather than with #ifdef LINUX. Perhaps OpenDevRandom and
fdDevRandom should be renamed accordingly.

I'm more concerned about the code that's calling PR_GetRandomNoise.
The output of PR_GetRandomNoise should only be used to seed a
pseudorandom number generator (PRNG). PR_GetRandomNoise must not
be used as a PRNG directly.

Created attachment 339296
Patch v2

How about this ?

Comment on attachment 339296
Patch v2

r=wtc. Thanks.

Wan-Teh, I think there may be disagreement about whether or not the switch to
/dev/urandom should be made "unconditionally, rather than with #ifdef LINUX."

Mike, could you find the iceweasel code that calls PR_GetRandomNoise?
Unless it uses the PR_GetRandomNoise output to seed a PRNG, it is
using PR_GetRandomNoise incorrectly and it needs to be changed.

Nelson, in spite of the documentation
(http://developer.mozilla.org/en/PR_GetRandomNoise
http://mxr.mozilla.org/nspr/source/nsprpub/pr/include/prrng.h#53)
people use PR_GetRandomNoise incorrectly as a PRNG. In fact,
I doubt there is any code that uses PR_GetRandomNoise as intended
(to seed a PRNG). This is why switching to /dev/urandom is a good
solution.

(In reply to comment #6)
> Mike, could you find the iceweasel code that calls PR_GetRandomNoise?
> Unless it uses the PR_GetRandomNoise output to seed a PRNG, it is
> using PR_GetRandomNoise incorrectly and it needs to be changed.

See comment #2. (There are no differences between iceweasel and firefox introducing uses of PR_GetRandomNoise)

Anyways, please note that I'm waiting feedback as whether the patch really addresses the freezing issue.

There are three callers of PR_GetRandomNoise in the Mozilla source tree outside of NSPR:

1) Use of PR_GetRandomNoise in nsUUIDGenerator.cpp was discussed in bug 279521.
2) nsMetricsService.cpp uses the "noise" to stagger update requests randomly - it doesn't really care that the numbers might not be sufficiently random.
3) nsXFormsXPathFunctions::Random passes the return value of PR_GetRandomNoise to srand().

Mike, Gavin, thanks for finding the users of PR_GetRandomNoise.

Among them, only nsMetricsService.cpp is using PR_GetRandomNoise
incorrectly. It uses PR_GetRandomNoise directly to generate a
random 32-bit number.

The problem of using PR_GetRandomNoise as a PRNG is that the
output of PR_GetRandomNoise, although random, may not be
uniformly distributed. This is why we need to feed it to
a PRNG to "whiten" the output.

I can confirm the patch solved the freezing problem for the people reporting it. I don't know what codepath was used then, though.

And the code path leading to the freeze was through nsUUIDGenerator.

*** Bug 453704 has been marked as a duplicate of this bug. ***

Please also see bug 455829 (with 5 votes), as this seems to be a duplicate. A
patch would be greatly appreciated as it seems to affect LTSP setups on a
critical level (Firefox won't launch for *anyone* after 2-4 users launch it on
the network).

Heh, there IS a patch! Ok, I'll try and test it out.

Jordan Erickson (lns) wrote :

Please see new triaged bug https://bugzilla.mozilla.org/show_bug.cgi?id=455829 as the previously triaged bug became a duplicate of this one. The upstream bug report already has a fix. Not sure where to go from here - we have a fix, but what can we do to get this pushed into Ubuntu repos?

Kai Wollweber (wollw) wrote :

Jordan, did you prove that the patch is a solution for the given problem with firefox in LTSP?

Jordan Erickson (lns) wrote :

Wollow, I've got no experience with patching, or creating ubuntu packages based on patches...if anyone can assist, I would gladly install them and test at my sites.

Changed in firefox:
status: New → In Progress

I checked in the patch on the NSPR trunk (NSPR 4.7.2).

Checking in uxrng.c;
/cvsroot/mozilla/nsprpub/pr/src/md/unix/uxrng.c,v <-- uxrng.c
new revision: 1.22; previous revision: 1.21
done

Changed in firefox:
status: In Progress → Fix Released
Alexander Sack (asac) wrote :

the upstream bug is about /dev/random vs. /dev/urandom. anyone can confirm that /dev/urandom fixes this issue for them?

Added nspr task for the nspr fix linked here.

Changed in nspr:
importance: Undecided → Medium
status: New → In Progress

*** Bug 454313 has been marked as a duplicate of this bug. ***

Jordan Erickson (lns) wrote :

Ok - I noticed some Firefox 3 updates in Hardy, so I thought I'd re-'strace' it to see if it was using /dev/urandom instead of /dev/random. I can't verify that this "fixes the slowness problem" because I'm on my own LTSP server (only 2 clients attached) but to me, anyway, it looks like /dev/urandom is being utilized. I'm on Ubuntu 8.04.1, Firefox 3.0.5, latest Ubuntu package updates as of 2008/12/22, updated client chroot.

----
jerickson@Fibonacci:~$ strace firefox > trace.txt 2>&1

*Does some random browsing*

jerickson@Fibonacci:~$ ls -lh trace.txt
-rw-r--r-- 1 jerickson jerickson 11M 2008-12-22 14:58 trace.txt
jerickson@Fibonacci:~$ grep random trace.txt > strace.txt
jerickson@Fibonacci:~$ less strace.txt
*******************************************************************************
strace.txt
open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 10
open("/dev/random", O_RDONLY) = 20
open("/dev/urandom", O_RDONLY) = 27
open("/dev/urandom", O_RDONLY) = 40
stat64("/dev/urandom", {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0
open("/dev/urandom", O_RDONLY) = 40
strace.txt (END)
*******************************************************************************
----

Not only does it seem that /dev/urandom is being utilized now, but it seems that the number of times /dev/urandom is being accessed has been greatly reduced overall.

Please, everyone, do as much testing as possible so we can see if this issue is still present or not. I will test some of my own schools as soon as school is back in (around the 1st of the year).

- Jordan/Lns

Jordan Erickson (lns) wrote :

Another strace using a new profile (created during the strace) and some more random browsing shows the following:

----
jerickson@Fibonacci:~$ mv .mozilla .mozilla.orig
jerickson@Fibonacci:~$ strace firefox > trace.txt 2>&1
jerickson@Fibonacci:~$ grep random trace.txt > strace.txt
jerickson@Fibonacci:~$ less strace.txt

*******************************************************
strace.txt:
open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 10
open("/dev/random", O_RDONLY) = 15
open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 12
open("/dev/random", O_RDONLY) = 19
write(18, "@mozilla.org/security/random-gen"..., 80) = 80
open("/dev/urandom", O_RDONLY) = 25
open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 14
open("/dev/random", O_RDONLY) = 23
write(22, "@mozilla.org/security/random-gen"..., 80) = 80
open("/dev/urandom", O_RDONLY) = 34
open("/dev/urandom", O_RDONLY) = 50
stat64("/dev/urandom", {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0
open("/dev/urandom", O_RDONLY) = 50
strace.txt (END)
*******************************************************

HTH,
Jordan/Lns

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package nspr - 4.7.3-0ubuntu1

---------------
nspr (4.7.3-0ubuntu1) jaunty; urgency=low

  * New upstream version: 4.7.3 from NSPR_4_7_3_RTM tag

  [ Fabien Tassin <email address hidden> ]
  * LP: #269188 - use /dev/urandom for better entropy on LTSP environments
  * update diverged patches:
    - update debian/patches/30_pkgconfig.patch
    - update debian/patches/81_sonames.patch
    - update debian/patches/99_configure.patch

  [ Alexander Sack <email address hidden> ]
  Drop debian soname patch for full upstream compatibility
  * eliminate soname patch
    - delete debian/patches/81_sonames.patch
    - update debian/patches/series
  * refresh configure patch to reflect dropped soname patch
    - update debian/patches/99_configure.patch
  * install unversioned .so files
    - update debian/libnspr4-0d.install
  * .so.0d links are not created without the soname patch. we create
    backlinks to the unversioned .so libs using debhelper; also we
    cannot dh_install the .0d versioned libs anymore and we drop
    them from .install accordingly
    - add debian/libnspr4-0d.links
    - update debian/libnspr4-0d.install
  * implement link shuffeling transition (with abort cases) in
    maintainer scripts; affected libs: libnspr4.so libplc4.so libplds4.so
    - add debian/libnspr4-0d.postinst
    - add debian/libnspr4-0d.postrm
    - add debian/libnspr4-0d.preinst
    - add debian/libnspr4-0d.prerm
  * drop soname version suffix from symbol files and reflect this fact by
    adjusting minimum version to this package version (4.7.3-0ubuntu1~)
    - update debian/libnspr4-0d.symbols
    - update debian/libnspr4-0d.symbols.amd64
    - update debian/libnspr4-0d.symbols.i386
    - update debian/libnspr4-0d.symbols.ia64
    - update debian/libnspr4-0d.symbols.lpia
    - update debian/libnspr4-0d.symbols.powerpc
  * bump lower shlibs version constraint to 4.7.1+1.9-0ubuntu5~
    - update debian/rules
  * rerun autoconf2.13 to apply dropped 81_sonames.patch to configure
    - update debian/patches/99_configure.patch
  * explitly define libnspr4_0d_EXPORTED_LIBS and pass those manually
    to dpkg-gensymbols to workaround uncommon SONAME used by nspr libs
    - update debian/rules
  * don't pretend to create shlibs-control file anymore; add binary
    lintian override for that
    - update debian/rules
  * add #DEBHELPER# token to maintainer scripts
    - update debian/libnspr4-0d.postinst
    - update debian/libnspr4-0d.postrm
    - update debian/libnspr4-0d.preinst
    - update debian/libnspr4-0d.prerm

 -- Alexander Sack <email address hidden> Sun, 11 Jan 2009 13:50:07 +0100

Changed in nspr:
status: In Progress → Fix Released
Jordan Erickson (lns) wrote :

This is great news!! I am going to be visiting #ubuntu-testing to coordinate an SRU into Hardy, if possible. Thanks!

Kai Wollweber (wollw) wrote :

I just tested the bugfix as described by Jordan at http://lns.wikidot.com/nsprupdate and I am happy to say that we have no more delays on starting firefox.

My test was:
20 new users with no firefox profile are starting firefox simultanously in a LTSP environment from a single Server with Hardy 4.01.
Firefox comes up within 2 to 3 seconds at all terminals and no one has "firefox already running" messages.

Thank's alot to all having helped to fix this bug! Please put the SRU into Hardy.

Alexander Sack (asac) wrote :

not firefox bug.

Changed in firefox:
status: Incomplete → Invalid

Kai,

Thanks for the quick testing!!! This is making me smile from ear to ear.

Kai Wollweber wrote:
> I just tested the bugfix as described by Jordan at
> http://lns.wikidot.com/nsprupdate and I am happy to say that we have no
> more delays on starting firefox.
>
> My test was:
> 20 new users with no firefox profile are starting firefox simultanously in a LTSP environment from a single Server with Hardy 4.01.
> Firefox comes up within 2 to 3 seconds at all terminals and no one has "firefox already running" messages.
>
> Thank's alot to all having helped to fix this bug! Please put the SRU
> into Hardy.
>
>

--
Jordan Erickson
Owner, Logical Networking Solutions
http://www.logicalnetworking.net
707-636-5678

Latest LNS Blogs - http://blogs.logicalnetworking.net

 Intel and HP team up to roll out Green PCs for the enterprise
 Mozilla Thunderbird Add-on "Signature Switch"
 Will "Windows 7" be another Mojave Experiment?

Alexander Sack (asac) wrote :

targetted for hardy SRU

Changed in firefox:
status: New → Invalid
Changed in nspr:
importance: Undecided → High
milestone: none → ubuntu-8.04.3
status: New → Triaged
Alexander Sack (asac) wrote :

for hardy we need to cherry pick the upstream commit: https://bugzilla.mozilla.org/attachment.cgi?id=339296

Jordan Erickson (lns) wrote :

I can also confirm the updated nspr package from fta's PPA works, via directions I wrote at http://lns.wikidot.com/nsprupdate . I launched 27 FF3 instances from different LTSP terminals, after rm -rf'ing current user FF profiles. No delays, even when launching 1-2 seconds apart each (as fast as I could run from terminal to terminal in my computer lab) - very snappy response.

Thanks all!!!

john_s (lists-john) wrote :

I can also confirm this fix for 9 clients that were exhibiting the same symptoms. I installed ibnspr4-0d via the directions that Jordan posted on his site. As a admin trying to make the transition 1600 users to the current Ubuntu LTS PLEASE - we really need to see this added to the Hardy repo's so that others can benefit from this fix.

Thanks!

Alexander Sack (asac) wrote :

moving to my todo list.

Changed in nspr:
assignee: nobody → asac
status: Triaged → In Progress
Alexander Sack (asac) wrote :

can we live without this fix in hardy? if not, let me know and i will push this higher on my SRU worklist.

Jordan Erickson (lns) wrote :

Personally, I would love to see an SRU for Hardy. There are plenty of large LTSP installations that use only LTS releases (myself included). A fix for this would mean one of the very few remaining major roadblocks cleared for prime-time implementation.

I Agree with Jordan. We only run LTS releases here and a fix would be
very appreciated.

On 7/9/09, Jordan Erickson <email address hidden> wrote:
> Personally, I would love to see an SRU for Hardy. There are plenty of
> large LTSP installations that use only LTS releases (myself included). A
> fix for this would mean one of the very few remaining major roadblocks
> cleared for prime-time implementation.
>
> --
> Extreme slowness, "Firefox is already running" error for >3 users launching
> Firefox in LTSP environment
> https://bugs.launchpad.net/bugs/269188
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Changed in firefox:
importance: Unknown → Medium
Alexander Sack (asac) on 2011-01-06
Changed in nspr (Ubuntu Hardy):
assignee: Alexander Sack (asac) → Chris Coulson (chrisccoulson)
milestone: ubuntu-8.04.3 → none
Chris Coulson (chrisccoulson) wrote :

Is this still an issue in Hardy? All supported Ubuntu releases have the same version of nspr now

Changed in nspr (Ubuntu Hardy):
status: In Progress → Incomplete
Martin Pitt (pitti) on 2011-02-15
Changed in nspr (Ubuntu Hardy):
assignee: Chris Coulson (chrisccoulson) → nobody
Rolf Leggewie (r0lf) wrote :

Hardy has seen the end of its life and is no longer receiving any updates. Marking the Hardy task for this ticket as "Won't Fix".

Changed in nspr (Ubuntu Hardy):
status: Incomplete → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.