Closed Bug 1723622 Opened 3 years ago Closed 3 months ago

linux profile files locked and not usable even after fresh install or removed

Categories

(Toolkit :: Places, defect, P3)

Firefox 90
defect

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: rodrigovilla, Unassigned)

Details

Attachments

(1 file)

Attached image Console output

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:90.0) Gecko/20100101 Firefox/90.0

Steps to reproduce:

Nothing in particular, normal use and in one moment the bug started happend

Actual results:

I filled a support.mozilla question with all the details: https://support.mozilla.org/en-US/questions/1345509#answer-1432153
After staring the program in a fresh install of Clearlinux with kernel: 5.13.6-1062.native and DE: GNOME GNOME Shell 40.3 the issue where about:support is empty, sites log out and extensions not working happens again as the first time the issue started before doing the fresh install of the OS

Expected results:

After following troubleshooting steps of creating new profile or erasing the files it should have fix the issue while this isn't the case

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

The issue happens both on Wayland and XOrg

Component: Widget: Gtk → Startup and Profile System
Product: Core → Toolkit
Component: Startup and Profile System → Storage: IndexedDB
Product: Toolkit → Core

The severity field is not set for this bug.
:jjalkanen, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jjalkanen)

Tested on Ubuntu 20.04 with Firefox 94.0.

The files places.sqlite and favicons.sqlite from the ~/.mozilla/firefox/profile-name.default-release/ directory were first deleted.

After reopening the browser, there's a warning that bookmarks/history won't work because the files are used by some other process. It is verified that these features are not working just as described by the report. Additionally, the default links are missing from the default front page.

Under the profiles directory, the deleted files have been recreated and have the same permissions as the originals.

However, when the "lock" file under the same profile directory is unlinked (with unlink), the file .parentlock is removed (with rm) and the browser is reopened, the missing functionality is back and as far as I can tell, bookmarks are working as expected.

After quickly going through the support links, it seems that this last step is not a prominent part of the documentation. On Windows, the lock setup seems different and after deleting the same files, I didn't notice anything special.

So either the locks should be released when certain files are regenerated, or if this defeats the purpose of the locks, documentation improved to mention this caveat on Posix platforms.

Severity: -- → S4
Flags: needinfo?(jjalkanen)
Priority: -- → P3

places.sqlite and favicons.sqlite are not part of Storage: IndexedDB but Toolkit: Places.
I wonder if bug 1716966 would have helped to uncover this earlier than in release.

Component: Storage: IndexedDB → Places
Product: Core → Toolkit

It's unclear if all places.* and favicons.* files have been removed, and if the removal was done while Firefox was closed.
The bookmarks/history warning appears only if we have trouble opening or creating the database files, that can only happen if there's permissions problems, or files were only partially removed (for example leaving behind a -wal or a -shm).
I don't see how the lock file would be involved, Places doesn't use it.

I'm sorry for seeing this bug so late, at this point I doubt it's debuggable, after so much time.

Status: UNCONFIRMED → RESOLVED
Closed: 3 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: