EDIT: New Bug Report Listed Here. Please add extra fixes there and whatnot.
As originally posted here after spending two weeks working on coming to a conclusion in my spare time:
I have good news:
I can officially verify with 100% certainty that this specific commit is the culprit behind this entire fiasco: torvalds/linux@339ddb5 . It was suggested earlier here and on reddit, but I had to find out on my own through testing to make sure.
Node-sqlite3 module just added official Electron 8 support in its master branch, meaning upgrading to Electron 8 in the future should be a fairly safe bet, since this was the one module that Joplin uses that I was scared would break the most on upgrade. mapbox/node-sqlite3@dc30669
There is a bit of talk about this particular issue being fixed in the next official Electron 8 release (with a partial fix implemented in 8.0.3). I’m having problems finding the source here, though, so I could be terribly mistaken.
The bad news:
If you use the btrfs filesystem for your harddrives, I’ve found that on the latest 5.5 releases after reverting the epoll commit above, there’s a chance that you won’t be able to boot properly. It’s a bit random when it happens, and I haven’t figured out a set pattern yet, so no bug report ensuing upstream there.
There is no set release date or timeline that I can find for an official stable release to be deployed for Electron 8.0.4 or Node-Sqlite3 4.1.2 (or whatever they decide to use for versioning for that release).
There are two solutions to this problem that should fix the issue for most users here:
Revert to the latest Kernel 5.4 release (whether it be the LTS release from your distro’s repos or a custom build if you know what you’re doing with building your own kernel)
Cloning the official github repo, patching it to the latest kernel.org release, and reverting the above commit and running that kernel with the caveat above and the possibility of other issues arising.
@laurent, if you are able to wait for Node-SQLite3 to release their next release, I don’t really see any other major hurdles for upgrading to Electron 8 for the time being. It would definitely be good to fully test it and I did find one minor UI bug on 5.4 involving creating new ToDo lists breaking the placement of the editor in the app and needing to be restarted.
Kernel 5.5.7 and 5.5.8 both are still showing this bug. The maintainers of the broken commit have acknowledged it and issued a fix but when it’ll show up in the main kernel is up in the air. Thanks for your patience all.
Great, nice to see that kernel developers know about this bug and intent to fix it. We can indeed also upgrade to Electron 8 and the latest SQLite if you think that can fix the issue. We’ll do so at some point in any case.
The linux kernel is going through a very screw phase now. Even as early as 5.4 kernel, many sound cards are not working and this has caused a huge uproar among people who recently updated to Ubuntu 20.04. 5.5 and 5.6 are even buggier, so all we can do is be patient
If you go to the first link in the original posting here, you'll see that we're trying to get to the bottom of it but as @RedDocMD said, this is a bug that may not be fully fixable anytime soon due to changes in the kernel breaking things for users. If you check here, Laurent is trying to work together a possible bandaid fix for it based on what I and a few other users have found through testing.
@t0dd, if you read the issue tracker, we do know for certain what Kernel commit was the bad one. I went through the process of bisecting the kernel and other sources confirmed it. The specific commit definitely affected a small handful of other Electron apps that used async in their implementations (such as a Protonmail Client) and also affected the Dart framework. The issue is also very specific to only asynchronous input output calls, which Joplin uses for both two way syncing between the server and the client and checking for changes between the two. We also do know that it is directly tied to the synchroniser.js file used by all clients but none of us involved, even the devs, know exactly how to fully fix the issue.
Of course, knowing what is broken in Electron would definitely be a great step in the right direction but we haven’t really dabbled in that yet. Electron 8 on does not solve the problem and without knowing the specifics about where it is broken there (if it is in fact in Electron), there’s no full way to write a bug report upstream that would be taken seriously and actually be addressed. If you have ideas on how to test that side of things, feel free to pitch in.
Thanks for the update, @wolfyrion. It looks like 5.5 is no longer going to receive updates which means that 5.6 could possibly receive upstream patches from 5.7 if some of 5.5’s issues get resolved there.
I’m working on testing it out myself, so wish me luck. If you can share your info on the Issue Tracker linked in the original post, that would be lovely. That way others can test it out.
EDIT: I also have 5.7 running right now (built it from source) and it’s running better but the issue did show up again; just not quite the same. Instead of the UI fully freezing like before, the Synchronize button is still hanging a bit and the Cancel button is unresponsive. I need to test it a bit more and see what the others say.
@wolfyrion, do you know if any of your packages have pulled in the xorg-server-xwayland package by some chance? I think I just figured out a dividing factor here that’s not kernel related but can definitely give similar results as this bug.
@laurent, I’m trying to see if anyone else can verify this. There are two main rendering stacks for Desktop apps on Linux: X11 (old but stable) and Wayland (its newer replacement that isn’t fully supported by everything yet and might never be). Using the Wayland stack with the X11-compatibility package, I get this issue regardless of kernel release but have only been using it as my main for under two weeks now.
EDIT: X11 and Xwayland do not seem to have an effect here. It looks 5.6.13 and 5.7 both fixed this particular issue and thanks to another user, my results seem to be a Nextcloud syncing problem that is unrelated to this particular issue but I’ve found to be fixed by using davfs to mount a local Nextcloud instance and filesystem sync in Joplin. Possible solution written here.
Summary: Fedora 32, Gnome 3.36.2, Wayland, Kernel 5.6.12-300.fc32.x86_64 freezes - anticipating the next kernel update!
I’ve been suffering from a random UI freeze when editing, which looks very similar to that shown in your workaround MP4. After editing a note, the UI partially freezes with notes, the drop-down menus and ‘Synchronise’ button clickable with no visible effect, however after monitoring the Joplin log (tail -f ~/.config/joplin-desktop/log.txt), the Sync button does do something:
My non-workaround has been to copy the text from the last edited note, close and reopen Jopin, then past the new text back in and immediately sync. Your workaround of toggling the Web Clipper settings has worked for me today and gave the following log: