Joplin Freezing on Linux Distros Running Kernel 5.5 Bug Update

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

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.

Electron 8.1.0 just released and the bug is still present.

1 Like

5.5.9 just released and the fix alluded to previously hasn’t been implemented yet.

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:


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

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

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

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

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.

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

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


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

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

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

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,


1 Like

I upgraded to Fedora 32 / KDE Plasma using Wayland three days ago with kernel 5.6.13-300.fc32.x86_64

Good news - the problem seems to have disappeared. Multiple new notes, changes and synchronisations and no freezes

1 Like

I just noticed something, that might be interesting.

With the current Version of joplin (1.0.218) i have the problem, that the GUI freezes instantly on startup. I can’t work with joplin.
System is openSUSE Leap 15.1 with Kernel 4.12 and wayland.

If i login with a session, i have no problems with joplin.

Should i open a new thread?