[MASTER]Firefox is already running message

Bug #308605 reported by ubby on 2008-12-16
290
This bug affects 39 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Confirmed
Low
firefox (Ubuntu)
Low
Unassigned

Bug Description

When I close Firefox and start it again I get the following 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.

I also have this problem with Firefox on Vista.
I use Firefox 3.0.4.
Ubuntu 8.10 (64 bit)

> Steps to Reproduce:
> 1. Start firefox with an existing profile "default"
> 2. Start firefox with an existing profile "second" using 'firefox -P second'
> Actual Results:
> The running firefox instance using the profile "default" opens another window

> Starting another firefox instance can be done by
> firefox -P second -no-remote
> but there is no way to e.g. open a firefox window with a specified profile
> and a given url from e.g. command line or from other programs
> that allow to specify the browser command.

Design/Behaviour of "Remote mode" and "NoRemote mode" is same as current since initial of Mozilla family. Simply, command line parameter for the mode is changed to one used by MS Win version from one used by Mozilla on Linux(Called "Mozilla Application Suite" after release of Fx/Tb).
(Before change on Linux)
  "Remote mode" : Started with -remote
  "NoRemote mode" : Started without -remote
(After change on Linux.)
  "Remote mode" : Started without -no-remote
  "NoRemote mode" : Started with -no-remote
And, "-P prof_name" has meaning only when (A) start of first instance of Firefox of "Remote mode", (B) start of new Firefox instance of "No-Remote mode".
See Bug 308076 Comment #19 for brief history of "-remote" switch, MOZ_NO_REMOTE=1 environment variable, and "-no-remote" switch.
See also Bug 459535(same report/claim of same behaviour of Seamonkey trunk on Linux).
Do you really think that enhancement(==Design change around "Remote/NoRemote mode") has to be done?
Please note that usual/average users never use multiple profiles. Further, many of usual/average users don't know about existence of profile manager, because Firefox developers(Mozilla Company) eager to hide existence of profile manager.
See following Bug.
> Bug 214675 Remove Profile Manager UI

> "Firefox is already running, but is not responding. [..]"

Which version of Firefox is the "unresponsive" Firefox?
How the "unresponsive" Firefox is started before the "unresponsive" problem?
Similar problem on Linux to Bug 427118 on MS Win(DUP of Bug 395891 on MS Win)?
Anyway, the "unresponsive" problem is different from your enhancement request, although the enhancement will be possibly a solution of the "unresponsive" problem. I recommend you to open separate bug for the "unresponsive" problem.

> Do you really think that enhancement(==Design change around "Remote/NoRemote
> mode") has to be done?
> Please note that usual/average users never use multiple profiles.

That's a point.

> Further, many of usual/average users don't know about existence
> of profile manager, because Firefox developers(Mozilla Company)
> eager to hide existence of profile manager.
> See following Bug.
> > Bug 214675 Remove Profile Manager UI

That would be the logical consequence. On the other hand it would force me to run a second browser other than firefox in order to accomplish a strict separation of the several things (proxy, passwords, bookmarks, etc.).

And it would make it unnecessarily difficult testing development versions of firefox with a fresh profile.

> > "Firefox is already running, but is not responding. [..]"
> Which version of Firefox is the "unresponsive" Firefox?
> How the "unresponsive" Firefox is started before the "unresponsive" problem?
Steps:
1) firefox -P profile1
2) firefox -P profile1 -no-remote

> Similar problem on Linux to Bug 427118 on MS Win(DUP of Bug 395891 on MS Win)?
Not quite, since there are no other programs than firefox (and command line) involved.

> Anyway, the "unresponsive" problem is different from your enhancement request,
> although the enhancement will be possibly a solution of the "unresponsive"
> problem. I recommend you to open separate bug for the "unresponsive" problem.

Hmm. The main reason I posted this bug is the same:
There are several profiles that are handled independently.
Using two profiles at the same time should be made "possible" simply by specifying the profile to use.
I don't want that "-no-remote" switch, it's just a workaround to open a second instance of firefox with another profile.
The no-remote swith is unnecessary imho, the distinction should be done according to the profile name, if given, otherwise it should use the default profile.
If no firefox instance using that profile is running, start a new one, otherwise open another window (or tab, depending on the configuration).

(In reply to comment #2)
> > How the "unresponsive" Firefox is started before the "unresponsive" problem?
> Steps:
> 1) firefox -P profile1
> 2) firefox -P profile1 -no-remote

Problem was re-created very easily, with Fx Trunk on MS Win-XP SP3.
(I have multiple profiles, so only "multiple profile exist" case is tested)
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080910043000 Minefield/3.1b1pre
Following dialog was issued when "2) firefox.exe -no-remote -P profile1" is kicked after "1)".
> 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.
This dialog was displayed even when "2) firefox.exe -no-remote -P profileX", where profileX doen't exist.
If profile name is not supplied("2) firefox.exe -no-remote -P" is used), profile manager's profile selection window is displayed.

I set "firefox.exe -P"(currently same behavior as "firefox.exe -ProfileManager"), because I want to choose profile manually always, so I couldn't meet the phenomenon.
If both are "Remote Mode"(without -no-remote), behaviour looks to be "as desinged".
See 459535 Comment #5 for Fx 3's behaviour when both are "Remote Mode"(without -no-remote switch).
This is possibly next problem:
  If -P "profile_name" is specified, "-no-remote" works only when already
  running Fx instance without -no-remote(Fx with Remote mode) doesn't exists.
I guess that this is because "-no-remote" is a circumvention of inconvenience due to design change of "kill -remote switch and force use of MOZ-NOREMOTE=1".

Tested some cases.

> BAT files to start Firefox. -no-remote can be replaced by "SET MOZ_NO_REOTE=1".
> Multiple profiles exist when tested.
> (A) Start in Remote_Mode
> (A-1) Remote_Mode_Existent_Prof : firefox.exe -P "Existent_Prof"
> (A-2) Remote_Mode_Non_Existent_Prof : firefox.exe -P "Non_Existent_Prof"
> (A-3) Remote_Mode_No_Prof : firefox.exe -P
> (B) Start in No_Remote_Mode
> (B-1) No_Remote_Mode_Existent_Prof : firefox.exe -no-remote -P "Existent_Prof"
> (B-2) No_Remote_Mode_Non_Existent_Prof : firefox.exe -no-remote -P "Non_Existent_Prof"
> (B-3) No_Remote_Mode_No_Prof : firefox.exe -no-remote -P

(Case-1) First kick of Firefox
  In any first kick of Firefox,
     (A-1)/(B-1) : Fx starts using specified profile
     (A-2)/(A-3)/(B-2)/(B-3) : Profile selection dialog is displayed

(Case-2) Start second Firefox

(Case-2-1) Already started Firefox : (A-1) Remote_Mode_Existent_Prof
(Case-2-1-1) Second Fx : (B-1) No_Remote_Mode_Existent_Prof
             => Firefox is already running, but is not responding
(Case-2-1-2) Second Fx : (B-2) No_Remote_Mode_Non_Existent_Prof
             => Firefox is already running, but is not responding
(Case-2-1-3) Second Fx : (B-3) No_Remote_Mode_No_Prof
             => Profile selection dialog is displayed

(Case-2-2) Already started Firefox : (B-1) No_Remote_Mode_Existent_Prof
(Case-2-2-1) Second Fx : (A-1) Remote_Mode_Existent_Prof
             => Firefox is already running, but is not responding
(Case-2-2-2) Second Fx : (A-2) Remote_Mode_Non_Existent_Prof
             => Profile selection dialog is displayed
(Case-2-2-3) Second Fx : (A-3) No_Remote_Mode_No_Prof
             => Profile selection dialog is displayed
(Case-2-2-4) Second Fx : (B-1) Remote_Mode_Existent_Prof
             => Firefox is already running, but is not responding
(Case-2-2-5) Second Fx : (B-2) Remote_Mode_Non_Existent_Prof
             => Firefox is already running, but is not responding
(Case-2-2-6) Second Fx : (B-3) No_Remote_Mode_No_Prof
             => Profile selection dialog is displayed

When profile selection dialog is displayed, and if already used profile is chosen, warning of "profile is in use" is issued.
Warning of "..., but is not responding" looks for me to be wrong(then misleading) warning problem when parent.lock exists or specified profile is not found.
In any case of "profile is in use" or "profile not found", I think profile selection dialog is kind for user if multiple profiles exist, but I think proper warning is sufficient.

Following bug are found by search for "profile already running".
> Bug 278860 confusing "profile in use"/"already running" error when profile is missing (not found)
> Bug 381139 Confusing "Thunderbird is already running..." message when profile is read-only.
> Bug 459991 "Already running" message if profile directory doesn't exist

Your case is 4-th case : "profile is in use".

FYI.
If without "MOZ_NO_REMOTE=1" and without "-no-remote", and if Fx of "Remote Mode" is already running, -ProfileManager is also ignored.
> Bug 99828 -profilemanager just opens a new window if Firefox is already running
It's same as ignored -P when already running Fx of "Remote Mode" exists.

Confirming, and changing to Severity=major

"profile is missing" of Bug 278860 means "profile is defined in profiles.ini, but pointed profile directory is not found".
To avoid loss of "non-existent profile name in -P with -no-remote" case (user error, profile manager is usually invoked), I added description of this case in bug summary in addition to main "(existent/correct) profile is in use" case.

This is certainly not a major loss of functionality

When I close Firefox and start it again I get the following 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.

I also have this problem with Firefox on Vista.
I use Firefox 3.0.4.
Ubuntu 8.10 (64 bit)

Confirmed. Also when firefox starting up is taking a long time and you click the firefox icon for a second time, the same message also appears.

Changed in firefox-3.0:
status: New → Confirmed
Charlie Kravetz (charlie-tca) wrote :

I am seeing this more in Jaunty 9.04 (development version) than in previous versions of Xubuntu. Firefox seems to take several seconds to shutdown.

Changed in firefox-3.0:
importance: Undecided → Medium
status: Confirmed → Triaged
Sjors Gielen (sgielen) wrote :

I am currently running Jaunty 9.04, and am having the same problem. Firefox does not quit here, even after a few minutes. I ran firefox --debug, then when the process hang, sent it a SIGHUP and generated a stack trace using gdb, this is the output:

