Can I run a second instance of Joplin?

A post was merged into an existing topic: GSoC idea - Support for multiple profiles

I hope this is the correct place for this comment: For Android devices, it would be possible to manually install a modified apk of Joplin where the package name is changed. That way one could install Joplin several times on one single device. Each app installation is independent and can sync to different sources.

2 Likes

I tried to use a second instance with an associated profile, it works but could not be used at the same time as the first one.
If I launch the second instance while the first is running, the second just wait until I quit the first.

Could it possible to lift this restriction ?

I am working on Mac OS High Sierra, I install Joplin in 2 folders JoplinA and JoplinA and started each instance from Applescript Script Editor:
-window A: do shell script "/Volumes/.../JoplinA/Joplin.app/Contents/MacOS/Joplin --profile /Volumes/.../JoplinA/joplin-desktop"
-window B: do shell script "/Volumes/.../JoplinB/Joplin.app/Contents/MacOS/Joplin --profile /Volumes/.../JoplinB/joplin-desktop"

As far as I know, it is not possible. The original issue is still open.

I'd love to use multiple profiles in Joplin simultaneously. I understand Joplin server is a way to have this, but I'm contemplating the effort needed to install Joplin server on my own lab server (it's sensitive data) + migrate from our current NextCloud solution. Overall we're talking days/weeks of tinkering and transitioning for the whole team.

Right now on macOS I have a default team profile and a "personal work" profile that I launch from the terminai using the --profile option. On Android I use the "Protected folder" from Samsung Knox that allows to run a second, independent version of the app.

On the mac, I have to close and reopen Joplin between the "team" and "personnal work" profiles a dozen of times each day. Just having a way to run both instances in parallel would solve my problem (I don't care about fancy profile switching or complex sharing schemes). I tried the "open -n" option that supposedly allows to run several instances of an app in OSX but it doesn't work.

I wonder if an alternative distribution of Joplin (as detailed here Unofficial alternative Joplin distributions) such as the macOS homebrew version could run in parallel to the official one?

Not out of the box I don't think, no. Joplin tends to hard code its config directories.
There is an (untriaged) issue (really an enhancement request) and associated PR that has been raised on Linux to follow the XDG directory spec but I don't know if there is anything additional in the base install that would get unhappy at two joplin processes running at once.

Otherwise, other applications can do this, yes. I have two instances of Discord (one deb and one flatpak) so I don't have to switch accounts and both can run at the same time.

By the looks of that one commit alone, I'd doubt it'd allow running second instances. At least on Linux, changing the config folder alone isn't enough to enable this. But there must be some combination of variables that might allow it, because using snap's parallel installation feature, you can do this. (This is presumably just setting up a load more of the XDG_* variables, not sure specifically which ones are required though)

It's experimental for a reason though. Here's some bad UI :slight_smile:

This is correct. Joplin uses this method provided by Electron to ensure only one instance is running at a time:

How exactly this is implemented I do not know.

I think we could try to additional test for the profile. So, iff an instance with the same profile was running, it should abort.

I think we discussed this a while back. It might not be so easy with the tools available by Electron. If we have to use lockfiles it could be a problem should Joplin ever crash without removing such a lockfile.

Update: Another problem is external URL links. If an instance is running that instance is used and Joplin is not started. So how can we be sure that the correct instance will handle the external URL request?

If we ignored the fact that external URLs may break and that people could destroy their states, a new parameter --multiple-instances could theoretically allow for starting more than just one instance.

However, I really doubt that Laurent would accept such a thing. It would be a support nightmare.
Just think of all the people who deliberately deactivated safe mode and opened ticktes that they "lost" their notes.

1 Like

URL links are relying on the fact that there's only 1 instance. If this limitation is removed, I suspect each click on such link will open new Joplin instance.

Wait - can a Joplin snap be installed under macOS and used to have several instances? Or is it Linux-only? I can live with the border effects (external URLs, UI quirks etc)

Unfortunately it's Linux only, I tried to figure out what exactly it's doing that makes the magic happen, but haven't managed to recreate it outside that environment yet unfortunately. It could possibly be some platform specific quirks that enable it.

I thought (from reading this forum) that the dev version of Joplin already allows to run 2 instances. So the Electron lock can be circumvented? I'm ready to install two slightly different Joplin for that (but not loose automatic sync as happens in the dev version if I read correctly).

Rather than supporting multiple instances of the application it makes more sense to me that Joplin would be able to swap profiles within the same instance or maintain multiple profiles opened at once. Essentially an extra level above that of Notebook.

That wouldn't be any kind of quick win though.

Problems are that 1) it would be a lot harder to implement as it would (likely) require a ton of development in the application itself and 2) it might not be a direction in which the project wishes to go.

I agree - but seeing how this idea is stuck for years now (it's going in circles really), I'm going for the pragmatic approach and a way/hack to run multiple instances. Basically something that will take less effort and less time than deploying my own Joplin server. Heck I'm even this close to run a Linux version in a virtual machine but that's an overkill I'm not ready for yet, if there's a more slimmed down hack

1 Like

Right now I'm looking at running a Windows version in Wine/Crossover...

... and it doesn't work either

Having enjoyed Joplin for a while, i reached for a feature that i assumed would be supported. In my case i wanted to edit a note in one profile whilst viewing a note from a another profile.

I'm very sorry to hear @laurent that such a fundamental modern structural feature of running two simultaneous instances of your application is so difficult to implement. I can't remember how many years ago i last contemplated such a weakness, (perhaps that's a little harsh). Umm... having to work around an issue such as this. We have been placing related notes, documents, spreadsheets, webpages and so forth side-by-side for comparative analysis on our monitors for decades. After writing text based software for a while, i wrote my first multi-window database application in the late 90's.

Are you trying to do too much with this feature too quickly? Having said that, i notice a Github thread on "multiple instance" starting way back in June 2018. Anyway, what basic features would give the community 90% of what they desparately seek?

Back in November 2019, @tsumare commented:

rather than getting too bogged down in them, I would suggest as a first step, to simply make --profile work correctly. Everything else is dependent on this functionality anyway, and it would allow us to make use of the feature right away while everything else is nailed down.

I subscribe.

Hoping not to raise too much angst and with the risk of duplicating previous contributions...

  1. Forget the mobile apps for the time being.
  2. Forget the same profile being allowed in multiple-instances.
  3. Simply allow each profile to have it's own instance.
  4. Deploy as experimental / beta / use at your own risk or however you want to phrase it
  5. Deploy with known caveats and warning that there will be more to follow
    • users should be prepared to visit the relevant discussion threads to learn new nuisances
  6. Only allow multi-instance through use of --profile param
  7. Instruct users to configure separate non overlapping sync configuration for each profile
    • do not worry about trying to block such a "mistake"
  8. Do not mention multi-instance in your main stream documentation
    • users will have search for then knowingly leverage the --profile param
    • users should therefore be aware of the caveats, and if not, it will be their own fault

At some stage @laurent you wrote...

At the moment, the app is limited to one running instance only ... this was to avoid people accidentally running multiple instances in the background, all syncing with each others.

I think i can appreciate how tricky this is to design, code and test. Don't bother with it at this stage. Just unlock the above so that on our desktops we can run a couple of profiles side-by-side. Please.

That is why I ask for a separated render window here : Desktop app: Opening/editing multiple notes - #53 by zackles

If it is just read-only render (new windows only or another instance) there must be no lock-in problem or write competition on the database.