340125 - Other Mozilla components (Thunderbird) block update

Status: RESOLVED WORKSFORME

(Toolkit :: Application Update, defect)

Description

[Colin S. Miller]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

If Thunderbird is running when Firefox updates (either automatically or manually),
then the update will fail.



Reproducible: Always

Steps to Reproduce:
1. Ensure Thunderbird is running, and is displaying an email (plain-text message is fine).
2. Start Firefox, and update.


Actual Results:  
The Firefox update will fail.

Expected Results:  
This might be correct. Thunderbird might be using Gecko or XUL,
which Firefox is trying to update.

However, the error message only mentions that all instances of Firefox must be stopped, not other Mozilla software.

A better error message, indicating that other Mozilla software must be stopped.

Or, even better, autodetecting the blocking software, and offering to stop it.

Comment 1

[Ralf Vitasek]

thats rather strange since i did the 1.5.0.4 update today in firefox while thunderbird was running. no problems encountered.

from what firefox version did you update? 1.5.0.3 or an older version?
was it an incremental update? or a full reinstall (550kb incremental update or was the autupdater downloading the full package?

Comment 2

[:Gavin Sharp [email: [e-mail]]]

Thunderbird and Firefox are completely independent, one should not be preventing the other from updating. Something strange may be happening with the NSS dlls, they can be loaded from places other than the installation directory, I think.

Colin: where are Thunderbird and Firefox installed on your computer?

Comment 3

[Nick Thomas [:nthomas] (UTC+12)]

Works fine for me too; Firefox & Thunderbird should be sharing no components.

Do you still have the update log from <firefox install dir>\updates\last-update.log ? If so, and the date stamp is right for the failed binary patch attempt, please attach it to this bug.

Comment 4

[Ria Klaassen (not reading all bugmail)]

Saw something like that before: Bug 313790.

Comment 5

[Colin S. Miller]

It was a 1.5.0.3 to 1.5.0.4 "later" autoupdate.
Thunderbird is currently "version 1.5 (20051201)"

I closed Thunderbird to let the update proceed; the log reports sucess.

Comment 6

[Colin S. Miller]

Attachment: 1.5.0.4 -> 1.5.05 update log (C:\Program Files\Mozilla Firefox\updates\0\update.log)

This occured again, when trying to update to 1.5.0.5.

Steps to reproduce

Pressed 'update firefox now' button, after firefox automatically 
downloaded the updates.

The installer started, and then exited without reporting an error.

Restarted firefox via "start menu/programs/mozilla firefox/mozilla firefox"
I got a dialog titled "Software Update Failed" and reading
"One or more files could not be updated. Please make sure all other applications
are closed and that you have permission to modify files, and then restart Firefox to try again."

I OK'ed this and the installer restarted, and failed in the same way.

I have the spellcheck plugin for Firefox installed, if this will have any effect on the updater.

Comment 7

[Nick Thomas [:nthomas] (UTC+12)]

This looks very like bug 313790, as nssckbi.dll couldn't be patched by Firefox. Could you look at bug 313790 comment #9 and report back ?

Comment 8

[Colin S. Miller]

There doesn't seem to be a secmod.db file in
C:\Program Files\Mozilla Thunderbird
or
C:\Program Files\Mozilla Firefox
however, although there is a nssckbi.dll file in
Thunderbird's directory, according to sysinternal's Process Explorer,
Thunderbird has loaded the copy from Firefox's directory.

Thunderbird is set to autostart when I log in; Firefox is not, although it is the default browser.

Comment 9

[Colin S. Miller]

Found the secmod.db file - I didn't realise that it was in my profiles directory, not the software install directory. These files seem to be in a binary format, but looking for strings seems to show that

Thunderbird is set to use
C:\PROGRA~1\MOZILL~1\nssckbi.dll
which is C:\Program Files\Mozilla Firefox\nssckbi.dll

and Firefox is using
C:\Program Files\Mozilla Firefox\nssckbi.dll

Comment 10

[Colin S. Miller]

Is there any way to edit Thunderbird's secmod.db file,
so that it use its own DLL?
Or is this not recommended?

Comment 11

[Kai Engert (:KaiE:)]

secmod.db records what "security devices" you have configured.

Unless you manually added a smartcard device to your profile, secmod.db probably does not contain important information.

You could try to quit your apps, move secmod.db away (rename it etc.) and start again.

If you do this for both TB and FF, I'm curious what each secmod.db looks like for you.

Does FF secmod.db refer to the FF nssckbi.dll
and
does TB secmod.db refer to the TB nssckbi.dll?

Comment 12

[gj]

I just did an automatic update to Firefox 2.0.0.5 and, as has happened for several of the past automatic updates over the past 2 or 3 years, I had this same problem - the update tries to install, and returns the message "One or more files could not be updated..." or words to that effect. I always have Thunderbird running, and I've always assumed it was causing a conflict, so I exit Thunderbird and then the update works fine. My symptoms and recommendations are exactly those of the original poster.

Comment 13

[Robert Strong (they/them - no direct email)]

(In reply to comment #11)
> secmod.db records what "security devices" you have configured.
> 
> Unless you manually added a smartcard device to your profile, secmod.db
> probably does not contain important information.
> 
> You could try to quit your apps, move secmod.db away (rename it etc.) and start
> again.
> 
> If you do this for both TB and FF, I'm curious what each secmod.db looks like
> for you.
> 
> Does FF secmod.db refer to the FF nssckbi.dll
> and
> does TB secmod.db refer to the TB nssckbi.dll?
After doing this I see just the reference to the root of the profile.

Interestingly enough, I had migrated my Firefox profile from a different system and it had no references to the current root of the profile though it had a reference to the root of my old profile on the old system from around a year or more ago. It also had a reference to an old installation's nssckbi.dll which had been removed a while ago.

Kai, is there an open nss bug on this?

Comment 14

[Kai Engert (:KaiE:)]

(In reply to comment #13)
> ... 
> Kai, is there an open nss bug on this?


I don't know.
I think your complaint is that secmod.db record full path for the roots module, causing this file to be system specific and causing trouble when you try to move the file to different systems (move profile)

Comment 15

[Robert Strong (they/them - no direct email)]

(In reply to comment #14)
> (In reply to comment #13)
> > ... 
> > Kai, is there an open nss bug on this?
> 
> 
> I don't know.
> I think your complaint is that secmod.db record full path for the roots module,
> causing this file to be system specific and causing trouble when you try to
> move the file to different systems (move profile)
For myself, it isn't clear to me why it would reference the dll for another installation in the first place as well as why it doesn't clean itself up when this other installation is removed. Is there some reason a Firefox profile using an installation that has nssckbi.dll would need or should have a reference to another Mozilla app's nssckbi.dll? In my case I never added a smartcard if for some reason that would cause the profile to reference another installation's nssckbi.dll... even then I don't see why it should.

Comment 16

[Nelson Bolyard (seldom reads bugmail)]

Maybe you copied the .db files from FF to TB as a way to copy your 
downloaded email certs from FF to TB?  That's the wrong way to do it.

If you're not using any crypto hardware, then just 
- shutdown FF and TB
- remove (or rename) the secmod.db file in the TB profile
- restart TB.

Comment 17

[Robert Strong (they/them - no direct email)]

(In reply to comment #16)
> Maybe you copied the .db files from FF to TB as a way to copy your 
> downloaded email certs from FF to TB?  That's the wrong way to do it.
I'm positive that I didn't and there have been several reports of nssckbi.dll being in use when performing an app update or an install where no other app files were in use though a different Mozilla app was in use (e.g. can't update Firefox while Thunderbird is running, vice versa, etc.). I believe it was dveditz mentioned the reference to a different nssckbi.dll than the one where the app was running a couple of years ago and iirc he said this has been happening for some time even then. Is there anyway to not reference any other nssckbi.dll than the one where the app is located?

> If you're not using any crypto hardware, then just 
> - shutdown FF and TB
> - remove (or rename) the secmod.db file in the TB profile
> - restart TB.
Right but that doesn't help when app update can't update the files because of nssckbi.dll being in use. In the case of the installer I've added file in use support to replace the file on the next OS reboot which is much more complex to add to app update.

Comment 18

[Phil Ringnalda (:philor)]

Given the paths reported in comment 9, I'd think the STR might be something like

1. Install Thunderbird, ages ago when paths in secmod.db were stored as C:\PROGRA~1\etc.
2. Uninstall Thunderbird, leave your profile.
3. Install Firefox
4. Install Thunderbird
5. In the modern era with full paths, create a new Firefox profile.

I don't really remember how ~1 paths worked, but I'd think that steps 2 through 4 would give you a Thunderbird profile pointing at what had become a Firefox app dir.

Comment 19

[Nelson Bolyard (seldom reads bugmail)]

Robert, the steps I gave in comment 16 will cure this problem for the user,
once and for all.  It would be good to do them in each of the user's profile
directories: FF, TB, and whatever else might have inherited/copied files 
from some old old installation.

Comment 20

[Robert Strong (they/them - no direct email)]

We haven't seen this in quite some time and there are already bugs for app update handling files in use which would also solve this. The specific problem with secmod.db containing full paths to dll's in other apps which caused them to be in use was fixed awhile ago so I am resolving this as wfm.