Program received signal SIGHUP, Hangup.
[Switching to Thread 0x7fd9622f0700 (LWP 9750)]
0x00007fd961ee2a94 in __lll_lock_wait () from /lib/libpthread.so.0
(gdb) bt
#0 0x00007fd961ee2a94 in __lll_lock_wait () from /lib/libpthread.so.0
#1 0x00007fd961ede190 in _L_lock_102 () from /lib/libpthread.so.0
#2 0x00007fd961edda7e in pthread_mutex_lock () from /lib/libpthread.so.0
#3 0x00007fd95a155a3c in xcb_writev () from /usr/lib/libxcb.so.1
#4 0x00007fd95caf6dde in _XSend () from /usr/lib/libX11.so.6
#5 0x00007fd95caf6f21 in _XReply () from /usr/lib/libX11.so.6
#6 0x00007fd95caeae13 in XSync () from /usr/lib/libX11.so.6
#7 0x00007fd95cdbaf8a in XRenderFindDisplay () from /usr/lib/libXrender.so.1
#8 0x00007fd95cdb89fe in XRenderFreePicture () from /usr/lib/libXrender.so.1
#9 0x00007fd951482c74 in ?? () from /usr/lib/libQtGui.so.4
#10 0x00007fd951483390 in ?? () from /usr/lib/libQtGui.so.4
#11 0x00007fd9514740f3 in QPixmap::deref () from /usr/lib/libQtGui.so.4
#12 0x00007fd951474434 in QPixmap::~QPixmap () from /usr/lib/libQtGui.so.4
#13 0x00007fd950d9bcfc in ?? () from /usr/lib/kde4/plugins/styles/oxygen.so
#14 0x00007fd950da7cf7 in ?? () from /usr/lib/kde4/plugins/styles/oxygen.so
#15 0x00007fd9611eb6ed in exit () from /lib/libc.so.6
#16 0x00007fd9611d35ad in __libc_start_main () from /lib/libc.so.6
#17 0x00000000004011b9 in ?? ()
#18 0x00007fff6a30e748 in ?? ()
#19 0x000000000000001c in ?? ()
#20 0x0000000000000001 in ?? ()
#21 0x00007fff6a3106e3 in ?? ()
#22 0x0000000000000000 in ?? ()
(gdb) detach
Detaching from program: /usr/lib/firefox-3.0.7/firefox, process 9750
(gdb) quit
dazjorz@dazjorz-desktop:~$ strace -p 9750
Process 9750 attached - interrupt to quit
futex(0xe75c68, FUTEX_WAIT_PRIVATE, 2, NULL^C <unfinished ...>
Process 9750 detached

summary: - Firefox is already running message
+ [MASTER]Firefox is already running message

Please read the bug report before marking it as a duplicate.

 https://bugs.launchpad.net/bugs/308605 is not related at all to https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/246010.

https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/246010 is about being unable to open a Firefox window on a second screen when a Firefox window is open on another screen.

https://bugs.launchpad.net/bugs/30860 is about being unable to open a Firefox window after closing the last Firefox window (quitting).

On 04/06/2009 12:44 PM, keepitsimpleengr wrote:
> Please read the bug report before marking it as a duplicate.
>
> https://bugs.launchpad.net/bugs/308605 is not related at all to
> https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/246010.
>
> https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/246010 is
> about being unable to open a Firefox window on a second screen when a
> Firefox window is open on another screen.
>
> https://bugs.launchpad.net/bugs/30860 is about being unable to open a
> Firefox window after closing the last Firefox window (quitting).
>
Ther eis on eon that already, not sure wher eor if it was marked as a
dup of that bug however same reason applies it wont open another session
in another desktop view if one is already running, however i do remember
a bug on this just not sure what happened to it

--
Sincerely Yours,
    John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246

"How can i get lost, if i have no where to go"
    -- Metallica from Unforgiven III

I have the same bug in Debian sid + KDE 4.2.

(gdb) bt
#0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:130
#1 0x00007f5b21457cc2 in pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:353
#2 0x00007f5b1e91388e in _xcb_conn_wait (c=0xaf7ea0, cond=0xaf8f70, vector=0x7fff2f0283e0, count=
    0xffffffffffffffff) at /home/ancient/jd/Work/debian/libxcb/./src/xcb_conn.c:266
#3 0x00007f5b1e913e39 in _xcb_out_send (c=0xaf7ea0, vector=0x7fff2f0283e0, count=0x7fff2f0283dc)
    at /home/ancient/jd/Work/debian/libxcb/./src/xcb_out.c:338
#4 0x00007f5b1e9140e5 in xcb_writev (c=0xaf7ea0, vector=0x7fff2f028430, count=3, requests=3)
    at /home/ancient/jd/Work/debian/libxcb/./src/xcb_out.c:286
#5 0x00007f5b21cfabf6 in _XSend (dpy=0xb188d0, data=<value optimized out>, size=0)
    at ../../src/xcb_io.c:332
#6 0x00007f5b21cfad49 in _XReply (dpy=0xaf8f70, rep=0x7fff2f0284f0, extra=0, discard=1)
    at ../../src/xcb_io.c:450
#7 0x00007f5b21ceed63 in XSync (dpy=0xb188d0, discard=0) at ../../src/Sync.c:48
#8 0x00007f5b21fedffa in XRenderFindDisplay () from /usr/lib/libXrender.so.1
#9 0x00007f5b21feba5e in XRenderFreePicture () from /usr/lib/libXrender.so.1
#10 0x00007f5b14a225b4 in QX11PixmapData::release (this=0x1f75b10) at image/qpixmap_x11.cpp:1206
#11 0x00007f5b14a22cd0 in ~QX11PixmapData (this=0xaf8f70) at image/qpixmap_x11.cpp:1182
#12 0x00007f5b14a13a73 in QPixmap::deref (this=0x1f6c2c0) at image/qpixmap.cpp:1322
#13 0x00007f5b14a13db4 in ~QPixmap (this=0xaf8f70) at image/qpixmap.cpp:332
#14 0x00007f5b1433bb7c in ~TileSet (this=0x1f6c1f0) at ../../../kstyles/oxygen/tileset.h:61
#15 0x00007f5b14347bd7 in OxygenStyleHelper::~OxygenStyleHelper() ()
   from /usr/lib/kde4/plugins/styles/oxygen.so
#16 0x00007f5b265ddcad in *__GI_exit (status=0) at exit.c:75
#17 0x00007f5b265c75ad in __libc_start_main (main=0x401296 <main>, argc=3, ubp_av=0x7fff2f028848, init=
    0x405750 <__libc_csu_init>, fini=<value optimized out>, rtld_fini=<value optimized out>, stack_end=
    0x7fff2f028838) at libc-start.c:254
#18 0x0000000000401139 in _start () at ../sysdeps/x86_64/elf/start.S:113

This seems to depend on the KDE styling, from the backtrace the actual bug is likely in Qt or X11.

*** This bug has been marked as a duplicate of bug 441422 ***

Closing as DUP of bug 441422 is incorrect action. Re-opening. Benjamin, please don't play around close code.

Guillaume Millet (guimillet) wrote :

Me too in Kubuntu Jaunty.

My backtrace is not very useful as most symbols are missing:
(gdb) bt
#0 0xb7feb430 in __kernel_vsyscall ()
#1 0xb7fc5cf9 in __lll_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb7fc1129 in _L_lock_89 () from /lib/tls/i686/cmov/libpthread.so.0
#3 0xb7fc0a32 in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0
#4 0xb63f468f in xcb_writev () from /usr/lib/libxcb.so.1
#5 0xb6a98afa in _XSend () from /usr/lib/libX11.so.6
#6 0xb6a98c23 in _XReply () from /usr/lib/libX11.so.6
#7 0xb6a8c507 in XSync () from /usr/lib/libX11.so.6
#8 0xb6b4c282 in XRenderFindDisplay () from /usr/lib/libXrender.so.1
#9 0xb6b49f25 in XRenderFreePicture () from /usr/lib/libXrender.so.1
#10 0xb4840f49 in ?? () from /usr/lib/libQtGui.so.4
#11 0xb484178d in ?? () from /usr/lib/libQtGui.so.4
#12 0xb4830d97 in QPixmap::deref () from /usr/lib/libQtGui.so.4
#13 0xb48311a0 in QPixmap::~QPixmap () from /usr/lib/libQtGui.so.4
#14 0xb45713fa in ?? () from /usr/lib/kde4/plugins/styles/oxygen.so
#15 0xb457df27 in ?? () from /usr/lib/kde4/plugins/styles/oxygen.so
#16 0xb457ec55 in ?? () from /usr/lib/kde4/plugins/styles/oxygen.so
#17 0xb4594aeb in ?? () from /usr/lib/kde4/plugins/styles/oxygen.so
#18 0xb7d5bbb9 in exit () from /lib/tls/i686/cmov/libc.so.6
#19 0xb7d4377d in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#20 0x08048d11 in ?? ()

On 05/09/2009 10:13 PM, ptitpoul wrote:
> Me too in Kubuntu Jaunty.
>
> My backtrace is not very useful as most symbols are missing:
> (gdb) bt
> #0 0xb7feb430 in __kernel_vsyscall ()
> #1 0xb7fc5cf9 in __lll_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0
> #2 0xb7fc1129 in _L_lock_89 () from /lib/tls/i686/cmov/libpthread.so.0
> #3 0xb7fc0a32 in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0
> #4 0xb63f468f in xcb_writev () from /usr/lib/libxcb.so.1
> #5 0xb6a98afa in _XSend () from /usr/lib/libX11.so.6
> #6 0xb6a98c23 in _XReply () from /usr/lib/libX11.so.6
> #7 0xb6a8c507 in XSync () from /usr/lib/libX11.so.6
> #8 0xb6b4c282 in XRenderFindDisplay () from /usr/lib/libXrender.so.1
> #9 0xb6b49f25 in XRenderFreePicture () from /usr/lib/libXrender.so.1
> #10 0xb4840f49 in ?? () from /usr/lib/libQtGui.so.4
> #11 0xb484178d in ?? () from /usr/lib/libQtGui.so.4
> #12 0xb4830d97 in QPixmap::deref () from /usr/lib/libQtGui.so.4
> #13 0xb48311a0 in QPixmap::~QPixmap () from /usr/lib/libQtGui.so.4
> #14 0xb45713fa in ?? () from /usr/lib/kde4/plugins/styles/oxygen.so
> #15 0xb457df27 in ?? () from /usr/lib/kde4/plugins/styles/oxygen.so
> #16 0xb457ec55 in ?? () from /usr/lib/kde4/plugins/styles/oxygen.so
> #17 0xb4594aeb in ?? () from /usr/lib/kde4/plugins/styles/oxygen.so
> #18 0xb7d5bbb9 in exit () from /lib/tls/i686/cmov/libc.so.6
> #19 0xb7d4377d in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
> #20 0x08048d11 in ?? ()
>
No need to confirm or place any more info since this bug has everything
needed to continue with it. IIRC we are waiting for fix from Mozilla

