Joplin: Synchronize fails after a few seconds

[matcharles]

Synchronize fails after a few seconds. This has been happening for the last little while (I was on 178 and it was doing it). I sync to a folder that I then share with syncthing. It had been working fine for the last month until this started to happen. If I modify something, then quickly sync, go to my other computer and open joplin, I will see the modifications fine.

Sometimes Joplin will stop to respond. Other times it will just spin in the bottom left without doing anything.

Environment

Joplin version: 1.0.179
Platform: Linux
OS specifcs: Arch x64

Steps To Reproduce

1. Load joplin
2. Write something
3. Sync (to folder)
4. At some point in the next 2 minutes it will either fail to respond or spin forever.

Describe what you expected to happen:

Sync normally like it used to.

Logfile

I am getting those in bash when I run joplin-desktop

../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:CRASHING:seccomp-bpf failure in syscall 0230
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:CRASHING:seccomp-bpf failure in syscall 0230
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:CRASHING:seccomp-bpf failure in syscall 0230
(node:7221) Electron: Loading non context-aware native modules in the renderer process is deprecated and will stop working at some point in the future, please see https://github.com/electron/electron/issues/18397 for more information
(node:7221) Electron: Loading non context-aware native modules in the renderer process is deprecated and will stop working at some point in the future, please see https://github.com/electron/electron/issues/18397 for more information

And I see those in the dev console:

/usr/share/joplin/resources/app/node_modules/react-dom/cjs/react-dom.development.js:12357 Warning: componentWillReceiveProps has been renamed, and is not recommended for use. See https://fb.me/react-unsafe-component-lifecycles 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(HeaderComponent), Connect(MainScreenComponent), Connect(NavigatorComponent), Connect(NoteListComponent), Connect(NoteTextComponent), Connect(RootComponent), Connect(SideBarComponent), Provider
printWarning @ /usr/share/joplin/resources/app/node_modules/react-dom/cjs/react-dom.development.js:12357

Content of log.txt for today:

log.txt

[laurent22]

Do you have very large files in your sync target? What's the largest file?

Unfortunately there's nothing abnormal in the log.

[matcharles]

I only have images, total folder size is 8mb and the biggeest image is 49kb. I have 107 different notes though, so maybe that's a problem?

I also noticed I had 2 conflict files from syncthing. I have removed them and will see if that improves. I'll get back with an update shortly.

[dimyself]

This is the same or similar bug that's happening to me that I reported on the forum and also here: https://github.com/laurent22/joplin/issues/2518 ... Mine happens without any images whatsoever. It happens with only 2 notebooks and a couple notes, only very few lines of text. There is some kind of bug with Sync. It becomes unresponsive and won't cancel. It happens several times per day even without me touching it, and can be reproduced by clicking on Sync in lower left corner a few times in a row. Then the notes/notebook windows are unresponsive and don't do anything. And it just spins forever, until it's killed

[matcharles]

Yes I confirm I experience the same thing.

[matcharles]

Duplicate of issue #2518 (Better discussion there and same symptoms)

[ChALkeR]

CRASHING:seccomp-bpf failure in syscall 0230

This is https://github.com/electron/electron/issues/22291 and is caused by an incompatibility between older Chromium/Electron and glibc >=2.31 (which recently landed in Arch).

Electron 8 is not affected, but this repo uses 7.

Backport PRs for Electron 7/6 already exist (see the link above), but are not landed/released yet.

To solve this, Electron dep should be updated either to a fixed v7 once it is released, or to v8 (which is already fixed).

[bedwardly-down]

@ChALkeR, if you can offer a PR that fixes this, the devs may take it. Just make sure you read Contribution.md in root directory and test the hell out of it because Electron 8 can break other things (like SQLite3 doesn't officially support it right now)

[ChALkeR]

@bedwardly-down the fix for this has been merged to Electron 7.1.x branch today, just updating to 7.1.x patch when it gets out would be enough here.

[bedwardly-down]

@ChALkeR that'd be an update in Master branch then. It's on v7.1.12 right now and the latest stable build was released 4 days ago.

[matcharles]

Apparently not the same bug as #2518 . Reopening for debug.

[bedwardly-down]

@ChALkeR I can confirm that this bug has shown up for the first time for me on linux-lts-5.4.22-artix-1 that just dropped in the main repos this morning. I was syncing and decrypting to the filesystem only to have the final note hang on decryption throwing this specific error.

I still stand by that it's not the same as #2518 but it definitely has finally appeared for me.

[ChALkeR]

Whoops, wrong issue. Deleted comment above =).
Moved to https://github.com/laurent22/joplin/issues/2518#issuecomment-591716872.

[ChALkeR]

Electron v7.1.14 is out, it fixes this specific issue
(the CRASHING:seccomp-bpf failure in syscall 0230 one).

Note that #2518 likely is still present there.

I highly suggest updating to 7.1.14 though to get at least this specific issue out of equation.

[stale[bot]]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

[stale[bot]]

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please feel free to create a new issue with up-to-date information.