Firefox (Nightly) causing system crash

kc9udx

Are you mounting / with journaling?

pfr

kc9udx I haven't set it intentionally, I would have assumed that this would be the default behaviour. How/where do I set this?

pfr How/where do I set this?

fstab, check the root partition line on it.
I have, /dev/wd0a / ffs rw,noatime,nodevmtime 1 1

If you want logging, add log to the comma separated list. In my case, it would be rw,noatime,nodevmtime,log.

OT, I have time stamps disabled to avoid excessive disk writes on my SSD.

pfr

I had to reinstall the system. The disk was cooked.

Jay

pfr maybe try ArcticFox https://pkgsrc.se/www/arcticfox
I think creator of ArcticFox also uses NetBSD

Jay Maybe ... articfoxdepends on x11/gtk2, though.

nia

pin I'm still convinced GTK 2 is the best X11 toolkit. GTK 3's ideologues chose to ignore 30 years of accumulated knowledge on how to design desktop applications, and the LXDE developer found it too unsuitable for developing lightweight X11 applications such that Qt is the better option. GIMP is the application GTK was made for and it's still a GTK 2 app. Qt has so many API/ABI compatibility and build slowness issues between releases that sticking with an unsupported toolkit often seems like the better option if you're compiling from source.

pfr

Yeah I dont think Arcticfox will cut it sadly.
But I have deduced that this issues is certainly related to Firefox on my machine, and it continues even after a fresh install.

I have added log to my fstab so I wonder where those logs are kept and what the say now after a few freeze-ups...

kc9udx

pfr I've never needed to investigate that. The whole idea behind journaling is that it prevents disk inconsistencies caused by crash-during-write by logging the writes and undoing the partial part, at mount time. This eliminates the need (normally) to fsck.

I much prefer atomic write (inherently safer and much faster) but journaling is what we get with FFS (and most others these days).

pfr

kc9udx I much prefer atomic write (inherently safer and much faster) but journaling is what we get with FFS (and most others these days).

Never heard of atomic... can you provide more details? And your saying it's not an option for FFS?

@pin I don't think starting a new thread is necessary, but perhaps if we could rename this one to "Firefox (Nightly) causing system crash)...

I wanted to continue this thread because the issue is not resolved, just avoided by not not signing in to my FF account.

The last time this freeze happened, was after I had freshly installed NetBSD once more. This time I wasn't even using FF when it froze. FF was open in another workspace, and I was signed in (perhaps it was still doing some kind of syncing in the background).

The error I saw upon reboot however was interesting because it referred to the same directory /home/dave/.mozilla/firefox/y74lurkd.default-default/storage/default/ but instead of an extension it refered to a web address file beginning with https// and the web address is a site I use (for accessing a vehicle registration account) but it's not even bookmarked and I hadn't visited it in a long while.... 😕

So, now I'm using FF without signing in and so far it has been stable, but WTF...

kc9udx

pfr atomic write causes a write to be not valid until it is complete. So if you were writing a 2Gb file and your system crashed, traditionally you end up with a partial file and bad metadata. With journaling, the changes can be "undone" and the filesystem will look like it did before the crash. With atomic write, the system is in the same state as it was before the crash because the write never happened.

The only trouble I'm aware of with atomic write is that you can effectively have less disk space. That is, if you are replacing a 2G file with a completely different 2G file, on a 3G partition, there isn't enough space to store the new data before deleting the old. In practice I've never encountered this but it's kind of dumb luck that I haven't.

I don't think any "modern" filesystem uses atomic write, because journaling is "good enough", and most people misunderstand atomic write. (My best example of this is the assumption that appending a file necessitates a complete separate copy of the original file. It does not.). Also, I think by now the concept of atomic write has been totally forgotten by anyone concerned with filesystems.

pfr

kc9udx Thanks for the explaination, makes sense now.

My only remaining question then is, why is journaling not enabled by default? Why should I have to edit fstab to enable it?

https://www.netbsd.org/docs/misc/index.html#journal-options

Note that metadata journaling does not help with file corruption when a write operation is interrupted by an unclean shutdown, and can in some cases make it worse.

nia Opinions ... I disagree. Gtk2 is deprecated, whether we like it or, not.

EDIT: GIMP will soon no longer be a Gtk2 app, https://pkgsrc.se/graphics/gimp-devel

jmcunx

nia

I'm still convinced GTK 2 is the best X11 toolkit.

Yes I agree with this. Menus on emacs 29.4 is very slow to appear and sometimes hangs X for a few seconds. This is via gtk3 package.

As a test, I compiled emacs 29.4 via pkgsrc using gtk2, no issues and works much faster. I noticed the same on another BSD OS also. The gtk3 version "fails" were the gtk2 version works great.

bsduck

pin Why not port GIMP straight to GTK 4 at this point? GTK 3 is already considered legacy...

Jay

I wish to see all BSD foundations together creating own toolkit 🙂