Bug #269188 “Extreme slowness, “Firefox is already running” erro...” : Bugs : firefox-3.0 package : Ubuntu

Revision history for this message

Alexander Sack (asac) wrote on 2008-09-11:

#1

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

Revision history for this message

Kai Wollweber (wollw) wrote on 2008-09-12:

#2

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.

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.

Revision history for this message

Kai Wollweber (wollw) wrote on 2008-09-12:

#3

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.

Revision history for this message

Jordan Erickson (lns) wrote on 2008-09-12:

#4

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.

Revision history for this message

Jordan Erickson (lns) wrote on 2008-09-12:

#5

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

Revision history for this message

Jordan Erickson (lns) wrote on 2008-09-12:

#6

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

Revision history for this message

Kai Wollweber (wollw) wrote on 2008-09-13:

#7

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

Revision history for this message

Jordan Erickson (lns) wrote on 2008-09-16:

#8

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 ...

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 (finally), I saw (which might be completely normal) a
continuous cycle of the following in strace:

---
gettimeofday({1221521746, 829628}, NULL) = 0
read(3, 0x8075324, 4096)                = -1 EAGAIN (Resource temporarily
unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8,
events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=12,
events=POLLIN|POLLPRI}, {fd=13, events=POLLIN|POLLPRI}, {fd=14,
events=POLLIN}], 7, 0) = 0
---
It would hang at "poll( "and cycle through these messages.

You can find the 3 different workstations' strace logs, with and without the
toolkit pref enabled, here: http://logicalnetworking.net/other/ac/

I really hope this information helps. After seeing this happen with my own two
eyes, I have to say...wow.

Revision history for this message

Jordan Erickson (lns) wrote on 2008-09-17:

#9

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.

Revision history for this message

In Mozilla Bugzilla #455829, Mh+mozilla (mh+mozilla) wrote on 2008-09-18:

#10

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.

Bug Watch Updater (bug-watch-updater) on 2008-09-18

Changed in firefox:
status:	Unknown → New

Revision history for this message

In Mozilla Bugzilla #455829, Wan-Teh Chang (wtc-google) wrote on 2008-09-18:

#11

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.

Revision history for this message

In Mozilla Bugzilla #455829, Mh+mozilla (mh+mozilla) wrote on 2008-09-18:

#12

Doesn't seem to be much problem...
http://mxr.mozilla.org/firefox/search?string=PR_GetRandomNoise&tree=firefox

Revision history for this message

In Mozilla Bugzilla #455829, Mh+mozilla (mh+mozilla) wrote on 2008-09-18:

#13

Created attachment 339296
Patch v2

How about this ?

Revision history for this message

In Mozilla Bugzilla #455829, Wan-Teh Chang (wtc-google) wrote on 2008-09-18:

#14

Comment on attachment 339296
Patch v2

r=wtc. Thanks.

Revision history for this message

In Mozilla Bugzilla #455829, Nelson-bolyard (nelson-bolyard) wrote on 2008-09-18:

#15

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."

Revision history for this message

In Mozilla Bugzilla #455829, Wan-Teh Chang (wtc-google) wrote on 2008-09-18:

#16

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.

Revision history for this message

In Mozilla Bugzilla #455829, Mh+mozilla (mh+mozilla) wrote on 2008-09-18:

#17

(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)

Revision history for this message

In Mozilla Bugzilla #455829, Mh+mozilla (mh+mozilla) wrote on 2008-09-18:

#18

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

Revision history for this message

In Mozilla Bugzilla #455829, Gavin Sharp (gavin-sharp) wrote on 2008-09-18:

#19

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().

Revision history for this message

In Mozilla Bugzilla #455829, Wan-Teh Chang (wtc-google) wrote on 2008-09-18:

#20

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.

Revision history for this message

In Mozilla Bugzilla #455829, Mh+mozilla (mh+mozilla) wrote on 2008-09-19:

#21

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

Revision history for this message

In Mozilla Bugzilla #455829, Mh+mozilla (mh+mozilla) wrote on 2008-09-21:

#22

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

Revision history for this message

In Mozilla Bugzilla #455829, Jordan Erickson (lns) wrote on 2008-10-06:

#23

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

Revision history for this message