--
Sincerely Yours,
    John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246

"How can i get lost, if i have no where to go"
    -- Metallica from Unforgiven III

FYI.
Bug 491295 is for problem of incorrect handling of -P "<prof_name>" switch.
It'll probably resolve issue in some cases on Linux. (The bug is currently only for Linux). Setting dependency to Bug 491295

(In reply to comment #0)
> Starting another firefox instance can be done by
> firefox -P second -no-remote
> but there is no way to e.g. open a firefox window with a specified profile and
> a given url from e.g. command line or from other programs that allow to specify
> the browser command.
> Running that very same command again if there is already a firefox instance
> using the profile "second" shows a dialog with the (only partially correct)
> message "Firefox is already running, but is not responding. [..]"

I think above your case is same as Bug 491295. But your result is different from one reported by Bug 491295. Simly because different build? (6 months, so big difference)
Frank-Ralph Reiser, can you reproduce "Firefox is already running, but is not responding. [..]" with newest Fx trunk nightly?

I think a fundamental re-examination of the design is in order for profiles.

Comment #1 stated "Please note that usual/average users never use multiple profiles." My belief is that they don't use it because they don't know it's there. The usual/average user doesn't know about command line options and requires a GUI. Using my own parents as an example, my father refused to convert from IE to Firefox because he didn't like my mother's extensions and it took me 2 months of convincing that (after I setup profiles for them) her stuff would not mix with his (that and configuring IE tab to support Remote Access automatically but I digress).

Design Choices:
#1) While installing you're given limited options to "import" from other browsers but not any configuration options.

Options:
a) Keep as is, assume KISS.
b) Prompt the user "Is there more than one person using this computer? If so, would you like to setup a profile for each? Yes||No. If Yes-> How many? ::gather required information.

#2) Upon install, Firefox just goes.

Options:
a) It's easy and friendly to "just get started", KISS
b) Take the user through some basic configuration. Note: KISS - only the most basic of options as not to overwhelm the user. Also note that this should not include "default browser", only options unique to the profile. Ideally the default browser prompt should come up prior to profile manager and include the Firefox logo and a basic description for those who don't know what that means.

#3) Additional options. "no-remote" flag is currently very limiting or unfriendly to average user.

Examples of user scenarios currently unsupported:
- Profile A user is browsing, Profile B user comes and wants to check email. Profile A user doesn't want to close their session (say, in the middle of a flash video they can't resume position - or - privacy options enabled will lose session). Average user won't know about no-remote.

- Developer running 1 default profile (a), 1 developer profile (b), receives an email in Thunderbird with a link - clicks link and receives inexplicable/confusing "not responding" error message.

- Taking previous scenario, user/developer wants link opened in a specific profile, lets say profile C.

With examples like these in mind:

i) Prompt 'default browser' prior to Profile Manager (if flag set)
ii) Depreciate no-remote in favour of new implementation
iii) Add profile specific "Tools->Options->Application style" option for what to do with external links (when multiple profiles exist). *Note: this does present the problem of what to do when multiple profiles are open with conflicting instructions. Possible resolutions: if conflicting default to "Always ask". or about:config option of default to: always ask, use first open, use last open, use last active.
iv) Add Manage Profiles option with appropriate GUI to "Tools" tab
v) Pipe Dream: Ensure profiles can be switched *after* load/addon support for profiles.

Bug 491295 was WONTFIX'ed by Benjamin Smedberg. Reason why WONTFIX was;
> (Copy of Bug 491295 Comment #12)
> From Benjamin Smedberg
> I really do not want to support remoting in any form with multiple profiles.

If spec of command line parameters is changed from former version, behaviour after spec change should be one which is resonable and consistent and acceptable.
Even if user specified paramaters which Benjamin Smedberg dislikes, behaviuour shouldn't be one like current. Proper warning/error message should be issued or some parameters should be ignored appropriately.

Sheldon Hall (sheldonkhall) wrote :

Sometimes I get this message after rebooting my machine. The current work around that I have is to do (for some unknown reason) some moving around of folders.

When this bug occurs go into your ".mozilla/firefox/" directory and look at the profiles.ini file. This will tell you what the current folder storing your profile is. Something like "dshj2r45.default/" will be indicated. What you need to do is delete the "profiles.ini" file from the ".mozilla/firefox/" directory and then you can start firefox as usual.

To get your bookmarks etc. working again find out the new directory "profiles.ini" points to and copy all of the contents from the previous directory to the new one. Restarting firefox should then bring up the browser exactly how it was when it was last working.

Not sure why this works, maybe someone can explain it, or fix it? It is kinda annoying.

Sjors Gielen (sgielen) wrote :

You make Firefox create a new profile, then move all old contents to the new one. This most probably removes a "lock file". When Firefox starts, it notes in the profile "this one is already in use", so a new Firefox process doesn't corrupt that profile by using it twice at the same time. You're working around that by creating a new profile, then moving the contents open, thus making it possible for Firefox to unintentionally destroy your data.
Just use the workarounds in this bug report: Run "killall firefox" in your terminal so it dies again.

For the purpose of this bug report: I haven't had this bug in ages. Maybe the bug was in KDE/Qt (since that shows up in the backtrace) and it has since been fixed. On the other hand, sometimes it seems to be caused by other things, like pulseaudio and maybe flash: when a firefox instance is still around, killall pulseaudio kills it too, iirc. Any other known causes for this bug to appear? If not, I think the bug is safe to close.

Sjors Gielen (sgielen) wrote :

Of course, that was "moving the contents over*". Sorry.

who are you

On Thu, 25 Jun 2009 13:09:44 +0100, Sjors Gielen
<email address hidden> wrote:

> Of course, that was "moving the contents over*". Sorry.
>

--
Using Opera's revolutionary e-mail client

korte1975 (korte1975) wrote :

of course

On Thu, 25 Jun 2009 13:09:44 +0100, Sjors Gielen
<email address hidden> wrote:

> Of course, that was "moving the contents over*". Sorry.
>

--
Using Opera's revolutionary e-mail client

Sheldon Hall (sheldonkhall) wrote :

On my machine the error occurs after a system reboot and no firefox process appears to be running. I checked this using ps -A. Is there a direct way to remove this "lockfile" so that I do not need to copy files about?

Sjors Gielen (sgielen) wrote :

No processes running? Try 'ps aux | grep firefox'. If you are really sure, please run 'strace firefox 2>firefox.strace' (you will hopefully get the same error) and upload firefox.strace somewhere, or put the contents on a pastebin.

I wish the dialog says:

Firefox is already running but not responding, do you want to kill previous process and restart it? (Yes/No)

And I can click yes to restart my firefox, instead of opening another terminal to killall firefox-bin.

Thank you.

GreatBunzinni (greatbunzinni) wrote :

This problem persists on Kubuntu 9.04 with both firefox-3.0 and firefox-3.5.

It effects Windows as well, changing it to all platform.

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20090816 Minefield/3.7a1pre (.NET CLR 3.5.30729) ID:20090816045208

Bug 458369 is found. Setting dependency for ease of track.

Sjors Gielen (sgielen) wrote :

Doesn't seem to happen anymore, for me on Kubuntu Karmic. Will report back when it does reoccur.

ii firefox 3.5.3+build1+nobinonly-0ubuntu2 meta package for the popular mozilla web browser
ii firefox-3.5 3.5.3+build1+nobinonly-0ubuntu2 safe and easy web browser from Mozilla
ii firefox-3.5-branding 3.5.3+build1+nobinonly-0ubuntu2 Package that ships the firefox branding
ii flashplugin-installer 10.0.32.18ubuntu1 Adobe Flash Player plugin installer
ii flashplugin-nonfree 10.0.32.18ubuntu1 Adobe Flash Player plugin installer (transitional package
ii nspluginwrapper 1.2.2-0ubuntu6 A wrapper to run Netscape plugins on other architectures

Jahava (danjacques) wrote :

At the moment this is anecdotal, but I have experienced this problem through the entire Firefox 3.0+ lines. Recently, I was addressing some KDE4 graphical glitches that occurred when using GTK applications:

System Settings -> Appearance -> GTK Styles and Fonts:
"GTK Styles": Usage another style: "QtCurve"
(Hit "Apply" and restart any GTK+ Applications, including Firefox; in the event of this bug, make SURE the process is terminated via 'ps/kill' as documented in previous comments)

After changing this, my rendering glitches in GTK applications running in KDE4 did stop, which was awesome. Firefox was one such application that was affected by this (being a GTK+ application).

However, I _also_ have noticed (so far) that all of the instances of the process not terminating when all of its windows were closed (i.e. this bug) have also stopped since making that change. I've even tried changing the setting back and immediately notice the familiar "process already running" messages reappearing.

Could someone else who is experiencing this using Kubuntu / KDE4 try making this change and see if your results coincide with mine?

Mysha (mysha) wrote :

I fear we now have at least two bugs in this one report.
1 Firefox not releasing a lock, and thus blocking a new instance. In this case, no amount of waiting or starting new instances will solve the problem, just drastic methods like restarting the computer will.
2 Firefox releasing a lock after a new instance already found it locked and therefore considers itself blocked. In this case, you merely have to stop the new instances and start it again. The problem here is that you can't tell it to retest the lock.

Problem 1 would appears to be an implementation error; problem two a design error.

Shahar Or (mightyiam) wrote :

Dear friends,

Are these upstream bugs, please?

Guillaume Millet (guimillet) wrote :

No more problem on kubuntu Karmic.

I still have this problem (on Ubuntu Karmic), but it is more rare.

2009/10/31 ptitpoul <email address hidden>

> No more problem on kubuntu Karmic.
>
> --
> [MASTER]Firefox is already running message
> https://bugs.launchpad.net/bugs/308605
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “firefox-3.0” package in Ubuntu: Triaged
>
> Bug description:
> When I close Firefox and start it again I get the following 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.
>
> I also have this problem with Firefox on Vista.
> I use Firefox 3.0.4.
> Ubuntu 8.10 (64 bit)
>

--
European Union - United in diversity

Anche se non sembra, l'Europa unita è un sogno per molte persone.
Nell'ultima campagna elettorale praticamente nessuno ha parlato dei (seri)
problemi europei. Credo che tutti noi italiani dovremmo vergognarci di
questo.

ubby (kostas-sytske) wrote :

I still have this problem in Ubuntu Karmic Koala:
http://img81.imageshack.us/img81/7871/schermafdrukh.png

I can confirm this bug since I use multiple profiles using --no-remote. Usually, when I click on a link in thunderbird when I have multiple profiles open, it is the first profile that was opened that gets to open that link.

Recently (in firefox 3.5.5 on ubuntu 9.10) I have been getting "already running, but is not responding" error when "profile is in use. There is a meta-bug open on Launchpad about this issue: https://bugs.edge.launchpad.net/ubuntu/+source/firefox-3.5/+bug/308605

komputes (komputes) wrote :

I get the same issue in 9.10 karmic koala. Even though I have it set to "open links in a new tab" in System > Preferences > Preferred Applications, when I click on a link in thunderbird, it tried to open a new firefox instance under the same profile and gives me an error.

firefox 3.5.5+nobinonly-0ubuntu0.9.10.1

Changed in firefox:
status: Unknown → Confirmed

I have the same issue on 10.04 Lucid. And have had this problem for a LONG time.
Why is the severity of this issue not raised previously. It REALLY annoying to have to killall firefox firefox-bin everytime firefox is to be restarted.

"Annoying" is not what decided importance but if
it was to be a security risk or impedes the using
of the browser, this meets neither. As i recall
(doing this from email since i dont have a browser
at this time.) this has been reported upstream and
should be fixed by Mozilla.

On 04/28/2010 05:24 AM, David Nyström wrote:
> I have the same issue on 10.04 Lucid. And have had this problem for a LONG time.
> Why is the severity of this issue not raised previously. It REALLY annoying to have to killall firefox firefox-bin everytime firefox is to be restarted.
>

--
Sincerely Yours,
    John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246

"How can i get lost, if i have no where to go"
    -- Metallica from Unforgiven III

Mysha (mysha) wrote :

Hi,

John Vivirito schreef:
> "Annoying" is not what decided importance but if
> it was to be a security risk or impedes the using
> of the browser, this meets neither. ...

Being unable to open a browser window doesn't impede using the browser??

> On 04/28/2010 05:24 AM, David Nyström wrote:
>> I have the same issue on 10.04 Lucid. And have had this problem for a LONG time.
>> Why is the severity of this issue not raised previously. It REALLY annoying to have to killall firefox firefox-bin everytime firefox is to be restarted.

BFN
--
                                         Peter Hans van den Muijzenberg
                                                                  Sneek
                                                           <email address hidden>

John Vivirito (gnomefreak) wrote :

i will bump the importance up to medium on it.
can you please test with 3.6 in Lucid,
I am unable to reproduce this bug with latest 3.6 version that we have in our daily repo.

gnomefreak@Development:~$ policy firefox
firefox:
  Installed: 3.6.5~hg20100506r34169+nobinonly-0ubuntu1~umd1
  Candidate: 3.6.5~hg20100506r34169+nobinonly-0ubuntu1~umd1
  Package pin: 3.6.5~hg20100506r34169+nobinonly-0ubuntu1~umd1
  Version table:
 *** 3.6.5~hg20100506r34169+nobinonly-0ubuntu1~umd1 400
        500 http://ppa.launchpad.net/ubuntu-mozilla-daily/ppa/ubuntu/ lucid/main Packages
        100 /var/lib/dpkg/status

I clicked on Firefox icon while having one already open and it opened fine. I also don't get it any other way since 3.6

John Vivirito (gnomefreak) wrote :

Bumped importance to medium and status to triaged due to it seems that 3.0 and 3.5 suffer from this the same

Changed in firefox-3.5 (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
jervin (jervin) wrote :

I am running Firefox 3.6.3pre (Namoroka) with Ubuntu 10.04(Lucid) and the problem persists.

jervin (jervin) wrote :

there was a report that flash was causing problems like this and that dom.ipc.plugins.enabled.libflashplayer.so needed to be set to false. This has been done on my system.

jervin (jervin) wrote :

Sorry, make that Firefox 3.6.5pre (Namoroka)

Me2, still seeing this issue after upgrade to 10.04. 3.6.5 final.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.3) Gecko/20100423 Ubuntu/10.04 (lucid) Firefox/3.6.3

Micah Gersten (micahg) wrote :

@jervin
This is a different issue and has been fixed in the version you are running.

On 05/10/2010 07:48 PM, jervin wrote:
> there was a report that flash was causing problems like this and that
> dom.ipc.plugins.enabled.libflashplayer.so needed to be set to false.
> This has been done on my system.
>
>

Mysha (mysha) wrote :

Hi,

I can confirm the interface issue for Ubuntu 10.4 LTS and Firefox 3.6.3 Ubuntu Canonical 1.0. Newly installed, I closed Firefox after checking I could reach the web, only to realise I needed to look up Ubuntu configuration issues. The first instance was slow to close, though it did so eventually. The second instant stopped with the well-known warning, still with OK as the only option, which aborted the start-up.

                                                                                                                                Mysha

Still have this issue with Firefox 3.6.8, on both my machines. Ubuntu Bug #1 will never be fixed if bugs like this are accepted with "Medium" priority.
HOW will a Ubuntu beginner use firefox in its current state ?

Changed in firefox:
importance: Unknown → Low

This is pure comment but the profile manager is one of the few reasons I'm still using Firefox on a day to day basis. As a developer I must have a profile for development and one for browsing because often the dev plugins will cause issues with browsing (slowdowns, memory leaks, etc). It's ridiculous to think that people would have to do multiple installs to accomplish this behaviour. If anything, spin it off into a plugin so it's development can be moved forward to include features like:

- GUI access
- open multiple profiles simultaneously
- "open in" context item for profiles and other programs (dev tools, other browsers, word, etc)

Those are just a few types of things I used to expect from Mozilla - not removing useful features and crappy UI changes (Firefox 4). /end rant

Odin Hørthe Omdal (velmont) wrote :

This is a very big issue here. We're moving away from Firefox to Opera and Chromium because of it.

When someone a) logs in, b) leaves with the Ubuntu computer "locked" and then c) someone turns off the computer at the end of the day/week, the .parentlock and lock reside on the NFS.

