Joplin Freezing on Linux Distros Running Kernel 5.5 Bug Update

Support
1

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:

  1. 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.
  2. 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
  3. 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:

  1. 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.
  2. 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:

  1. 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)
  2. 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.

UPDATE 05-17-2020:

4 Likes
2

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.

4

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.

1 Like
5

Fixed that. Whoops. Itā€™s the component maintainers not the kernel ones that issued the fix. It could still be turned down in main branch, so hereā€™s to hoping.

Either way, Electron 8 definitely has some fixes for other Linux specific bugs or just plainly doesnā€™t have the problem code.

6

Electron 8.1.0 just released and the bug is still present.

1 Like
7

5.5.9 just released and the fix alluded to previously hasnā€™t been implemented yet.

8

One of the people helping me with this bug found a quick and easy way to get around it:

  1. Whenever Joplin Freezes during sync, go to Options=>Tools

  2. Click the WebClipper tab up top

  3. Enable and then Disable Webclipper

  4. Click Apply

  5. Go back to business as usual. :smiley:

Here's a demo:

2 Likes
10

Well if you are not using web clipper service is not freezing at all.
Oups ā€¦ correction ā€¦ it froze after a couple of hours

11

You donā€™t have to be using the webclipper service on the browser. This just refreshes the entire UI causing the syncing to recommence.

12

any ETA when this will be fixed ?

I have started typing some important notes today and joplin frozed , I thought that I have I saved the notes but all lost... kinda annoying bug... :frowning:

1 Like
13

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 :sweat_smile:

1 Like
14

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.

There is no ETA for this to be fixed.

15

ā€œChanges to the kernelā€ is the narrative I keep hearing, but do we have any idea what changes those were? Are we positive this particular issue resides outside of Joplin or Electum.

16

@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.

4 Likes
17

I have installed the latest Kernel Linux wpc 5.7.0-1-MANJARO (RC5) and so far this freezing bug does not exist :smiley:

1 Like
18

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, My Full Test Report

19

@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.

20

Hi,

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:

2020-05-18 16:01:53: "Scheduling sync operation...", "0"
2020-05-18 16:01:53: "Preparing scheduled sync"
2020-05-18 16:01:53: "Starting scheduled sync"
2020-05-18 16:01:53: "Synchronisation is already in progress. State: in_progress"

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:

2020-05-18 16:02:24: "TaskQueue.stop: syncDownload: waiting for tasks to complete: 0"
2020-05-18 16:02:24: "TaskQueue.stop: syncDownload: Done, waited for 0"
2020-05-18 16:02:26: "BasicDelta: Report: {"timestamp":1589814034000,"older":1603,"newer":0,"equal":1}"
2020-05-18 16:02:26: "Operations completed: "
2020-05-18 16:02:26: "fetchingTotal: -"
2020-05-18 16:02:26: "Total folders: 7"
2020-05-18 16:02:26: "Total notes: 339"
2020-05-18 16:02:26: "Total resources: 39"

Iā€™ll continue to look for any patterns, and look forward to Fedora updating the kernel to 5.6.13 to see if it changes anything.

Thanks for your efforts, and useful workaround,

James

1 Like