Yes, it’s consistent, almost daily. But not everytime. I really don’t see a nice pattern.
Sometimes directly after waking up and installing a package, sometimes when idling for an hour during lunch, sometimes not. I’m really sorry that I can’t find a pattern.
However, it only crashes with pacman/flatpak.
I ran all the commands and no crash; however, that does not mean much because afterwards, I ran pacman and it also didn’t crash. I’m trying later.
No, I’m using flatpak update on the terminal (or rather topgrade). It also happens with the (very ugly) bauh.
Strange and strange.
Since I cannot reproduce the matter 
I have no more ideas.
Revert this to the use the ‘normal’ .cache folder and check if firefox changes behavior.
The topic on Arch BBS hasn’t been marked as solved yet - but I am fairly certain it boils down to a change in Firefox configuration.
Not all pacman hooks is triggered on every package installation - and I have a hard time understanding why you are getting this issue - especially since you are 1 out of 2 - at the moment - reported issues - this topic and the Arch BBS topic.
Perhaps you already did as it was mentioned before
Check the script /usr/share/libalpm/scripts/systemd-hook if the conditional exec contains
udev-reload)
udevd_live
/usr/bin/udevadm control --reload
if [ ! -e /etc/systemd/do-not-udevadm-trigger-on-update ]; then
/usr/bin/udevadm trigger -c change
/usr/bin/udevadm settle
fi
;;
If it does then you can touch the condition file to see if it makes any difference
sudo touch /etc/systemd/do-not-udevadm-trigger-on-update
Just did, and unfortunately, firefox just crashed again with both profiles (one with the cache in the ramdisk and one reverted).
I ran pamac install ibus which installed ibus and libibus.
The log:
:: Synchronizing package databases...
mesa-nonfree is up to date
core is up to date
extra is up to date
sublime-text is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
Packages (2) libibus-1.5.29-3 ibus-1.5.29-3
Total Installed Size: 116.80 MiB
:: Proceed with installation? [Y/n] y
(2/2) checking keys in keyring [-------------------------------------------------] 100%
(2/2) checking package integrity [-------------------------------------------------] 100%
(2/2) loading package files [-------------------------------------------------] 100%
(2/2) checking for file conflicts [-------------------------------------------------] 100%
(2/2) checking available disk space [-------------------------------------------------] 100%
:: Processing package changes...
(1/2) installing libibus [-------------------------------------------------] 100%
(2/2) installing ibus [-------------------------------------------------] 100%
:: Running post-transaction hooks...
(1/9) Reloading user manager configuration...
(2/9) Arming ConditionNeedsUpdate...
(3/9) Updating system dconf databases...
(4/9) Compiling GSettings XML schema files...
(5/9) Probing GTK2 input method modules...
(6/9) Probing GTK3 input method modules...
(7/9) Updating icon theme caches...
(8/9) Updating GTK4 module cache...
(9/9) Updating the desktop file MIME type cache...
When running it again, it doesn’t crash. One of the hooks might be the culprits.
udev reloading doesn’t seem to be the issue. Typically, when running this command, my screen flashes but it doesn’t kill anything.
Ok, so I’ve found the bad hook. It is update-desktop-database. 
I don’t know how to proceed from here.
1 Like
Can confirm it’s that particular hook. Ran the command in it manually, and it insta-noped Floorp and Thunderbird.
I’m running Plasma 6.0.3/Wayland, and triggering sudo /usr/bin/update-desktop-database doesn’t cause any crash neither for Firefox nor Thunderbird.
Except for Firefox that always display “Restart Firefox” when it gets updated, which I consider normal to reload the app to use the new libraries.
1 Like
In my case, it doesn’t happen everytime I install of update, so it was difficult to trace it.
Since the last update, Firefox did not crash during any update or executing update-desktop-database.
I don’t know which update was responsible for this, maybe Firefox itself because I’ve personally submitted around 500 crash reports.
Or maybe it was something else.
(For me this issue is resolved but I don’t know how.)
1 Like
