(Bug report) Uncaught Exception: Error: write EPIPE

[user171]

Trilium Version

0.49.3-1

What operating system are you using?

Other Linux

What is your setup?

Local (no sync)

Operating System Version

Arch Linux

Description

On Arch Linux, Trilium is installed using AUR, since a system update from a week or 2, when I launch Trilium now I get a popup window with the title: A Javascript error occurred in the main process.

That window has the following content:

Uncaught Exception:
Error: write EPIPE
  at afterWriteDispatched (node:internal/stream_base_commons:164:15)
  at writeGeneric (node:internal/stream_base_commons:155:3)
  at Socket._writeGeneric (node:net:780:11)
  at Socket._write (node:net:792:8)
  at writeOrBuffer (node:internal/streams/writable:389:12)
  at_write (node:internal/streams/writable:330:10)
  atSocket.Writable.write (node:internal/streams/writable:334:10)
  at console.value (node:internal/console/constructor:289:16)
  at console.log (node:internal/console/constructor:363:26)
  at log (/opt/trilium-bin/resources/app.asar/src/services/log.js:58:13)

That window keeps popping up, rendering the application unusable.

I have updated all my packages and rebuilt Trilium through yay (AUR).

[zadam]

Hi, I have no idea about AUR packages, but you could try the official binaries: https://github.com/zadam/trilium/releases

[user171]

What the AUR package does is simply installing the binary, in a clean and convenient way. You can see what it does here, it's pretty straightforward: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=trilium-bin

Yet, I have downloaded the binary as per your instructions and the same error happens. Any idea to solve it is welcome. I will notify the AUR package maintainer as well in case this is something specific to Arch Linux.

[francois2metz]

I have the same error with the debian package (debian unstable), version 0.50.1 and remote sync.

It happens from time to time, when it does it's at least on every keystroke. Restarting the application fix the problem for a while.

[user171]

Trilium is advertised as being a tool to build large personal knowledge bases. I want to be a believer and keep on building my own knowledge base with Triulium. But, we need to take into account that a knowledge base is a very important work, both in terms of the energy that it takes to build, and also the usefulness of that resource when one needs to access it.

If Trilium can crash so easily and lock the users out of their own knowledge base, then it beats the purpose of even building this software.

I believe one the main features of Trilium should be its stability.

Right now I can't access my knowledge base and there's not much to be done about it. That greatly reduces my confidence in the software. The advantages of using Trilium over a simple file system are obvious. But the stability of the filesystem still makes it a better choice. That's too bad.

Let's try to improve that with your help @zadam . I'm not a javascript dev, but I can still follow your instructions if you want to try to debug that. I understand through your previous comment that you prefer to give support to official binaries. As I said earlier, the AUR package is just a clean way to manage external packages from within the OS package manager, but the package coming from the AUR is the official binary.

Could it be anything related to a library? Are there any test I can do in order to conceal the bug?

Apart from that, how can I recover my notes without being able to launch Trilium?

Thanks.

[zadam]

The only "officially supported" distro is Ubuntu, meaning that's the only one I test.

The problem with this error is that it's very low level, something on the level of electron interaction with the system, it's not coming from an application code. That's difficult to debug without diving into the distro's specifics.

There are 2 options:

• you can use the "server edition" which uses vanilla node.js (which you can replace with arch node.js) and I assume there won't be such problems there
• if you want to "jump ship", you can use dump db tool to extract the contents of the document.db into a directory tree of notes.

It might be also worth trying to build Trilium binaries on arch (bin/build-linux.sh in checked out stable branch), but that might be more involved.

[Dialga]

I've hit this same bug as well, I was about to report it but will add to your issue. Also using the trilium-bin package from the AUR in Arch Linux x64, the latest version 0.50.2. I left trilium open overnight and came back to this exact same error the next day. In journalctl I see app-trilium ... Consumed 22min 8.406s CPU time. and app-trilium...scope: Consumed 10.205s CPU time., 40 seconds apart. Seems like some reoccurring job is getting stuck, consuming alot of cpu time, and resulting in EPIPE. I don't know if it's relevant, but my document.db seems to have just hit 100mb (105041920), backup-daily.db is 99mb. As such I as a user can no longer access my own data, much like @user171.

[Dialga]

@user171 @francois2metz what is the size of your document.db? Perhaps that might narrow down the error.

[user171]

Hi, @Dialga , my document.db is 3.9M.

I find it unfortunate that this software architecture is coupled to an OS. I have successfully recovered my data and transferred it to another solution.

Thanks for your work.

[Nriver]

You are welcome to use Manjaro, which is based on arch. I've been using Trilium on Manjaro for a year and everything works well. Trilium's note data is very important, therefore I always use Trilium package from github release not AUR, just to prevent from an unrecoverable update like you experienced.

[Dialga]

The AUR PKGBUILD uses the build from github release, so your point is moot.

[user171]

Re-installing an operating system in order to use Trilium? Thanks, I'll think about it.

[Nriver]

The AUR PKGBUILD uses the build from github release, so your point is moot.

Some PKGBUILD always use latest build and deps, sometimes make application not working. It may take hours or days to find a proper solution. I couldn't risk that for important app like Trilium.

[Nriver]

Re-installing an operating system in order to use Trilium? Thanks, I'll think about it.

It's just a suggestion for your next new machine's OS. Less pain in head.

[cmuench]

I also use Arch Linux and Trilium. I have also sometimes this issue and tried to kill the trilium-bin. That does not help. What I see is that it's always fixed on my machine if I reboot.

[renyuneyun]

I'm using Arch (with trilium-bin package from AUR) and my recent experience is similar to @francois2metz : this error sometimes pops up. It used to work correctly without any issues, so this must be related to some recent updates. I'm generally satisfied with trilium, and am currently reassured (by the various mechanisms) the data won't be lost. But fixing this error would be clearly much more reassuring...

[zadam]

There has been some progress in creating a flatpak build so this would be one way to resolve this issue.

[cmuench]

Short update. I had no issues in the last days with Trilium on Arch Linux. Maybe the issue was fixed in Electron or somewhere else.

[TiZ-HugLife]

I'm using the Flathub package for Trilium, and I switched from KDE Neon 5.25 (based on Ubuntu 20.04) to Kubuntu 22.04 and started experiencing this when starting up Trilium with the rest of my system. The only thing different from the original report is that the last line of the stack trace says line 65 instead of 58.

It goes away if I give a flatpak kill com.github.zadam.trilium and then restart it, which causes me to try to ask what is different between the startup and regular invocation. On startup, I am piping all of Trilium's output to syslog using the logger utility. So for some reason, on KDE Neon / Ubuntu 20.04, that works fine, and on Kubuntu 22.04, it does not work fine. Other Electron apps from Flathub don't freak out like this.

So this could be caused by a bad interaction with syslog.