Closed Bug 135137 Opened 22 years ago Closed 11 years ago

Profile data cannot be shared by multiple running instances.

Categories

(Core Graveyard :: Profile: BackEnd, defect)

Product:
Core Graveyard
Component:
Profile: BackEnd
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX
Milestone:
mozilla1.4beta

People

(Reporter: jud, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: helpwanted, meta) 

Currently mutliple Gecko based (embedding for example) applications can not
share profile data such as cookies, cache, etc, while running simultaneously. As
more and more applications start using Gecko as their browser component, this
sharing capability becomes a necessity.

See http://www.mozilla.org/projects/embedding/shared_profiles.html for further
information.
Depends on: 135061
Depends on: 135062
Keywords: meta
OS: Windows 2000 → All
Hardware: PC → All
Some comments after reading
<http://www.mozilla.org/projects/embedding/shared_profiles.html>...

Different cache directories for each application would not be much of a step
forward. Apps can already get this by setting up their own profile directory
(indeed, that's what they do). Having apps be able to share a single cache (per
user) is a major usability win. Further discussion of this probably belongs in
bug 135061.

Prefs... IMO, the most desirable situation from a usability standpoint would be
to have Gecko prefs shared. Apps that don't want that can set up their own
profile directories and share nothing with other apps.
Blocks: 115903
Summary: Profile data can not be shared by multiple running instances. → Profile data cannot be shared by multiple running instances.
-> ccarlen
Assignee: valeski → ccarlen
Taking.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0.1
*** Bug 148102 has been marked as a duplicate of this bug. ***
Blocks: profile-corrupt
*** Bug 148509 has been marked as a duplicate of this bug. ***
Blocks: 148839
This means that the browser and mail now conflict with each other. 

This means that separate menu selections, scripts, or icons for "mozilla" and
"mozilla mail" no longer work independently, or consistently, depdending on what
else is running.

This means that naive users have to be told, "mostly, you can just click on this
to check mail, but if the browser is running, you have to do something
completely different" and "mostly, you just click on this to get to the web, but
if you've got e-mail open...". 

This means that users that are NOT used to having tabs can no longer just fire
off multiple sessions and cut-and-paste or compare, as they routinely do with
IE, for example.

This means that, now running mail and the browser as one session but in
different desktops, clicking on a link in an e-mail message will open the link
on another desktop, out of view rather than in front of the user.

If multiple windows are open in one session, and Edit-Preferences is selected in
each, it branches to one and only one copy of the preferences dialog. Is this
impossible across sessions?
No longer blocks: 148839
*** Bug 148839 has been marked as a duplicate of this bug. ***
This issue is especially bad for the common user on Linux/X, as programs like
KMail, etc., are used to ordering the platform browser to run with a given url,
in the expectation that either the running application will just open a new
window on the new url, or that the application won't mind multiple copies of
itself running.

It would be nice that if one ran 'mozilla', or 'mozilla-mail', that mozilla
would look to see if a browser instance was running in the same user account
with the same DISPLAY environment set, and if so, a signal would be sent to the
running instance so that it could open up the appopriate window.

I believe this is how it works on Windows now.  It would make this issue much
less objectionable on X Windows if we could get the same kind of behavior.
> It would be nice that if one ran 'mozilla', or 'mozilla-mail', that mozilla
> would look to see if a browser instance was running

Very true, but a separate issue (XPApps) If what you're talking about was done,
there would be less need for mozilla to be able to share a profile amongst
multiple instances. This bug is not about the behavior of mozilla, but being
able to share profiles for applications which really need to do this (not
nescesarily mozilla).
>>This bug is not about the behavior of mozilla<<

People reporting this issue as a bug in Mozilla's behavior have had their bug
reports rolled up (DUPME) into this one- or discarded (RESOLVED). Either action
apparently discards/disregards votes for the previous bugs that were so handled.
The brings up questions as to how accurately it's impact can now be judged.

If this bug is not about the behavior of Mozilla, perhaps this action was
inappropriate. Those people are now tracking this bug to see what the resolution
will be, if any.
*** Bug 154074 has been marked as a duplicate of this bug. ***
*** Bug 154875 has been marked as a duplicate of this bug. ***
Marking http://bugzilla.mozilla.org/show_bug.cgi?id=154875 as a duplicate of
this bug is, IMHO, misleading.

154875 is an issue that's been driving myself and several others I know up the
wall - we were all happily using RC2, without this behaviour, (although AFAIAW
all of us were fortunate never to have profile corruption problems), and
suddenly things have gone pear-shaped.

The reporter of bug 154875 sounds quite upset by it all, and I can see where
s/he  is coming from - all my window-manager shortcuts for opening browsers are
now broken without any apparent workaround (since they point to /..../mozilla),
and I have to keep paging through all my virtual desktops to find wherever the
heck the last remaining instance of EITHER a browser window OR EVEN a mail
window is hiding, and then Ctrl-N / Ctrl-1 off that window.

I wouldn't mind at all if someone (anyone?) had proposed a workable workaround,
but for now it seems my only option is to downgrade to RC2, or stop using
Mozilla altogether (if you think this is OTT, then think how much time is wasted
paging through 9 virtual desktops almost every time you want to open a new
browser window!)

HOWEVER, marking 154875 as a duplicate hides this entire problem.  I read this
bug report first (135137) and decided it was a different problem. It was only by
noting Robert West's comment (#10), and reading all the dupes that I realised it
was now officially the same bug. (!).
See also bug 122698, "Detect [and use] currently running instance of Mozilla
when app is launched a second time".  Several of the dups of this bug are really
dups of 122698.  It's probably easier to fix bug 122698 than it is to fix all
profile-corruption and other dataloss bugs that crop up when two instances try
to share a profile.
OpenOffice.org(OOo) integrates with mozilla. Please see:

http://www.openoffice.org/issues/show_bug.cgi?id=6391

What interests me here is the Mozilla Address Book integration with OOo. This is
a readonly access by OOo. But following the fix for bug #76431, it is no longer
possible to simultaineously run the Browser and access Mozilla Address Book data
from within OOo. 