So, when they get back, Firefox will NEVER work again. And I have to go in and delete those two files. It's extremely irritating, and it also affects Thunderbird.

They're not crash proof.

Bad design.

So yes, it should be a softlock, where you can say "I want to start Firefox ANYWAY".

komputes (komputes) wrote :

@Odin Hørthe Omdal (velmont)
This bug does not mention NFS as the cause of the issue, but using the --no-remote option for using multiple profiles. Are you just getting this error or are you using this option when starting firefox?

This bug still is "valid" imho:

Steps to reproduce:
1) Start firefox using a profile "xyz"
2) Start firefox with the options "firefox -P xyz -no-remote"

Result:
I dialog appears stating
"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."

Environments used:
Ubuntu Linux, Gentoo Linux
Firefox 7.0.1

can confirm in FF 10

dorpm (dorpmueller) wrote :

Same problem here with FF 10.0.2

Why does this keep getting closed/re-opened? It's not resolved unless it's wontfix

Bug 278860 has been fixed on 2012-05-04.
That bug is for following issue and for "without -no-remote" case.
  confusing "profile in use"/"already running" error when profile is not found
Do you see this bug's problems in latest trunk build?
(a) non-existent profile name, "without -no-remote" case
(b) non-existent profile name, "with -no-remote" case
(c) other than "non-existent profile name", "without -no-remote" case
(d) other than "non-existent profile name", "with -no-remote" case

