On Linux, profile is missing after shutdown
Categories
(Toolkit :: Startup and Profile System, defect)
Tracking
()
People
(Reporter: theminecraftman757, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:133.0) Gecko/20100101 Firefox/133.0
Steps to reproduce:
Running Firefox Nightly on a recent install of Garuda Linux. Have a bunch of tabs open. Shut down the computer in a normal fashion. (Not using regular Firefox since this shift because I thought it might help with some issues, but I haven't been able to replicate the issue with Firefox.)
Additional details: when switching distros from Manjaro I had issues with Firefox running out of disk space. I eventually found out it was RAM allocation through the file system being disproportionately small. The /run/user/1000 directory, under which the currently loaded Firefox profile is kept. I fix that and it never runs out of space. Despite this, I find myself signed out of YouTube a few times a week, which never happened prior (doesn't seem to apply to other sites I'm perpetually logged in to). Seems like it would be a bug with the cache or site cookies, but I don't know how to verify this.
Actual results:
Upon rebooting, either Firefox Nightly says the profile is missing or inaccessible, or it says it's still in use. can make it not be in use by manually deleting the lock file in the profile. If it is missing, I see that in ~/.mozilla/firefox, my profile directory is still a soft link to /run/user/1000/psd, even though that is on a tmpfs space on RAM, not non-volatile storage. To resolve and get my session back, I remove the broken soft link and then move the most recent backup file to where the link was, and it seems to accept the folder in place of the link.
Expected results:
Firefox should shut down normally, resulting in the profile lock file being removed and the profile directory not being a link to a file system that is actively being flushed.
|
||
Comment 1•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Toolkit::Startup and Profile System' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•1 year ago
|
||
What type of filesystem is your profile directory on?
|
Reporter | |
Comment 3•1 year ago
|
||
(In reply to Dave Townsend [:mossop] from comment #2)
What type of filesystem is your profile directory on?
Pardon me, I should've included that. The installation came with BTRFS but my home folder is EXT4.
|
|
||
Comment 4•1 year ago
|
||
(In reply to Gannon Neilson from comment #0)
Firefox should shut down normally, resulting in the profile lock file being removed and the profile directory not being a link to a file system that is actively being flushed.
I'm a little confused by this. Firefox never creates the profile directory as a symlink. Is it possible that something else did this?
Is this still happening?
|
|
Reporter | |
Comment 5•1 year ago
|
||
Well that's weird. I can't find anything to suggest that this is a Linux distro-specific thing, but I suppose I don't know if it was like that elsewhere.
I've confirmed that both Firefox and Firefox Nightly do it like this. Here is the ~/.mozilla/firefox directory:
lrwxrwxrwx - me 25 Oct 13:25 6elupd8w.default-release -> /run/user/1000/psd/me-firefox-6elupd8w.default-release drwxr-xr-x - me 25 Oct 13:25 6elupd8w.default-release-backup drwxr-xr-x - me 12 Oct 11:36 6elupd8w.default-release-backup-crashrecovery-20241013_101424 drwxr-xr-x - me 12 Oct 11:36 6elupd8w.default-release-backup-crashrecovery-20241014_123310 drwxr-xr-x - me 15 Oct 10:28 6elupd8w.default-release-backup-crashrecovery-20241015_113710 drwxr-xr-x - me 15 Oct 11:40 6elupd8w.default-release-backup-crashrecovery-20241016_131340 drwxr-xr-x - me 16 Oct 13:17 6elupd8w.default-release-backup-crashrecovery-20241018_151619 drwxr-xr-x - me 23 Oct 13:50 6elupd8w.default-release-backup-crashrecovery-20241024_140427 lrwxrwxrwx - me 25 Oct 13:25 8xeojm03.me -> /run/user/1000/psd/me-firefox-8xeojm03.me drwxr-xr-x - me 25 Oct 16:15 8xeojm03.me-backup drwxr-xr-x - me 31 Aug 12:28 8xeojm03.me-backup-crashrecovery-20240831_131127 drwxr-xr-x - me 1 Sep 12:28 8xeojm03.me-backup-crashrecovery-20240901_123827 drwxr-xr-x - me 4 Sep 23:30 8xeojm03.me-backup-crashrecovery-20240905_134519 drwxr-xr-x - me 20 Sep 00:37 8xeojm03.me-backup-crashrecovery-20240920_123236 drwxr-xr-x - me 4 Oct 00:37 8xeojm03.me-backup-crashrecovery-20241004_123317 drwxr-xr-x - me 6 Oct 11:25 8xeojm03.me-backup-crashrecovery-20241006_120700 drwxr-xr-x - me 13 Oct 10:46 8xeojm03.me-backup-crashrecovery-20241014_123523 drwxr-xr-x - me 15 Oct 11:12 8xeojm03.me-backup-crashrecovery-20241015_113928 drwxr-xr-x - me 16 Oct 00:48 8xeojm03.me-backup-crashrecovery-20241016_131557 drwxr-xr-x - me 1 Sep 12:36 8xeojm03.me-old-profile-20240901_123827 drwxr-xr-x - me 21 Oct 14:06 'Crash Reports' lrwxrwxrwx - me 25 Oct 13:21 dq3euau0.default -> /run/user/1000/psd/me-firefox-dq3euau0.default drwxr-xr-x - me 25 Oct 13:21 dq3euau0.default-backup drwxr-xr-x - me 12 Oct 11:32 dq3euau0.default-backup-crashrecovery-20241014_122733 drwxr-xr-x - me 15 Oct 10:25 dq3euau0.default-backup-crashrecovery-20241015_113136 drwxr-xr-x - me 15 Oct 11:40 dq3euau0.default-backup-crashrecovery-20241016_130659 drwxr-xr-x - me 16 Oct 13:17 dq3euau0.default-backup-crashrecovery-20241018_150829 drwxr-xr-x - me 23 Oct 13:46 dq3euau0.default-backup-crashrecovery-20241024_135924 lrwxrwxrwx - me 25 Oct 13:16 fx5mevs0.default-release-1 -> /run/user/1000/psd/me-firefox-fx5mevs0.default-release-1 drwx------ - me 25 Oct 13:16 fx5mevs0.default-release-1-backup drwx------ - me 5 Oct 10:29 fx5mevs0.default-release-1-backup-crashrecovery-20241006_115712 drwx------ - me 9 Oct 12:31 fx5mevs0.default-release-1-backup-crashrecovery-20241010_134707 drwx------ - me 12 Oct 11:25 fx5mevs0.default-release-1-backup-crashrecovery-20241012_184114 drwx------ - me 12 Oct 11:25 fx5mevs0.default-release-1-backup-crashrecovery-20241013_101056 drwx------ - me 12 Oct 11:25 fx5mevs0.default-release-1-backup-crashrecovery-20241014_122700 drwx------ - me 15 Oct 10:19 fx5mevs0.default-release-1-backup-crashrecovery-20241015_113118 drwx------ - me 15 Oct 13:04 fx5mevs0.default-release-1-backup-crashrecovery-20241016_130647 drwx------ - me 16 Oct 13:17 fx5mevs0.default-release-1-backup-crashrecovery-20241018_150811 drwx------ - me 23 Oct 13:38 fx5mevs0.default-release-1-backup-crashrecovery-20241024_135915 drwxr-xr-x - me 23 Oct 13:49 'Pending Pings' .rw-rwxr-- 117 me 4 Oct 14:40 installs.ini .rw-rwxr-- 459 me 4 Oct 14:40 profiles.ini
The profile in use is "8xeojm03.me" (user name redacted).
And here is the contents of the /run/user/1000/psd directory:
drwx------ - me 25 Oct 13:15 me-chromium drwxr-xr-x - me 25 Oct 16:41 me-firefox-6elupd8w.default-release drwxr-xr-x - me 25 Oct 16:47 me-firefox-8xeojm03.me drwxr-xr-x - me 25 Oct 16:41 me-firefox-dq3euau0.default drwx------ - me 25 Oct 16:46 me-firefox-fx5mevs0.default-release-1
I haven't a clue why there is one for Chromium; I don't have that installed. I wonder if Garuda Linux then set this up as a way to centralize browser profiles, or perhaps for better access in RAM. If that's the case, awfully short-sighted.
|
|
||
Comment 6•1 year ago
|
||
Looks like maybe you have a tool installed called "Profile Sync Daemon"? It's not something I've ever come across before but looks like it works by making your profile folder a symlink to a tmpfs RAM disk to give faster disk I/O. I wouldn't be surprised at all to find that this was messing with our locking strategy.
|
|
Reporter | |
Comment 7•1 year ago
|
||
Huh. So I do. I wrongfully assumed this was a Firefox configuration, even though I didn't observe this behavior or structure on the prior installation. Much appreciated!
Description
•