Closing (flatpak) Mailspring fails and eats all CPU

[tomastan]

On app quit the indicator disappears, however mailsync.bin processes remain and eat all CPU.

Description

After quit, there are still processes hanging

$ ps ax |grep mailspring
2373309 ?        Sl     0:00 /usr/share/mailspring/chrome_crashpad_handler --monitor-self-annotation=ptype=crashpad-handler --no-rate-limit --database=/home/user/.config/Mailspring/Crashpad --url=https://id.getmailspring.com/report-crash?ver=1.18.0&platform=linux --annotation=_companyName=Mailspring --annotation=_productName=Mailspring --annotation=_version=1.18.0 --annotation=lsb-release=Fedora Linux 43 (Workstation Edition) --annotation=plat=Linux --annotation=prod=Electron --annotation=ver=39.2.7 --initial-client-fd=41 --shared-client-connection
2373642 ?        Sl     0:00 /usr/share/mailspring/resources/app.asar.unpacked/mailsync.bin --mode sync --info ***@gmail.com
2373646 ?        Sl     0:00 /usr/share/mailspring/resources/app.asar.unpacked/mailsync.bin --mode sync --info ***@gmail.com
2373650 ?        Sl     0:00 /usr/share/mailspring/resources/app.asar.unpacked/mailsync.bin --mode sync --info ***@gmail.com

To Reproduce…

Steps to reproduce the behavior:

1. Open Flatpak version
2. Close the app

Expected Behavior

App closes normally

Screenshots

Setup

• OS and Version: Fedora 43
  • Installation Method: Flatpak (flathub)
• Mailspring Version: 1.18.0

[tomastan]

Actually this is not Flatpak related, the same happens with RPM package for me in 1.19.0.
Same issue reported later by another user:

The program's background processes continue to run even after it is closed

Description I encountered this issue on an Arch Linux KDE Wayland system. When closing the program, the system error message shown in the image appears, and the program’s processes continue to run in the background. Every time the program is started and then stopped, the running background processes multiply and can consume all available memory. Screenshots [Képernyőkép_20260316_103554] Setup OS and Version: Arch Linux Installation Method: AUR Mailspring Version: 1.19.0 Additional Conte…

[bengotow]

Hey Toma – Mailspring 1.19.1 includes an upgrade to Electron 41, which brings significant updates to the Chromium and Node.js runtimes. This may help with the zombie process issue you’re seeing on close, as there were known improvements to process lifecycle handling. There are also Wayland-specific fixes (GTK drop shadows, extended resize borders) that improve stability on Linux. Please update to 1.19.1 and let me know if the lingering mailsync processes are still an issue — if so I’ll investigate further.

[tomastan]

Sure, thanks for comment. Will try once 1.19.1 reaches Flathub.

[LinusDierheimer]

I had the same problem on my system, and fixed it coincidentally while packaging the flatpak.
On Linux, the “mailsync” shell script calls the “mailsync.bin” binary. When closing, the shell process is terminated, leaving the mailsync process hanging, which in turn causes it to behave buggy.
In the latest flatpak, i do not use this shell script, instead “mailsync” is directly the binary. Since then closing works as expected.
@bengotow using exec to call “mailsync.bin” will probably fix it for other distribution methods too, as the shell process will then get replaced by the mailsync process.

Will try once 1.19.1 reaches Flathub.

It already did and should work because of the reasons above. It just shows up as 1.19.0 because of The 1.19.1 release is incomplete.

[bengotow]

Oh that’s a super interesting find - let me see if I can repro and fix that, I wonder if the behavior of the mailsync.bin wrapper is slightly different on macOS and Linux. We may be able to inject the env vars and libs directly from the mailsync process too.

[tomastan]

@LinusDierheimer

Will try once 1.19.1 reaches Flathub.

It already did and should work because of the reasons above. It just shows up as 1.19.0 because of The 1.19.1 release is incomplete.

Unfortunately I still see old update date. And more importantly the app does not update.

[LinusDierheimer]

@bengotow

We may be able to inject the env vars and libs directly from the mailsync process too.

Flatpak wants to use the system libsasl. It uses its own version of mailsync/build.sh, in which i simply left out all SASL_PATH related stuff, like copying the libraries to app/. Hence why i also skipped creation of the wrapper. Please keep in mind that if it gets hardcoded, package formats that ship their own runtime will either require extra patching, or need to duplicate a lot of libraries, increasing package size.

@tomastan

Unfortunately I still see old update date. And more importantly the app does not update.

What you see is the time since the last release according to the appdata file, which is fixed to 1.19.0 from 2026-03-09. When you hover it however, you will see that the latest build is not even a day old. More importantly, after a flatpak update and Mailspring restart, you should see that it is version 1.19.1 in the “Help” menu.

[tomastan]

You are right, Flathub shows newer timestamp on hover. Thanks, didn’t know that trick

Looks now all processes closes correctly! Thanks guys! Nice work!