Nextcloud flatpak can be opened multiple times

[Firstyear]

It's possible to open multiple instances of the nextcloud flatpak, and all of them attempt to run and sync content at the same time. This may or may not cause consistency issues, so it would be great if the nextcloud flatpak was limited to a single instance running.

Thanks,

[TingPing]

Does flatpak run --filesystem=/tmp org.nextcloud.Nextcloud change anything?

[juliusknorr]

I thought this was fixed with flathub/org.nextcloud.Nextcloud#6 but unfortunately it seems to work only every second time when running Nextcloud. So maybe this is an upstream bug.

[Firstyear]

Yes! Setting --filesystem=/tmp results in the second instance displaying:

Gtk-Message: Failed to load module "canberra-gtk-module"
Gtk-Message: Failed to load module "canberra-gtk-module"
Sys Info size:  0
int main(int, char**) Already running, exiting...

[juliusknorr]

@Firstyear does it also work if you try to open an instance for the third time?

[Firstyear]

Okay, it opens again on the third time ...

[juliusknorr]

I'm still not sure if this is an upstream issue or not. When running the client without flatpak it works as expected every time.

[prog-amateur]

Hello, did you find a solution ?
I am on Ubuntu Wayland. Any flatpak app I have installed can open, while Nextcloud can't.
Today, I have sync issues, and I can't simply open the UI.
This issue was open on January, do you care about flatpak support ?

[juliusknorr]

I still could not find out why this is happening, seems like an upstream issue as the lock file is there and can be accessed by the client but it only recognizes it sometimes. However I cannot reproduce this outside of flatpak. If anyone has some ideas how this could be debugged, help is very welcome.

[fabiscafe]

Could we set another lock file for the flatpak itself? In that way we can just ignore the nextcloud lock file.

[cwmke]

For Debugging

[jurf]

Setting --env=TMPDIR=/var/tmp should be enough to get this to work…

[RobertBuhren]

Launching nextcloud with:

/usr/bin/flatpak run --branch=stable --arch=x86_64 --env=TMPDIR=/var/tmp  --command=nextcloud org.nextcloud.Nextcloud

Still allows multiple instances to run. Imho this makes the flatpak nextcloud app unusable,

[tilosp]

The problem is that that QtSingleApplication is used to allow only one instance to be open.
And QtSingleApplication relies heavily on pids which breaks completely since the new process has the same id as the already running one.

[tilosp]

I have opened an issue to discuss possible replacements for QtSingleApplication upstream nextcloud/desktop#2364

[Iolaum]

Tried replicating the bug in a Gnome Boxes VM running Fedora SilverBlue 32 on Wayland. I failed to replicate it:

$ /usr/bin/flatpak run --branch=stable --arch=x86_64 --env=TMPDIR=/var/tmp  --command=nextcloud com.nextcloud.desktopclient.nextcloud 
QSocketNotifier: Can only be used with threads started with QThread
nextcloud.gui.application: Already running, exiting...
$ flatpak info com.nextcloud.desktopclient.nextcloud

Nextcloud desktop sync client - Nextcloud desktop synchronization client

          ID: com.nextcloud.desktopclient.nextcloud
         Ref: app/com.nextcloud.desktopclient.nextcloud/x86_64/stable
        Arch: x86_64
      Branch: stable
     Version: 3.0.1
     License: GPL-2.0+
      Origin: flathub
  Collection: org.flathub.Stable
Installation: system
   Installed: 163.9 MB
     Runtime: org.kde.Platform/x86_64/5.15
         Sdk: org.kde.Sdk/x86_64/5.15

      Commit: 16956de802284db5ec2c6090df550820fb08270ff2f9e3650329a81e911c1eeb
      Parent: c901e78be336fa30ad1d3936d819c82afb4d4c9813bd613512669c8701bd8ba6
     Subject: Do cleanup (72d3d910)
        Date: 2020-09-07 07:09:34 +0000

[tilosp]

@Iolaum have you tried more than once, because once it works for me too.
You basically have to run flatpak run com.nextcloud.desktopclient.nextcloud three times, once to start it.
Than again to test if it detects the already running one, which it does on my machine, and then again to trigger this bug.

[Iolaum]

@tilosp You are correct, trying again succeeds where it shouldn't:

$ /usr/bin/flatpak run --branch=stable --arch=x86_64 --env=TMPDIR=/var/tmp  --command=nextcloud com.nextcloud.desktopclient.nextcloud
QSocketNotifier: Can only be used with threads started with QThread
nextcloud.gui.application: Already running, exiting...
$ /usr/bin/flatpak run --branch=stable --arch=x86_64 --env=TMPDIR=/var/tmp  --command=nextcloud com.nextcloud.desktopclient.nextcloud
QSocketNotifier: Can only be used with threads started with QThread
2020-09-30 23:58:04:106 [ debug default ]	[ unknown ]:	static bool LibSecretKeyring::findPassword(const QString&, const QString&, QKeychain::JobPrivate*)
2020-09-30 23:58:04:286 [ debug default ]	[ unknown ]:	static bool LibSecretKeyring::findPassword(const QString&, const QString&, QKeychain::JobPrivate*)
2020-09-30 23:58:04:287 [ debug default ]	[ unknown ]:	static bool LibSecretKeyring::findPassword(const QString&, const QString&, QKeychain::JobPrivate*)
2020-09-30 23:58:04:287 [ debug default ]	[ unknown ]:	static bool LibSecretKeyring::findPassword(const QString&, const QString&, QKeychain::JobPrivate*)
2020-09-30 23:58:04:287 [ debug default ]	[ unknown ]:	static bool LibSecretKeyring::findPassword(const QString&, const QString&, QKeychain::JobPrivate*)
2020-09-30 23:58:04:535 [ debug default ]	[ unknown ]:	static bool LibSecretKeyring::writePassword(const QString&, const QString&, const QString&, QKeychain::JobPrivate::Mode, const QByteArray&, QKeychain::JobPrivate*)
^C
$ 

[julianfairfax]

This doesn't seem to be the case anymore. Tested with Nextcloud Desktop-Client 3.14.2 on Fedora Linux 41 (Workstation Edition).