joplin icon indicating copy to clipboard operation
joplin copied to clipboard

High cpu usage / hanging system when opening Joplin under Wayland

Open diogogomes opened this issue 4 years ago • 51 comments

Environment

Joplin version: 2.1.9 (this issue already existed in some previous versions) Platform: Linux OS specifics:

  • Arch with Plasma
  • Centos 8
  • Debian 10 with Gnome Desktop with Wayland
  • Fedora 32

Steps to reproduce

  1. Log in in a Gnome session with Wayland / Mutter 1.Click to open the Joplin app
  2. Wait until system hangs and/or crash

Describe what you expected to happen

It's expected the application opens normally without hanging the machine when using the Wayland protocol.

Notes

This only happens under the Mutter window manager and Wayland. Joplin opens immediately with normal cpu usage under other window managers.

Urls

Mutter

Logfile

Log from the terminal: (electron) The default value of app.allowRendererProcessReuse is deprecated, it is currently "false". It will change to be "true" in Electron 9. For more information please check https://github.com/electron/electron/issues/18397

Log from developer tools:

DevTools failed to parse SourceMap: file:///tmp/.mount_joplinywn0Xg/resources/app.asar/gui/ResourceScreen.js.map
/tmp/.mount_joplinyw…r/lib/logger.js:126 23:12:28 Starting Clipper server on port 41184
/tmp/.mount_joplinyw…evelopment.js:11494 Warning: componentWillReceiveProps has been renamed, and is not recommended for use. See https://fb.me/react-async-component-lifecycle-hooks for details.

* Move data fetching code or side effects to componentDidUpdate.
* If you're updating state whenever props change, refactor your code to use memoization techniques or move it to static getDerivedStateFromProps. Learn more at: https://fb.me/react-derived-state
* Rename componentWillReceiveProps to UNSAFE_componentWillReceiveProps to suppress this warning in non-strict mode. In React 17.x, only the UNSAFE_ name will work. To rename all deprecated lifecycles to their new names, you can run `npx react-codemod rename-unsafe-lifecycles` in your project source folder.

Please update the following components: Connect(NoteTextViewerComponent), Connect(NoteToolbar), Connect(TagItemComponent), Connect(TagListComponent), Connect(ToolbarComponent), ReactAce
/tmp/.mount_joplinyw…evelopment.js:11494 Warning: componentWillUpdate has been renamed, and is not recommended for use. See https://fb.me/react-async-component-lifecycle-hooks for details.

* Move data fetching code or side effects to componentDidUpdate.
* Rename componentWillUpdate to UNSAFE_componentWillUpdate to suppress this warning in non-strict mode. In React 17.x, only the UNSAFE_ name will work. To rename all deprecated lifecycles to their new names, you can run `npx react-codemod rename-unsafe-lifecycles` in your project source folder.

Please update the following components: Connect(NoteTextViewerComponent), Connect(NoteToolbar), Connect(TagItemComponent), Connect(TagListComponent), Connect(ToolbarComponent)
3
/tmp/.mount_joplinyw…essageHandler.js:30 Got ipc-message: noteRenderComplete undefined

diogogomes avatar Jun 19 '20 23:06 diogogomes

Environment

  • Version 1.0.223(prerelease)
  • Windows 10x64 pro

Effect

  • opens four threads (Taskmanager)
  • no window opens → no access → "useless"

Workaround

  • returned to version 1.0.220

BsNoSi avatar Jun 20 '20 12:06 BsNoSi

