Unable to run Inkdrop on Void Linux

Issues
1

Bug report

I’ve been eager to try out Inkdrop, but I have an issue starting it. My platform is not exactly supported by you, but I’m trying to get it to work somehow.

I’ve downloade the zip-version, unzipped it, installed the dependencies but I’m getting this error when starting:

./inkdrop
node[20600]: pthread_create: Invalid argument
  app:error Failed to start session: Error: Unknown or unsupported transport “disabled” for address “disabled:” +0ms
(node:20600) UnhandledPromiseRejectionWarning: Error: Unknown or unsupported transport “disabled” for address “disabled:”
(node:20600) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:20600) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
  Rollbar:error Received error: Over free plan monthly limit. Project id 57343 access token b1af6b4a263447d8963dfe2650804b29. +0ms

It doesn’t do anything after that.

I’ve been searching for an solution in this forum and thought it was a Void Linux specific issue.

I have checked the deb-package dependencies and installed them, I thought it might be an issue with gnome-keyring or gconf but I’ve checked the dependencies and even reinstalled them.

This pthread_create warning/error might be the cause, but I can’t really/don’t know how to debug that.

I have other Electron-based applications installed, but they’re running flawlessly.

Info

  • Platform: Void Linux w/ i3wm
  • Platform version: Rolling release
  • App Version: 3.25.3 (but cat version says v3.0.14)

Reproduce

Just unzip and start Inkdrop from a Void Linux machine.

2

Hi Michael,

Yeah, I guess it’s a keyring problem.
3.0.14 is the Electron’s version.
Inkdrop uses node-keytar to store credentials, which is also used by Atom Editor.
And I found the related issue:

Maybe it’s helpful to solve it.

3

Hey,

first of all, thanks for the quick response.

I’ve looked into node-keytar and the related issue you’ve sent. I have written a quick and dirty test for checking whether it is working correctly or not.

I can use node-keytar without any issues. ::setPassword, ::getPassword, and ::deletePassword works flawlessly.

I think the issue might be the node-keytar version. Which version is Inkdrop using?

4

Thanks for checking that.
node-keytar is 4.2.0, and it seems like the issue has been resolved in the latest version.
So I built the app with the latest keytar here:

https://s3-ap-northeast-1.amazonaws.com/inkdrop-dist/tmp/Inkdrop-3.25.3-Linux-patch-1.zip

I hope it works.

5

I’ve tried to run your node-keytar patched version, but I had no success with it. It had exactly the same output as the log in my initial post.

After that I tried using node-keytar 4.2.0 as dependency version for my keytar-test-script and it wouldn’t build. I was missing libsecret-devel (libsecret only wasn’t enough). After installing it, node-keytar test was working and I was hoping that Inkdrop would work aswell.

Well, it didn’t.

I tried installing -devel packages for some keyring dependencies (gconf, libgnome-keyring, …) hoping that this would fix the issue.

Unfortunately it didn’t.

Being suspicious, that the following line

would block the Electron rendering thread, I quickly bootstrapped an Electron 3 app.

My testapp logged the pthread_create-line aswell. It wasn’t blocking the rendering thread and the app ran fine.

6

Good news! I got it working!

After a lots of research and trial & error, I found a solution.

The issue was gnome-keyring-daemon combined with dbus. For some reason the gnome-keyring-daemon couldn’t run without dbus exporting its values.

So in the end, I had to prepare my system like one would prepare a CI system for e2e tests.

The following issue-comment was very useful:

After adapting the commands from the issue-comment, so we can actually use them, they would look like this:

export $(dbus-launch)
export $(gnome-keyring-daemon --start)

I just added these 2 lines to my .xinitrc, so they would be in my export-path at startup.

After a quick logout & login, I could finally use Inkdrop! :smile:

tl;dr for people having the same issue Add the 2 lines above to your .xinitrc, relog, use Inkdrop and be happy :raised_hands:

7

Wow, that’s great to hear!
Thanks for letting me know :wink: