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.
--
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 member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