The reason for adding this comment is two fold, one to draw attention to the
effect of this on 3rdparty products such as OOo and secondly to support the
requests for the ability to support a readonly access to a second instance in
the spirit of 4.x. 
*** Bug 160026 has been marked as a duplicate of this bug. ***
*** Bug 160402 has been marked as a duplicate of this bug. ***
changing component, since this deals specifically with the work needed to make
profiles accessible by multiple processes. adding the nspr
semaphore/memorysharing bug as a blocker
Component: Browser-General → Profile Manager BackEnd
Depends on: 160724
Please don't forget to take into account multiple instances running on SEPARATE
machines using a common NFS mounted home... I'm not sure if that is a separate
issue or not. If it is, I could not find it.
gconf uses a technique that the first instance is opening a port on which the
other instances from the same user can connect to. only the first instance use
the files directly (better: write them).
i think this technique is not bad, because the normal way is that the profile is
located in a networkwide lan where ports can opened and connected in them.

if the first instance of the application dies, another becomes the writer instance.
Blocks: 158454
I would like to help this work on Mac OS 9. To do this, I need a description of
the proposed shared profile architecture. I have not yet found such a
description in this or related bugs, or at
http://www.mozilla.org/projects/embedding/shared_profiles.html , which describes
the problem but not the solution.

Mac OS 9 has an IPC mechanism and with this information I will be able to
provide assistance in using it for this job. Thank you.
I'm working on a tech spec right now, and when it is coherent enough to post for
comments I'll post it, uh, somewhere ( probably newsgroups and m.o ). It will
only outline the preferences work, but the architecture is one we hope to be
able to leverage to share the other profile data.
Can anyone tell me the difference between bug 122698 and this one. I was very
disappointed to find Mozilla falling back to bug 122698 when upgrading from 1.1b
to 1.2a. Why wasn't the patch mentioned in 122698 included in the new
run-mozilla.sh?
bug 122698 deals only with start up behavior. This bug deals with the ability to
run multiple programs that all use mozilla, more specifically gecko, as a
rendering engine. 

bug 122698 doesn't want to "share" the profile data between apps, it just wants
to check for a currently running version of mozilla and open a window from that
process. The bug aims at allowing two or more processes, like chimera and
phoenix and netscape, to run at the same time on the same profile without
profile corruption, deadlocks, or any other Bad Stuff(tm).

Docs have been posted(or rather links to m.o) to the n.p.m prefs,xpcom,&
embedding as well as posted at
http://www.mozilla/org/projects/embedding/profileSharing/index.html that talk
about the design we are working on for sharing the profile data.
Might it be possible to have an interim 'solution' that would keep both sides
happy? 

For sites where Mozilla is used by technically unsavvy users, the prompt to 
setup a new profile leads to headaches for support staff, and everyone I've 
asked would settle for a message that says "Close the other Mozilla first" 
instead of the new profile setup prompt.