I updated the issue with logs from terminal and developer tools (I'm waiting for the log.txt been populated with information).

@laurent22, you removed the bug tag for some reason related to the lack of logs or because you do not consider a bug? Thank you.

this issue already existed in some previous versions

diogogomes avatar Jun 20 '20 22:06 diogogomes

The GitHub tracker is only for actionable issues, and unfortunately while this bug might happen in your computer it's not possible to replicate it on our side. The log is just the usual warnings.

laurent22 avatar Jun 20 '20 22:06 laurent22

Does it happen with all the notes or just some of them?

And isn't it the same as this bug https://github.com/laurent22/joplin/issues/3114

laurent22 avatar Jun 20 '20 22:06 laurent22

Understand (about the tracker).

It's happening when I try to open the app. I'm aware of the issue with the kernel 5.5 but I missed the references to the high cpu usage and I decided to open this issue.

Can be related. I'll try later with a lower version of the kernel on another machine to be sure if is related or not.

I'll leave a message then. Thank you

diogogomes avatar Jun 20 '20 23:06 diogogomes

I tested on another machine with kernel 4.19 and the result was the same: high processor usage when the application is opened.

diogogomes avatar Jun 26 '20 00:06 diogogomes

(For me) Solved with → Joplin 1.0.224 (prod, win32) Revision: 1899d866 (master)

BsNoSi avatar Jul 03 '20 09:07 BsNoSi

For me, the problem persists in the version 1.0.224.

diogogomes avatar Jul 04 '20 22:07 diogogomes

The issue persists in the version 1.0.227 and kernel 5.4, 5.5, 5.6 and 5.7.

Note: Related with Gnome Shell and not with kernel?

diogogomes avatar Jul 23 '20 12:07 diogogomes

@laurent22, I just made some progress to debug this issue.

This only happens under Wayland protocol. Joplin opens immediately with normal cpu usage under Xorg.

Wayland webpage

Please tell me if I can help providing more information.

diogogomes avatar Jul 23 '20 13:07 diogogomes

Ive been stuck on 1.0.179 on fedora 32 for this very reason (ie I get the same electron message and then nothing). I havent tried reverting the kernel because:

  • I dont really want to run an old kernel just for a note app
  • I heard that the kernel issue had been resolved?

I keep trying every release (and some pre-releases) to no avail :( (FYI I am using appimage home & config directories to keep attempts with other releases separated from my 1.0.179 data so they should be running clean)

isaiahfrantz avatar Jul 27 '20 17:07 isaiahfrantz

I updated the issue with the Fedora 32.

@isaiahfrantz, can you test with Xorg and tell me if the issue persists?

I heard that the kernel issue had been resolved?

I tested with the old 4.19 kernel and I suspect this issue is not related with the kernel.

diogogomes avatar Jul 27 '20 23:07 diogogomes

The issue persists in the version 1.0.233.

diogogomes avatar Aug 02 '20 23:08 diogogomes

The issue persists in the version 1.0.242.

diogogomes avatar Sep 07 '20 15:09 diogogomes

I have been following these types of threads since 1.0.207 (the last version that worked for me) I've just discovered a fix for my situation, maybe it will help others. While trying to find some smoking gun I came across the fact that I could not update nodejs. `Error: Problem: cannot install both nodejs-2:14.11.0-1nodesource.x86_64 and nodejs-1:10.19.0-2.module_el8.1.0+296+bef51246.x86_64

  • package npm-1:6.13.4-1.10.19.0.2.module_el8.1.0+296+bef51246.x86_64 requires nodejs = 1:10.19.0-2.module_el8.1.0+296+bef51246, but none of the providers can be installed
  • cannot install the best update candidate for package nodejs-1:10.19.0-2.module_el8.1.0+296+bef51246.x86_64
  • problem with installed package npm-1:6.13.4-1.10.19.0.2.module_el8.1.0+296+bef51246.x86_64 ` After removing npm Joplin works as expected. NAME="CentOS Linux" VERSION="8 (Core)" KERNEL="4.18.0-193.14.2.el8_2.x86_64"

JCTechSol avatar Sep 17 '20 13:09 JCTechSol

Well that was short lived. It hangs again now on launch...I really don't know why. I even installed 1.1.4 and still hangs on launch...

JCTechSol avatar Sep 21 '20 13:09 JCTechSol

Since the upgrade to 1.1.4 I can launch the AppImage from terminal and it will open without hanging. At least there is a work around...

JCTechSol avatar Sep 21 '20 13:09 JCTechSol

@JCTechSol, I have been using the terminal method but sometimes I have to cancel the process and start again to work.

I did some testing with Debian Unstable with a newer version of xwayland and it seems to have worked well.

Still, I can't confirm that it's due to xwayland because I ran out of time to continue my tests.

diogogomes avatar Sep 25 '20 15:09 diogogomes

Today I wasn't able to open Joplin from terminal. It froze just like with the app shortcut. After repeated attempts and combinations I was able to get it to launch after I tried lunching an old version. It presents an error message about the database being newer then expected. After I press OK and dismiss that, I can then open the appimage of 1.1.4 successfully. I'm not sure why that combination works.

JCTechSol avatar Sep 28 '20 13:09 JCTechSol

There is some more oddities with this workaround as well. I've discovered that if I try lunching the 1.0.241.AppImage it doesn't work, in fact it will crash the computer. But if I try lunching the 1.0.207.AppImage the database error successfully pops up saying that the database is newer then expected etc. Then I can successfully lunch the 1.1.4.Applmage. It seems like such a random piece of information but I can faithfully reproduce this behavior every time so I think its significant.

JCTechSol avatar Oct 05 '20 12:10 JCTechSol

Hi, I am on Debian 10 and use the .deb from github releases. Same issue: Joplin freezes the system on Wayland. This is very counter-productive :( I lost some unsaved work and computations.

smalltimer avatar Oct 11 '20 08:10 smalltimer

Update: The issue persists in the version 1.2.6.

diogogomes avatar Oct 13 '20 14:10 diogogomes

I can also confirm the same behavior is present in 1.2.6. Also the same workaround works. Launching the 1.0.207 appImage, click ok on the error message, then launching the 1.2.6 appimage

JCTechSol avatar Oct 19 '20 17:10 JCTechSol

I haven't be able to do a lot of testing but it appears 1.3 won't run at all. Thankfully I am still able to run 1.2.6 with the workaround as it looks like no modification\upgrade has happen on the database. (Launching the 1.0.207 appImage, click ok on the error message, then launching the 1.2.6 appimage)

JCTechSol avatar Nov 09 '20 13:11 JCTechSol

So I've just installed 1.4.18 using the recommended method ( wget -O - https://raw.githubusercontent.com/laurent22/joplin/dev/Joplin_install_and_update.sh | bash) and it opened up flawlessly....I'm excited but cautious. I will do some more testing and update here again...

JCTechSol avatar Nov 30 '20 13:11 JCTechSol

After a reboot now Jopin won't open at all. Not even the work around works any more. Tried updating to 1.4.19, no change. Installed the latest CentOS 8 update, no change. I can't access my Joplin notes at all now...

JCTechSol avatar Dec 07 '20 16:12 JCTechSol

Removing the following folders and reinstalling using the recommended wget method fixed the issue. Joplin will now open again... ~/.joplin-bin ~/.joplin ~/.config/@joplin ~/.config/Joplin ~/.config/joplin-desktop

JCTechSol avatar Dec 07 '20 19:12 JCTechSol

Reboot seems to break things. I had to remove the folders again and reinstall. I tried just removing the ~/.joplin folder and reinstalling but it still crashed. I had to remove all 4 and reinstall to get it to work again.

~/.joplin ~/.config/@joplin ~/.config/Joplin ~/.config/joplin-desktop

The only thing that I change or configure after install is:

  1. Configure darkmore in appearance
  2. Setup dropbox sync
  3. Set encryption to decrypt the notes.

I wonder if one of these is responsible for the crashing behavior...

JCTechSol avatar Dec 14 '20 13:12 JCTechSol

It seems that deleting ~/.config/@joplin and ~/.config/joplin-desktop are enough to get it working again. I will test to see if darkmode has anything to do with it...

JCTechSol avatar Dec 21 '20 13:12 JCTechSol

man this problem keeps getting stranger and stranger... Test darkmode, not the issue here, with our without darkmode the same crash is experienced on opening. That leaves encryption\dropbox and related to the issue.

I tested this morning with 1.5.11.... same issues. I wanted to test my old workaround of opening an old version, getting an error prompt and then opening the new version, BUT instead of giving me an error prompt, joplin.1.2.6.AppImage actually opened! I was not expecting this and thought this might be bad news for my notebook. But I noticed something I've never seen before, a conflict notebook in red. It had a copy of one of my notes in it. I examined it closely and did not notice any issues or differences from the actual note. Just to be sure I wanted to export it but I wasn't able to. Joplin would go through the motion and create the _resource folder but nothing else and no data was in the _resource folder. I could export other notes, just not this conflict one. So I decided to delete the conflict note, sync and close. I was then able to open 1.5.11 with no issues....

Was the problem this whole time!?!? A corrupted conflict note?!?!?! That would explain why it would only open if no notebook was existing and would break after I synced it.

If this is indeed the root issue. Is there anyway this can be identified or cleaned up instead of just hanging?

JCTechSol avatar Dec 28 '20 14:12 JCTechSol