Can I run a second instance of Joplin?

Yep, but luckily even the new locking mechanism must not be very complicated. Files are out of the question. Let’s hope there’s a module we can use to create and access shared memory.

By the way, @tessus there’s a PR which I think is related to something you said about multiple profiles some times ago - Is it still relevant today? Because for the implementation we’re discussing, this new flag is not needed.

It depends, I’ve already answered on github.

It all depends on the architecture that has to be designed first. I see a multiple profile, multiple instance solution, which means that I can have several instances of Joplin running at the same time, plus that I can switch profiles in one single Joplin instance. However this architecture will look like, I think it needs more fleshing out, before thinking about PRs in that area.
But this is just my vision. Maybe you only want to have one or the other. As I said, it all depends.

1 Like

@laurent22 any chance we can pick this up again?

P.S.: This just popped into my mind when I read another sharing request.

I still plan to implement this some day but don’t know when. Now that we know how to do it, maybe we could write a spec for it for a start, as that might help identify some small tasks that could be done first.

I just want to mention a current behavior that works in linux that might be something to consider when running 2 instances of the terminal application (i.e. cli).

Running 2 instances of the cli with the default profile doesn't work because the instances are sharing a /tmp directory. Upon sync the contents in /tmp changes and thus causes the files therein to be lost. This causes any external editor's file contents to be decoupled with the database representation (by id).

The work around that I've found is to create a second profile folder and create soft links for the keymap.json file and the resources directory within the second profile back to the first.

The second profile looks like this:

├── database.sqlite
├── keymap.json -> ../joplin/keymap.json
├── log-database.txt
├── log.txt
├── resources -> ../joplin/resources
└── tmp

Then running a second cli instance is straightforward: joplin --profile joplin-2ndprofile

I do not recommend linking the databases as that could be problematic in the future. Although it does work fine for now -again just don't do it without having clear development rules in place about database vs application instance behavior.

Also, FYI, soft linking the <profile>/resources directory from a joplin-desktop profile does seem to work but I haven't tested it very much.

In addition, I'd like to point out that while linking the <profile>/resources seems to work fine for cli and desktop apps. I'm weary of the practice without some dedication to this concept being a -feature- and not just a -hack-.

At any rate, by linking the <profile>/resources directories we save transfer back and fourth to your sync directory if you are using nextcloud, et. al.

[edit]: as a side note -it's probably obvious but do consider that editing the same note in multiple instances is not handled in the behavior outlined here. Therefore, editing the same file between multiple instances of Joplin at the same time is bound to create conflicts -hence, it's a bad idea :smiley:

1 Like

I don’t have Windows anymore to test it out (just became too much of a slog on my old laptop), but I wonder if Joplin Desktop could be run at the same time as a WSL2 terminal instance?

I would love to see this coming but I want to challenge two points of the actual description:

  • while it would be a got first step I think switching between profiles is only a workaround or? I would love to see an integration of the profiles without switching.
  • the mobile platform is actual optional but lacks already many features from the desktop so I would suggest to set the scope to all platforms (making it harder to implement).
    just my two cents :wink: Thanks anyway to those picking up this feature.

How do you think that multiple profiles without switching should work? How can there be 2 profiles in one Joplin instance. This does not make any sense.

I agree. This should not be a desktop-only feature.

I also want to put it out there that I’d rather not have to restart the app. I’d like to see some research into how to reset the app states without a restart.

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.


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/ --profile /Volumes/.../JoplinA/joplin-desktop"
-window B: do shell script "/Volumes/.../JoplinB/ --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.