Another solution would be a simple prefs.js setting to disable the locking. 
Those of us following this and related bug reports that have a problem with 
the new locking behaviour are fully aware of the risk of profile corruption 
and yet are willing to take that risk (primarily because the alternative 
really isn't an alternative), and a means to disable it would make us happy
campers again.
Depends on: 178806
*** Bug 184913 has been marked as a duplicate of this bug. ***
Cyrus,

rm -f ~/.mozilla/profilename/wierd-dirname/lock

I'm keeping that command in my mozilla script until they figure out how to fix
the problem correctly.
Here is the workaround I came up with:

#!/bin/sh

#URL TO OPEN
URL=$1

#MOZILLA REMOTE COMMAND
COMMAND="openurl("$1",new-tab)"
#COMMAND="openurl("$1",new-window)"

#CHANGE DIRECTORY TO MOZILLA
cd /usr/local/mozilla

#SEARCH FOR MOZILLA WINDOW
xwininfo -root -tree | grep -q -s phoenix
RETVAL=$?

if [ $RETVAL = 0 ] ; then
  ./mozilla -remote $COMMAND
else
  ./mozilla $URL
fi
*** Bug 185367 has been marked as a duplicate of this bug. ***
*** Bug 185586 has been marked as a duplicate of this bug. ***
Depends on: 185706
*** Bug 186498 has been marked as a duplicate of this bug. ***
*** Bug 190718 has been marked as a duplicate of this bug. ***
*** Bug 191179 has been marked as a duplicate of this bug. ***
*** Bug 192572 has been marked as a duplicate of this bug. ***
The bug I reported, Bug 190718, is *not* a duplicate of this bug -- far from it
-- in most respects it seems almost the opposite.

My problem is this:  In Mozilla 1.1 (Mandrake 9.0) when any portion of Mozilla
crashes, all my open Mozilla tabs and windows close.  (Since it is not untypical
to have 150 tabs open spread across 15 or so Mozilla windows, and some of those
windows may have open "text boxes" for editing TWiki pages, I lose a significant
amount of work and context.)

It seems no matter how I open Mozilla, only one instance is created.

In one of the comments above it is stated that this is how applications in
Windows behave.  It is not, at least as of Win95, and if it has changed it is a
change for the worse.  The truth is that in Windows there are ways to open new
copies of an application so they are new windows/tabs of the same instance and
there is a way(s) to open an application so a new instance is created.

In Windows (95), if you open a new application window by entering the
application name on the command line, clicking the icon, or clicking on the
start menu entry, you get a new instance of the application that shares nothing
with the previous instance.  (Well, that statement may be a little too strong --
it presumably shares the preferences and things like that.)  The point is, a new
instance of the program is created, and if some other instance of the program
crashes, this new instance does not crash (unless the crash kills all of Windows).

On the other hand, if you go into an open window or tab of a running instance of
a program and click New (or Open??), you create a new Window or Tab that is part
of the existing instance.  If something happens to cause a crash of this new
window, all open windows and tabs that are part of this instance close, but
those that are part of some other instance remain open and functional.

IIUC some other people are pushing for improvements or changes to the single
instance behavior.  My bug (RFE) is requesting that there be a means to create
multiple instances.

Is it clear?

If so, I think somebody needs to rewrite some bugs or create some "meta bugs" to
properly collect the votes.  (Note that the two behaviors I describe above are
not mutually exclusive -- there should be a means to do both, and at least
knowledgable users should be aware of how to do both.)

I will now basically paste these same comments into bug 190178 and attempt to
reopen it.  Please don't close it as a duplicate of this bug again -- perhaps
there is some other bug that it is truly a duplicate of, but it's not this one.

Or, another way of saying what I'm trying to say -- the writeup on this bug
135137 is so confusing, it's hard to tell what it is about.  If my bug truly is
a duplicate of this bug, this bug needs to be rewritten (a new "meta bug") very
clearly, and all the comments to this bug (135137) that confuse the issue need
to be discarded.

Randy Kramer
*** Bug 190718 has been marked as a duplicate of this bug. ***
No longer blocks: profile-corrupt
*** Bug 105181 has been marked as a duplicate of this bug. ***
*** Bug 111070 has been marked as a duplicate of this bug. ***
Setting to milestone that's not passed.
Target Milestone: mozilla1.0.1 → mozilla1.4alpha
Randy,

There's no guarantees under Windows whether you get a new process or same the
process.  It's up to the application developer.  If they don't do anything
special, you will get multiple processes.  What changed with Win95 (well, Win32)
was that the HANDLE to the previous instance was no longer passed to WinMain, so
application developers had to start using named mutexes, or named pipes or
FindWindow if they wanted to have one process only.  Try launching Word multiple
times, you will not succeed (Office XP at least).

Explorer/Internet Explorer is an interesting case.  It has an option in its
preferences dialog to run multiple processes.  This is the first thing that I
enable when I sit down at fresh installation/new user environment.  The stupid
default of having it disabled will mean the shell dies whenever a crash occurs
in another window.  Anyway, IE allows multiple processes, which is vital IMHO
considering how often I make it crash.  Some of the shared data is accessed
through separate singleton processes, like the Protected Storage service that
originally came with IE4.

I would really like to see the ability to launch Mozilla in multiple processes.
 This will make it more reliable and more useful.  Concurrency of the shared
data is going to be a problem though.  Do we have something in the toolkit that
allows interprocess communication on all the Mozilla platforms?  E.g. a CORBA
based profile/configuration service/daemon would be very useful.
Randy, 

I suspect that the reason why your RFE was made a dup of this one is because
this bug needs to be resolved before your RFE can be tackled. (In that sense, it 
should be 'depends on' this bug, not a dup of it).

Malcolm,

the reason why the HINSTANCE of the previous instance of an application is not
passed to other instances is because HINSTANCE is a win16 thing. In Win16
HINSTANCE is the selector of data segment. Under win32 that selector would be
meaningless since each application has its own descriptor table (unlike under
win16 where _all_ win applications share one descriptor table, ie run in _one_
memory space).

When you start a new instance of Mozilla under Windows, it looks for an existing
instance, and if found, sends that instance a message to open a new window - not
unlike what happens when select "File" -> "New Window". After posting the
message the new instance exits. 

There is nothing unusual about this - quite a few applications do it including
Word and IE. 

If Moz were to continue as a separate process, it would run into the profile
sharing issues that this bug is all about.

> Explorer/Internet Explorer is an interesting case.  It has an option in 
> its preferences dialog to run multiple processes. 

It does not run multiple processes in the traditional sense of a separate
process. It runs its message loop thread in a separate process (the window, 
and only the window, is in a separate process). The window classes, as well 
as all data that is not window-specific is in shared memory space. This is
somewhat analogous to creating new processes with the rfork(RFMEM) syscall 
under BSD or clone(CLONE_VM) under Linux - bad code in one process will kill
that, and only that, process, but that does not mean that all siblings are
immune to corruption of (shared) mem. If Explorer/IE truly ran one entirely
separate instance per window, every instance of an Explorer/IE window would be
using several megs of memory.

Enough off-topicness for today. :)
-> 1.4b
Target Milestone: mozilla1.4alpha → mozilla1.4beta
*** Bug 200803 has been marked as a duplicate of this bug. ***
Blocks: 213274
I second Nye Liu's comment #19 - this needs to work both when additional
instances of an application are started on a given machine (or when another
application like Evolution or KMail or whatever says something like "mozilla
http://www.mozilla.org"), and if the same user starts Mozilla on another machine
in an NFS environment.
Depends on: 217538
Security databases (cert/key) are part of the Mozilla profile data, and were
forgotten in this bug. I created bug 217538 to track this problem, and added a
dependency.

*** Bug 216437 has been marked as a duplicate of this bug. ***
*** Bug 222661 has been marked as a duplicate of this bug. ***
Does anybody know the current status of this work?
kyle: i think work on this bug was suspended when AOL decided that it no longer
had use for gecko.  AOL was the major driver behind this feature.  that said,
there is talk at the Mozilla Foundation about resuming work on this feature.
The problem with most workarounds I have seen is this:  
  
Starting a new window using the remote features does not allow you to log into  
the same site twice using different credentials. What if you want to log into  
phpMyAdmin for example using two different usernames? Because Mozilla shares  
the session cookie between all browser windows in the same process, this is  
impossible. The only solution is either use two different browsers or be forced to  
use different profiles.   
  
Frankly, every single browser besides Mozilla and clones can seem to figure this  
simple issue out, so why is Mozilla's team so half ass backwards? IMHO, Firebird  
is the best browser for Linux by far, but this one issue cripples it so bad that I am  
usually forced to use an inferior browser just so I can have uninterrupted work.  
  
  
*** Bug 230944 has been marked as a duplicate of this bug. ***
*** Bug 244450 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
Blocks: 250856
No longer blocks: majorbugs
*** Bug 253946 has been marked as a duplicate of this bug. ***
hi malcolm 

internet explorer has two possibilities to get multiple processes:
1. click on the normal start icon starts a new process,
   doing "new window" in an existing window uses the same process
2. enable the option "every window in a new process"
   then even open in a new window ends up with a new process
   probably the way you described it.

i never succeeded in clicking on the normal start icon without creating a new
process.

but in general i find this behaviour elegant ... somehow it seems to me that
other applications might have some code in it to look if there is already a
running instance of that application and and tell that instance to create a new
window with the new contents. it seems internet explorer is just not doing that,
so i believe strongly it is programmed like that and you cannot switch it off.

this means:
- you can log in multiple times (with one instance)
- one instance of internet explorer instances crashes
  with all its windows, no other instances affected

firefox by contrary looks for an existing running instance.

Is it true that other browsers only have one user profile for a given user
login, whereas Mozilla/Firefox can have several?
*** Bug 315194 has been marked as a duplicate of this bug. ***
To me it's not obvious what the idea is behind this Profile selection dialog when starting a second instance of Firefox. Maybe there are some reason for that.
But when starting Firefox on another X display presenting this dialog is annoying and useless. It's even more annoying when started with '-P default'.

> But when starting Firefox on another X display presenting this dialog is
> annoying and useless.

It's worse than that.  It's anti-productive.  I frequently have several logins on several different Linux boxes, sharing my home directory via NFS/automount.  But I can only have Mozilla/Firefox active on ONE of those machines.  So I have to track down which machine it's running on, terminate that session, and then I can run it on the one I need to.

Ugh.
A way to solve this problem would be to do display migration (e.g. with "teleport" -- I've never used it though). But does Firefox support it?
> A way to solve this problem would be to do display migration (e.g. with
> "teleport" -- I've never used it though). But does Firefox support it?

a) that's not a real fix... maybe I want separate instances
b) this is a problem on Windows as well
Firefox 1.5 "Deer Park" compiled from source. Cannot start second Firefox if there is a first one already running with all its windows visible only on X server on _another machine_.

I read all the comments. Fixing this will require transaction-like safe updates of profile data...
To clarify: "can't start" looks like this. Second instance of ff 1.5 says:

"Firefox is already running, but is not responding. To open a new window, you
must first close the existing Firefox process, or restart your system. [OK]"

soon (~3 seconds) after I start it.
This is still a pending issue. The last comment from the person, who the bug is assigned to (Conrad Carlen), made the last comment 3 years ago.

Conrad: If you are still interested (and actually the right person to handle this), please can you give us an update on the issue?

If not, can someone reassign the bug? Maybe to the QA team.
Assignee: ccarlen → nobody
Status: ASSIGNED → NEW
Flags: blocking1.9?
I hope this assessment isn't too immature. Wouldn't it be possible [and not difficult] to have the preferences read in and then the file handles dropped? This would mean that when changes are made, the entire file has to be read back in, modified, and saved [to prevent forking], and the handle dropped again.
This might be mozilla2 fodder, but it's not going to make 1.9 (and we probably wouldn't even take a patch if it were available).
Flags: blocking1.9? → blocking1.9-
Keywords: helpwanted
No longer blocks: 250856
I wonder how Konqueror does this. This has just always worked in it, at least for me (and this is a major reason for me to use Konqueror as my primary browser, but it doesn't _always_ work quite as well as FF). Might be that they use some strange KDE glue though, like a single process that manages the files and the other processes just communicate to it somehow, although this also seems to always have worked over NFS so I wonder.
What is the problem of just picking up the advisory locking stuff from the shared filesystem. I dont know i Windows-things supports this, but NFS does and other programs use this to avoid writing to the same files at the same time. 

Nice.. easy soloution.

... admit it .. but nearly any other application works flawlessly when running multiple instances in the same $HOME under NFS. 

Jesper
So what should FirefoxB do when FirefoxA has the history file locked and it wants to update it?  Queue those things for later?  Block the UI?  How should it communicate to the calling code that the write it wanted didn't really complete?  How to keep other code in that app from reading stale data?

We could litter our code with O_NONBLOCK/WOULDBLOCK checks, but that is neither easy nor nice.  I don't know of other applications that store profile-like data as frequently as we do (browsing history), and manage to not interfere with other instances.  If you can point us at some, we might be able to adapt their techniques.
First it would be nice to have a feeling about the magnitude of this problem. The situation you describes above will only (as far as I can see) when:
1) FirefoxA "forgets" to drop its lock, when it is done updating the file. 
or
2) When a user actually are using several different physical terminals at the same time.