I am confirming this bug occurrences as well. Just:
1. Create some profile in FF profile manager and set is as default
2. Close FF and delete profile folder
3. Try to start FF
and you get "Firefox is already running but is not responding" error message instead of expected "Default profile is deleted" message

Adolfo Jayme (fitojb) on 2013-02-20
affects: firefox-3.5 (Ubuntu) → firefox (Ubuntu)
Changed in firefox (Ubuntu):
importance: Medium → Low
no longer affects: firefox-3.0 (Ubuntu)
Mysha (mysha) wrote :

Hi,

Not that I understand how this bugs are being handled, anyway, but just to ask whether I understand the recent change:

With FireFox versions nearing the 20, the continued validity of this bug report for 15 versions is deemed less important because on the historical version it was reported for some five years ago, it's no longer valid for some reason?

Interestingly, while the design error that doesn't let you retry is still found in all versions of FireFox, the implementation error that causes the frequent occurrence of this seems to be limited to Ubuntu installed versions. Those versions I got from Mozilla for beta-testing don't seem to block, but the updates coming from Ubuntu which have the same Mozilla FireFox version number still do.

I consider this inability to open an URL in an already running profile as a work stoppage. There are many other software packages now, in their menu bar item Help, within the pulldown menu list there are items that actually invoke the default web browser in order to display their documentation, FAQ, user manual, and other web pages.

A possible fix to reduce this work stoppage to a work around available, is for the pop up error message to contain the URL that is being attempted to be opened. That way, users could copy and paste the URL into an new Firefox window or tab, and get the valuable information on that web page's URL for that version of the software.

Also, any other options would be nice to see displayed by the error message.

Truly, the wording of the pop up error message could be rewritten to be self explanatory. Hiding Firefox profiles is likely a motivation for not doing this. So, I suggest there be two errors, the original one, when there is no profile.ini entries (just one default profile), but for those who use profiles, change the error message, to include the name of running profile that was attempted. And provide a button to select an unrunning profile (unlocked) to satisfy the requested URL. Only those users currently using profiles would get the second wording, thus keeping the rest of the Firefox users in the dark. This button could merely start the Profile Manager, which would have to then pass on any options to the new instance, to honor the requested options. Thus, two keeping the number of code lines down, easing debugging.

I'm not sure if the rest of this comment is directly applicable, but here it is. /etc/alternatives does not have a way to specify command line options, so "-no-remote -P profilenamehere" is not available. Sure, this would be 'fix' to update-alternatives functionality. At issue is when the default web browser is firefox, firefox starts up the profile.ini default profile, and I really do not want to use the default.

a good start would be to apply the improved warning of bug 278860 multiple profile handling to the case of -no-remote when profile is already in use. IOW, that patch in bug 278860 is incomplete

Changed in firefox:
status: Confirmed → Unknown
Changed in firefox:
status: Unknown → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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