Linux: Mailspring fails to activate already-running instances


The Mailspring “single instance” code on Linux is very unreliable. Launching Mailspring will sometimes bring up the existing instance (as intended). Other times, usually after a long wait (it seems), it will instead start a new instance, upon which further calls to the “mailspring” command will bring up that new instance, while the old one also runs in the background simultaneously. After enough time passes, even the new instance will be “forgotten” and the “mailspring” command will spawn yet another instance.


The first instance was the auto-started one at system startup. The second was created when I attempted to launch the Mailspring app.

To Reproduce…

Steps to reproduce the behavior:

  1. Install Fedora Workstation 36. You can use a virtual machine, I guess.
  2. Install the AppIndicators GNOME extension, so that you can see Mailspring’s tray icon.
  3. Install Mailspring from the native RPM installer on your website.
  4. Set Mailspring as GNOME’s default mail client.
  5. Bind the GNOME Settings: Keyboard: Launchers: Launch email client to a key, such as Super+E.
  6. Reboot the computer and let Mailspring launch at startup.
  7. Wait and just do other stuff for a few hours (I really don’t know how long it takes). Don’t open mailspring.
  8. When you finally press Super+E to launch your email client, it will open a new instance of Mailspring instead of activating the existing one. Closing the new instance and running the command again will yet again spawn a new instance. Same thing if you manually run “mailspring” command in a terminal.
  9. If you try to run further instances of Mailspring when the NEW one has spawned, that one will continue getting focus as intended, but if you wait long enough, even that one will be “forgotten” and extra/new instances will spawn instead.
  10. This issue never happens when a Mailspring instance is “fresh”. A fresh instance will always activate itself properly. But given some time, every new instance is forgotten in the end, and the duplicate issue appears.

Expected Behavior

More robust handling of multiple instances is needed.

I suspect that you had to do something sneaky since you’ve also got a Snap version (which I am not installing, it doesn’t belong outside Ubuntu and even there it’s an abomination). So you are probably using a method of checking instances which works inside containers such as Snap/Flatpak.

I am not sure, but I THINK the proper way to handle this is to register a dbus singleton instance of Mailspring, and then make the mailspring binary’s startup process attempt to “activate existing instance by sending it a message”, and if THAT fails THEN start a new instance of Mailspring, or QUIT if the existing instance responded.

I even suspect that you may be doing something like that already, but perhaps the dbus registration is being forgotten after a while.


  • OS and Version: Fedora Workstation 36, fully updated as of this writing
    • Installation Method: .rpm
  • Mailspring Version: 1.10.3-a476c230

I am also curious: Is there risk of database corruption when two instances run simultaneously like this? I get very worried about it.

I would add as well, this is currently breaking protocol handling. With a background instance (as per defaults), the newly launched copy that gets the URL just dies and never passes its URL to the running instance. So, the “activate existing instance” code needs to also pass arguments/URLs to the running instance.

1 Like

I stopped using the “launch email” keyboard shortcut due to this bug. Has anyone noticed if the bug still exists?

:frowning: These forums are dead. GitHub Issues was better.

+1 on this issue. Unlike any other app I have to tippy toe around how I launch this one by only reopening a running instance through the app panel indicator. I can’t even click on a email link to write an email without it opening a new instance.