1) Would be a bug.. 2) might happen but the locks should only be held while doing changes to the files, so even here, the chanches of a "collision" is fairly rare. 

By checking ctime on the files, other firefox instances may be able to look for changes in the files done by others.

Example code could be SQLite3 that supports running different processes updating and accessing the same file, safely changing them under concurrent load.  (They have a big nice warning about broken NFS-locking on their webpage). Gnome seems to rely on NFS-filelocking that works, but given the number of NFS-servers and clients out there, there may be broken combination among. (but that is not really firefox's problem). 


Jesper
(In reply to comment #75)
> Gnome seems to rely on NFS-filelocking that works, but given the
> number of NFS-servers and clients out there, there may be broken combination
> among. (but that is not really firefox's problem). 

That's a nice theory, but are you going to answer all the fan mail we'd get when people hit that bad combination of software and their profile data gets corrupted?



It should be possible to test for broken NFS locking somehow.  Are there really still a significant number of broken NFS implementations out there?  In any case you could use alternate (albeit less efficient) locking mechanisms if necessary.

Realistically I don't think finding a locking mechanism is the biggest problem.  I'd think it would take a massive code review to identify all the places where the code assumes it has exclusive access to the profile, and there are likely to be cases that require major changes to fix.  (Remember we're not just talking about preferences and bookmarks here, it's also the cache, extensions, and I don't know what else.)

How about locking the bookmarks and stored logins separately from the rest?

If I ssh to a box and run mozilla, it can create another history and cache for my new session if it likes.
Well.. Simple thing would improve the situation for "most users". 

1) A good global lock on .mozilla (just a lock file) that would just be activated whenever writing to a file.. and remove after. (actually letting parallel firefox-instances start up). Throw a big nice warning if it hits the point. 

2) Show the hostname of the host the "other" running firefox is on in the dialog that pops up. (allowing me to go directly to the workstaion and shutting it down). 

Remember that status at the moment is that it is just not possible to start firefox as the same user at 2 different NFS-clients. 

1) Would work flawless for people moving around between different clients, since the lock would actually only be held by the firefox running "active". 

.. then it could be improved subsequently ..


I don't think it's that easy, but if it is you could write a prototype patch and some tests, and prove me wrong.  I like being wrong about stuff like this!

There are a lot of broken NFS impls out there still.  And AFS.  History and bookmarks are in a unified store (key to a bunch of great features in FF3), so splitting them is non-trivial.  Users can run multiple copies on different profiles, and a simple cp -r of the profile should suffice if you want to go there.

If nothing else, without a good set of tests for such sharing, I'd be reluctant to take such changes into the tree -- it's an uncommon scenario that wouldn't get good ambient test coverage, and breaking it would result in user dataloss rather than user inconvenience.

If such things are important to a decent number of people, especially those who are on Unix environments and therefore more technically adept than average, I would expect that someone with such environments to hand could write some good automated tests, and then on that basis a patch to decouple or lock or whatever.

(Tweaking a lock file around every write sounds like a performance disaster to me, but without a patch to test we're just throwing guesses around.  Yours are based on your knowledge of your own environment.  Mine are based on total ignorance of that environment, but a decade of experience with this profile code and our file layer.  Only code can break the tie. :) )
(In reply to comment #75)
> First it would be nice to have a feeling about the magnitude of this problem.
> The situation you describes above will only (as far as I can see) when:
> 1) FirefoxA "forgets" to drop its lock, when it is done updating the file. 
> or
> 2) When a user actually are using several different physical terminals at the
> same time.

Scenario 2 is pretty common at our site, where a we have a large number of Linux compute boxes that people ssh into from their desktop box (which may be running Windows or Linux).  They launch Firefox on the compute box in order to view local (to the compute box) generated html reports.  Firefox may be launched from the command line, or from a button (like "View Logs") in another GUI tool.  With the current Firefox implementation, before launching users have to either (a) make sure no other instance of Firefox is running on some other box, and/or (b) copy the html files to an NFS or Samba shared directory and use an already running Firefox.  This adds a lot of friction to a process that people feel ought to be very simple.
(In reply to comment #74)
> We could litter our code with O_NONBLOCK/WOULDBLOCK checks, but that is neither
> easy nor nice.

You knew the job was dangerous when you took it, Fred.  :-)

>  I don't know of other applications that store profile-like data
> as frequently as we do (browsing history), and manage to not interfere with
> other instances.  If you can point us at some, we might be able to adapt their
> techniques.

I'm not sure how KDE's konqueror browser handles this situation, but it does seem to handle multiple instances running on different machines pretty well.  It might be worth checking out.
> So what should FirefoxB do when FirefoxA has the history file locked and it
> wants to update it?  Queue those things for later?  Block the UI?  How should
> it communicate to the calling code that the write it wanted didn't really
> complete?  How to keep other code in that app from reading stale data?

By designing your data store to be as nonblocking as possible.

Compare mailbox (one huge file with all your mails glued together)
and maildir format.

In mailbox, deletion of one email is a blocking operation - you must
prevent other processes from sseing half-updated file, and it also
may take arbitrary amount of time (think 2GB mailbox).

Zillions of mails stored in maildir directories can be read, written,
moved, deleted etc concurrently by any number of independend processes,
even from different machines! All what is needed is atomic rename().

I agree that relying on locking is a bad idea.
Networked filesystems+locking => bugs, bugs, bugs, bugs, bugs.

I appreciate the network file system issues here, but I just want to bring up a simpler case where this problem rears its head.  

In my case I am logging into the same machine either locally, or through various VNC connections.  This causes the frustrating situation of a firefox running on display :0 preventing me from running a firefox on VNC :1 or :2, etc.  That means I have to do the "killall firefox && killall firefox-bin" dance every time I try to run firefox from a different login.

Konqueror does not seem to have this problem.

In this case, there are no NFS or such issues.  All of the files are local. 
(In reply to comment #84)

> By designing your data store to be as nonblocking as possible.

That of course is the problem.  The data store in this case has already been designed, and it wasn't designed with multiple simultaneous access in mind.  Redesigning the data store would potentially affect every single line of code in the entire project, as far as I can see; it's just too big a change.

Of course I don't want to discourage anyone from trying to find a clever solution.  It would be great if this could be done, I'm just not optimistic.

Perhaps an emulation layer could present most of the code with what looks like a classic profile with exclusive access while actually managing simultaneous access, maybe on a copy-on-write basis?

An initial implementation might provide limited functionality (along with a warning message) for additional instances, e.g., bookmarks, history and preferences won't be remembered; I think it would still be useful, and improvements could then be made incrementally.

Seems to me that the problem is not the local file system, but network ones (nfs, afs, smbfs, cifs, etc), so why not break the problems in two?

firefox detect if the profile file system is a local fs or a network one and then:

if local, doesnt create the lock, uses the sqlite for multiple access browsers. before writing, check for the lock flag... set a minimun check interval for 10s to avoid too many checks. If lock detected, place a flag somewhere in the gui or give a warning that is running read only. this "read only" mode is the limited functionality Harry (comment #86) said.

if network file system, use the current lock system, and would block any other  running instances after 10s, allowing the "network based" firefox to run and the other to run "read only"

if lock already exists, uses the current implementation: dont allow a new instance. Even better, allow the running, again, in "read only" mode

later we could allow a "take over" button, that on user decision, would allow a "read only" instance to take over the flag and start to write (again, after the 10s checkout). the take over would warn that even if several instances are running, only the "active" one could write data.

isnt perfect, but i'm sure would be enough for most people around here. the local instances would allow a user to run several browsers instances, to avoid one crash to take over all open browsers or running different version of the browser.

the network code would allow the same user to roamming machines and still have
access to the their browser.

the only problem i see is the crash recovery, but that might be another war... :)


I agree with #85. While the NFS use case may be relatively uncommon, X was _designed_ so that I can run an application remotely. In case of browsers, I really do that quite often, ssh to my box and run the browser. No NFS. I can't believe this is an uncommon thing to do (and just look at the number of Cc:s to this bug). And this is one of the main reasons why I use Konqueror, because it works as I'd expect any software to: Not break when run both locally and remotely at the same time.

I could live with separate caches and anything else for the instances, but the one thing I'd want above other things is shared bookmarks.

I don't want to sound like I'm flaming, so sorry if it sounds like that, but I can understand how this requirement is foreign to Windows users; however the fact that I can't do this is the single most obvious non-unixism in FF. It really gives the impression FF was designed for Windows and the Unix port is just a hack to get it mostly working (and I can't blame even if it was so, since the Windows market is obviously bigger by an order of magnitude; however it makes me want to resort to some other browser that I feel is designed for the needs of a Unix user).
> Seems to me that the problem is not the local file system, but network ones
> (nfs, afs, smbfs, cifs, etc), so why not break the problems in two?
> 
> firefox detect if the profile file system is a local fs or a network one and
> then:
> 
> if local, ...
> 
> if network file system, ...

Filesystems are supposed to abstract backing store. If you are trying to "find
out whether filesystem is networked", you are doing something wrong. What next?
"Does my filesystem sit on SATA disk made by Samsung?"

Just act as if your filesystem is always networked (i.e., do not use flock()
locking, use lock files and/or atomic renames).

Apart from this, I like the proposal to make second firefox run in some sort of
"read only" mode.
(In reply to comment #87)

> [...] If lock detected, place a flag somewhere in the gui
> or give a warning that is running read only. this "read only" mode is the
> limited functionality Harry (comment #86) said.

Don't be misled into thinking this is easy.  The second instance would still need to have access to a consistent profile (whether real or emulated) and to be able to write to it, even if the changes will later be discarded when the instance exits.  This requires a fundamental change to the way the profile is stored on the disk; all an emulation layer might achieve is to help reduce the effort involved in modifying all the existing code that makes use of the profile.

This may be foreign to home Windows users, but there's an awful lot of us using Windows in networked office environments, where our home drives are on network shares, and our profiles are roaming.

In this situation leaving yourself logged into your main PC with Firefox running, and then logging into another machine on the network (as the same user) and trying to open Firefox gives the same message ("Firefox is already running, but is not responding. To open a new window, you must first close the existing Firefox process, or restart your system.").

Please don't go down a Unix-only path for fixing this...
i agree that the detection of the file system type is a hack, but breaking the problem in two would help local instances, full features with multi-instances in little time. reducing all to the network FS way will take more work and so longer and with reduced funcionality. 

If later the network soluction is good enough, we could remote the "local FS" hack... of course, this is just a opinion, even more as i'm not a developer, my programming skills are very basic  :)


for Comment #90, of course there is a need for some sort of extra layer for the read-only mode, my idea is not block all writes, but not update the "Real" profile (and so any change is lost in the end).

my idea is, when the the profile is locked, to copy the needed files (or use a copy-on-write) to a new dir (say a folder named ip-data-time) and work over there, write and read...  In the end, we could drop that folder and lose any changes.


i got another 2 ideas that might be used or not with the above idea

-sockets!! why not create a socket in the first instance and new instances would ask the first one to do the updates in their name... if needed, fork a small daemon to keep the process that do the writes simple and reliable way.
This could be the extra layer talked about.
Of course windows could be a problem, but cygwin had solved someway...

-there are several software that do the sync of several parts of the profile to a web location... why not take that idea and apply it locally?

we know the original state, the know what changed in each instance, so do a "diff" (or list actions done, no need to do a real diff) and place it in some "queue" dir with some kind of serial number.

when the normal (non-locked) instance start, would read that queue dir and try to apply the diffs/actions to the profile...
...as it was said before, bookmarks and maybe passwords and cookies are the most important things to try to keep from locked instances, all remaining probably arent worth the trouble

(In reply to comment #92)

> my idea is, when the the profile is locked, to copy the needed files (or use a
> copy-on-write) to a new dir (say a folder named ip-data-time) and work over
> there, write and read...  

Probably not adequate because the profile is in use when the second instance starts, and so is not necessarily in a consistent state.  The second instance needs to be able to reconstruct the profile as it was when the first instance started, or preferably as it would be if the first instance were to finish.

(Arguably this is no worse than the case in which Firefox crashes or is terminated leaving the profile potentially inconsistent, so the risk might be tolerable.  However it would make it more difficult to progress the solution beyond the most primitive level.)

> -sockets!! why not create a socket in the first instance and new instances
> would ask the first one to do the updates in their name...

Wouldn't work in general across machines because of firewalls, and wouldn't really solve the underlying problem that each instance would (potentially) get confused by the changes the other was making.  A more straightforward solution of this general class would be for the second instance to be a remote window of the first instance.

there is a simple way of workaround it... make the first instance also copy-on-write, leaving a consistent profile and do a move/rename in the end of session. This with the a folder with the other instances actions would solve most of the problem for network people

in a manual way, this is what people really do, when we have the profile locked, we create a new profile and copy the bookmarks. we use the new profile and when needed, we copy the changes to the old profile
> in a manual way, this is what people really do, when we have the profile
> locked, we create a new profile and copy the bookmarks. 

yep. Indeed thats what I do too (copy on login, copy on logout).

May I suggest using a simple redirection mechanism that simply modifies calls to open(filename) to something like...
  #1) Is there a temp copy of 'filename' yet? If not, copy over to 
      tmp_profile dir.
  #2) Change open("filename") to open("tmp_profile_dir/filename") 
Then, when the last instance of ff closes, move the changes to the original profile directory. No synchronization necessary, last man wins. Even this caveat would be immensely more acceptable to admins than the current state of affairs. It would be to this admin anyway. :)

The "which directory should it be" question is resolvable by either using tmp (IIRC, FF is already using LocalSettings/AppData/<whatever> under win), or by using a "virtual" disk, i.e. memory, and letting the OS figure out where to page.
Blocks: 260107
Flags: wanted1.9.1?
Flags: wanted1.9.1? → wanted1.9.1-
This script resolves most of the problems associated with this stupid bug for me, while it doesn't fix the bug it does make using firefox on several machines sharing the same filestore possible without feeling like you have to throw the computer out of the window:

#!/bin/sh
HN=`hostname`

echo hostname set to $HN
if  test -e ~/.mozilla/firefox/lock_host ; then
        LM=`cat ~/.mozilla/firefox/lock_host`
        echo Firefox has taken a lock out on the following machine:
        cat ~/.mozilla/firefox/lock_host
        if test $LM = $HN ; then
                echo Running a repeat firefox
                /usr/bin/firefox
                exit 0
        else
                if kdialog --yesno "Firefox is locked on machine $LM \n Do you want me to kill it?" ; then
                        echo OK I got a YES
                        ssh -o "StrictHostKeyChecking no" $LM "killall -regexp firefox"
                        kdialog --msgbox "Now try again"
                else
                        echo Ok I got a NO
                        exit 0
                        fi
                exit 0
                fi
        fi

echo No lock_host detected
echo Making lock_host
hostname > ~/.mozilla/firefox/lock_host
echo Running firefox
/usr/bin/firefox
echo Removing lock_host
rm ~/.mozilla/firefox/lock_host


It is a little sloppy and could be neater and could handle ssh requiring a password but it works for me.
I see this was tagged wontfix. Any chance of at least getting firefox to work so that when I have a running instance on machine X, then I ssh to X from Y (with X11 forwarding), starting firefox from the command line with DISPLAY pointing to the forwarded X11 display, I would get a window of the *same ff instance* on the sshing machine (i.e. where DISPLAY points), not on the wrong display (i.e. DISPLAY when firefox was first started)? This is really annoying, and works for at least Konqueror btw :P
Ah, I misparsed the email. What was changed to WONTFIX was a bug this depends on. Hope that doesn't mean this will never get fixed - this seems to annoy a lot of people, just jugding from the enormous Cc: list.
QA Contact: imajes-qa → profile-manager-backend
See Also: → https://launchpad.net/bugs/93546
Revised script that provides the required functionality until a proper fix is supplied.

Basically logs where firefox is running and will remotely kill ff allowing it to be restarted locally (and ff recovers the session). Requires kde / ssh keys to be setup to work.

#!/bin/sh
HN=`hostname`

echo hostname set to $HN
if  test -e ~/.mozilla/firefox/lock_host ; then
        LM=`cat ~/.mozilla/firefox/lock_host`
        echo Firefox has taken a lock out on the following machine:
        cat ~/.mozilla/firefox/lock_host
        if [ "$LM" = "$HN" ] ; then
                echo Running a repeat firefox
                /usr/bin/firefox
                exit
        else
                #ANS=`kdialog --yesno "Firefox is locked on machine $LM \n Do you wish me to try to kill it?"`
                kdialog --yesno "Firefox is locked on machine $LM \n Do you wish me to try to kill it?"
                #ANS=$?
                #cho "Debug, ANS=$ANS"
                if [ $? = 0 ]; then
                #if test yes = $ANS ; then
                        echo "Trying to kill the remote firefox"
                        #RES=`ssh -o "StrictHostKeyChecking no" $LM "killall -regexp firefox"`
                        echo "No result" > /tmp/.netfoxsshres
                        ssh -o "StrictHostKeyChecking no" $LM "killall -regexp firefox" 2> /tmp/.netfoxsshres
                        RES=`cat /tmp/.netfoxsshres`
                        rm  -f /tmp/.netfoxsshres
                        kdialog --msgbox "Result was $RES, now try again"

                        else
                                exit
                        fi
                exit
                fi
        fi

echo No lock_host detected
echo Making lock_host
touch ~/.mozilla/firefox/lock_host
echo $HN >> ~/.mozilla/firefox/lock_host
date >> ~/.mozilla/firefox/lock_host.log
echo $HN >> ~/.mozilla/firefox/lock_host.log
#uname -n > ~/.mozilla/firefox/lock_host

echo Running firefox
/usr/bin/firefox $1 $2 $3 $4 $5
echo Removing lock_host
rm -f ~/.mozilla/firefox/lock_host
date >> ~/.mozilla/firefox/lock_host.log
For goodness sake.  TEN YEARS and an issue is still "new".  In a commercial environment someone would be sacked.

You cant run Firefox in a remote desktop session or under Citrix if another session already has Firefox open.  This is a pretty big defect.

Frankly, this is the achilles heel of "community" software.  Lots of voluntary work on building a Ferrari ... but because it is not managed as a consumer product ... you cant drive it on Sundays between 2 and 3pm.  

The thing that really ticks me off after 20 years in the industry is techs nodding their heads and saying "yep, that's to be expected". Sorry, just because you can come up with an explanation doesn't mean "its OK".

Any workaround is better than closing umpteen "duplicates" and leaving an issue open for 10 years.  Come back in 2050 and this will probably still be open.

Am I really the only one who is ashamed to say I'm a software developer?  This is exactly the sort of thing that sees software guys get mocked by business people (well actually anyone for that matter)... and fair enough too.

Firefox as a browser is in my opinion the best (except for this particular problem) ... all the man hours that some extremely talented and selfless people have put into the tool is amazing .. only to be let down by a failure to look at the whole... as a tool used by people ... to address real usability issues ... which after all is the point.

Do you know that in real engineering disciplines people construct whole buildings? that stay standing? that can be used all year round? That take technology and engineering and apply it to _people_? that can be constructed in days? to budget?!! ... such a revolutionary concept.

While "db" has been very generous with his time to provide his script I don't think this will help my grandmother.

Yep, Im an angry old man .. the thing that makes me a sad old man is that this sort of failure is why open source and community software hasn't quite conquered the world how many predicted.  Instead a commercial layer appears in between .. a layer that "tweaks" all the effort of selfless individuals to get to an actual product that delivers... and that commercial layer then chuckles it all the way back to the bank.
Mike S - Not disagreeing a bit. There are also other significant flaws in FF4 and up (dysfunctional default UI, rapid release cycle, the 'fix' for bug 586234, inability to clone a tab).
I don't think it is necessarily a reflection on all software developers, not even on all who work on FF. My guess is - and that is true for commercial software as well - some folks with a far too big ego make the decisions and they want things to be their way. The UI change that nobody wanted - still there. The rapid releases that still break add-ons and that caused hundred thousands of complaints - still there. All the stuff that works fine in FF3.x and was broken for no reason in FF4 - still there. I think that up until FF3 Mozilla was close to the community of users and made a browser that users loved. Then something changed, a decision was made to copy Chrome and entirely ignore the wishes of the user community. What Mozilla needs to do is replace the decision makers with folks that care about the users more than themselves. FF turned into the materialized ego trip of a select few and the result is unhappy users and continuously dropping market share. I really wonder how the decisions are made which bugs to fix first after covering security issues. My guess is that new (and buggy) features trumps fixing bugs filed a decade ago. And the memory leaks are still there, but that is a common occurrence in FF since version 1.

As far as sharing a profile is concerned, I think that it is even more a need for Thunderbird. You wrote that you are a developer. I know it is a common response that gets used too often, but maybe you can take on this issue and fix it? I wish I could, but I am just a QA buff and a regular user aka someone who the FF folks give a damn about.
I cannot believe this bug is still in the wild - it has been made worse recently for me because the the fragility of the FF databases.  I'm on a big net - if the computer I last had FF running on sleeps then I'm screwed unless I physically find the computer, turn it on and quit FF before I attempt to run it elsewhere.  Given this sleeping computer could be several km away it is pretty impractical.  

Result: toss up between good browsers with limited functionality on brain dead webaps I'm obliged to use or FF which regularly screws up all saved information because it can't imagine a computer system where more than one host shares a disk drive!
db, I think you're seeing another (related) bug. Locking is used, so that unless there's a hardware/filesystem/user-mistake problem or Firefox freezes/crashes, there mustn't be any profile corruption.

If you attempt to remove the lock file manually, this is your problem. Never put a computer into sleep while there's a lock file on a shared disk.
The computer sleeps of it's own accord.  It is ridiculous that FF cannot handle this (or equivalently a computer crashing) without losing data.  

The point about this is that I need to be able to start FF on a machine in a situation where it might be running or might of been running on another machine.  The inability of FF to handle one disk space shared over more than one machine is the fault here.   If FF had this ability (and it used to have it many years ago) then the problem of a remote machine sleeping or crashing should be solved.

As done to death elsewhere there are numerous well established ways to play nicely with shared data but FF chooses not to.
At this point we have no reasonable plan or path to fixing this issue, so I'm going to WONTFIX it.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → VERIFIED
Giving up because you can't all agree on a method how open source of you. Do you think chrome or internet explorers teams would give up because they can't find a solution. Has anybody asked chrome what they did to solve the problem. You could probably find out what is does by looking at their file structure. Why don't you just make the caches and ids indiviual to the machine/time or is that out of the question because of some reason that would make a lot more work that should probably be done consider how many thousands of people face this issue every day.
I share Ben O'Brien's sentiment. Just look at how many duplicates and comments are there for this issue. Here is what my situation is:
I have two desktops, a file server, and a laptop. I use them for various tasks and at times need to post to mailing lists for help or want to share information or small files with others via email. Having to do this from one and only one system at any given time with no other client running anywhere else is a huge annoyance. I'd understand the restriction that not two clients at the same time can access a profile, but surely they should be able to do so one after another as long as those clients no longer needing profile access just let go. That does not even have to be default behavior. Many folks will ever only run one instance, but plenty others have two or more.
Alternatively, create a service that can be installed on one system where the profile is stored. All other clients do not access anything else other than that service on the LAN.

This issue came up over TEN years ago and is around since then. Nobody expects a quick fix done in a matter of weeks, but to not do anything for a decade is just weak. Nobody among the developers feels to be up for this challenge?
I strongly suggest not only to reverse course on this issue, but to finally get this fixed. Other apps can share common data, so it is surely not impossible.
Thank you Ramona@gmx.net you have given me an idea.

I don't see why you have to lock a profile in anymore. There are plenty of work around even if you do. Tons of files can be now edited by multiple sources. At max you should be able to make a temporary copy of the file marked with there date then sync the two at often as posible. Just pop up a window with any conflicts, after all out of this small fraction of people who will be using this feature most, if not all, will know how to deal with such a question. Then there is the option to make the profile unique to the machine but that would be the slack option however even that would be better then after ten years of no progress just giving up. Seriously just putting any sort of cheap fix is better then giving up because there is no consensus for a solution. You can always improve upon a cheap fix however you can't do as much with a team that just gives up when they see something that difficult that requires cooperation and desicion making on an open source project.


So now is the point where you get mad and prove me wrong instead of mud slinging or burying the **** you won't clean up.
This is not resolved and it is, if anything, worse than before.

I have the misfortune to have a large net over several site which I move around.  Computers in various locations put themselves to sleep when idle.  This makes it <impossible> to recover firefox at another machine without corrupting the databases.

As it is FF is incompetent for use with NFS and there is no good reason to make it so.
Try this for a problem:

Fix "The bookmarks and history system will not be functional" error message
(Redirected from The bookmarks and history system will not be functional)

Do you see this error message when you start Firefox?
The bookmarks and history system will not be functional because one of Firefox's files is in use by another application. Some security software can cause this problem

That happens when the file (named places.sqlite) that stores your bookmarks and browsing history can\u2019t be accessed by Firefox. This article covers two possible solutions.

If you don't see the error above, then you should try one of these articles instead:

    Bookmarks and toolbar buttons not working after upgrading
    Recover lost or missing Bookmarks
    Can't add, change or save bookmarks - How to fix
    Navigation buttons like back, home, bookmarks and reload are missing 


The reality is this occurs when using FF with NFS because FF can't handle simple file locking on its databases and it happens all the time.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.