In Mozilla Bugzilla #455829, Jordan Erickson (lns) wrote on 2008-10-06:

#24

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).

Revision history for this message

In Mozilla Bugzilla #455829, Jordan Erickson (lns) wrote on 2008-10-06:

#25

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

Revision history for this message

Jordan Erickson (lns) wrote on 2008-10-06:

#26

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?

Revision history for this message

Kai Wollweber (wollw) wrote on 2008-10-06:

#27

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

Revision history for this message

Jordan Erickson (lns) wrote on 2008-10-06:

#28

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.

Bug Watch Updater (bug-watch-updater) on 2008-10-07

Changed in firefox:
status:	New → In Progress

Revision history for this message

In Mozilla Bugzilla #455829, Wan-Teh Chang (wtc-google) wrote on 2008-10-07:

#29

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

Bug Watch Updater (bug-watch-updater) on 2008-10-08

Changed in firefox:
status:	In Progress → Fix Released

Revision history for this message

Alexander Sack (asac) wrote on 2008-10-08:

#30

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

Revision history for this message

In Mozilla Bugzilla #455829, Bsterne (bsterne) wrote on 2008-12-03:

#31

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

Revision history for this message

Jordan Erickson (lns) wrote on 2008-12-22:

#32

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

Revision history for this message

Jordan Erickson (lns) wrote on 2008-12-22:

#33

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

Revision history for this message

Launchpad Janitor (janitor) wrote on 2009-01-11:

#34

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

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 <fta@ubuntu.com> ]
  * 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 <asac@ubuntu.com> ]
  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 <asac@ubuntu.com>   Sun, 11 Jan 2009 13:50:07 +0100

Changed in nspr:
status:	In Progress → Fix Released

Revision history for this message

Jordan Erickson (lns) wrote on 2009-01-12:

#35

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

Revision history for this message

Kai Wollweber (wollw) wrote on 2009-01-12:

#36

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.

Revision history for this message

Alexander Sack (asac) wrote on 2009-01-12:

#37

not firefox bug.

Changed in firefox:
status:	Incomplete → Invalid

Revision history for this message

Jordan Erickson (lns) wrote on 2009-01-12: Re: [Bug 269188] Re: Extreme slowness, "Firefox is already running" error for >3 users launching Firefox in LTSP environment

#38

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?

Revision history for this message

Alexander Sack (asac) wrote on 2009-01-12:

#39

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

Revision history for this message

Alexander Sack (asac) wrote on 2009-01-12:

#40

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

Revision history for this message

Jordan Erickson (lns) wrote on 2009-01-13:

#41

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!!!

Revision history for this message

john_s (lists-john) wrote on 2009-03-02:

#42

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!

Revision history for this message

Alexander Sack (asac) wrote on 2009-03-11:

#43

moving to my todo list.

Changed in nspr:
assignee:	nobody → asac
status:	Triaged → In Progress

Revision history for this message

Alexander Sack (asac) wrote on 2009-07-09:

#44

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

Revision history for this message

Jordan Erickson (lns) wrote on 2009-07-09:

#45

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.

Revision history for this message

john_s (lists-john) wrote on 2009-07-10: Re: [Bug 269188] Re: Extreme slowness, "Firefox is already running" error for >3 users launching Firefox in LTSP environment

#46

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.
>

Bug Watch Updater (bug-watch-updater) on 2010-09-17

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

Revision history for this message

Chris Coulson (chrisccoulson) wrote on 2011-01-23:

#47

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

Revision history for this message

Rolf Leggewie (r0lf) wrote on 2014-11-21:

#48

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

	Status	Importance	Assigned to
Mozilla Firefox	Fix Released	Medium	mozilla-bugs #455829
firefox-3.0 (Ubuntu)	Invalid	Undecided	Unassigned
Hardy	Invalid	Undecided	Unassigned
nspr (Ubuntu)	Fix Released	Medium	Unassigned
Hardy	Won't Fix	High	Unassigned

Ubuntu
firefox-3.0 package

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

Bug Description

Related branches

Other bug subscribers

Remote bug watches

Ubuntufirefox-3.0 package

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

Bug Description

Related branches

Other bug subscribers

Remote bug watches

Ubuntu
firefox-3.0 package