mono Duplicati.Gui.TrayIcon.exe --toolkit=cocoa is resulting in the same error for me
however using --toolkit=gtk is starting the trayicon and duplicati as expected
1 Like
When I enter the revised command, I get this:
mono Duplicati.Gui.TrayIcon.exe --toolkit=gtk
Crash!
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> Duplicati.Server.SingleInstance+MultipleInstanceException: Another instance is running, and was notified
at Duplicati.Server.Program.CreateApplicationInstance (System.Boolean writeConsole) [0x00063] in <1fb2f5acbba047c8b281d2f7d847aa06>:0
at Duplicati.Server.Program.RealMain (System.String[] _args) [0x00277] in <1fb2f5acbba047c8b281d2f7d847aa06>:0
at (wrapper managed-to-native) System.Reflection.RuntimeMethodInfo.InternalInvoke(System.Reflection.RuntimeMethodInfo,object,object[],System.Exception&)
at System.Reflection.RuntimeMethodInfo.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0006a] in <b27839cc2dba4804baacf2f5cce6de32>:0
--- End of inner exception stack trace ---
at System.Reflection.RuntimeMethodInfo.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00083] in <b27839cc2dba4804baacf2f5cce6de32>:0
at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] in <b27839cc2dba4804baacf2f5cce6de32>:0
at Duplicati.Library.AutoUpdater.UpdaterManager.RunMethod (System.Reflection.MethodInfo method, System.String[] args) [0x00000] in <28c7b8f845214dcdac93572d0e131366>:0
ah you need to make sure you dont have the server running when you start this command
Duplicati.Server.SingleInstance+MultipleInstanceException: Another instance is running, and was notified
1 Like
Can I kill the Server with a command line command? A quick Google search yielded no usable results. Any help is appreciated!
Thanks, I have been able to repro it. Managed to find access to a Mac computer, inspite of everything Murphy has thrown in my way (the evil one even managed to disturb my power supply :-), my Internet access is currently shaky too), sorry about the delay in responding to your report.
Now all that remains is to actually fix the problem.
3 Likes
Of course you can, just as any other process. But be warned, if itās compacting and youāll do that, then you might destroy the backup. If you planning to kill the process, make sure that compaction is disabled, or isnāt running.
I donāt want to make separate post about this, but when people complain about slow database recreate, it should be split to two groups based on my experience. Situation where backup data is corrupted and situation when it isnāt. Because thereās some additional extremely slow recovery code which runs if itās corrupted. Earlier when I complained about extremely slow db recreate, it was due to the fact that the backup was corrupted. When backup isnāt corrupted, recreate happens just by handling i files, but when itās corrupted all b files and even local files (if not disabled) are used to recover. - AFAIK, based on experience.
Add possibility to set custom SQlite pragmas, thanks
Thatās great, because if SQLite3 is up to date, there are settings which can increase performance a lot, like 20x compared to default settings. This could tremendously help with cases where there are many (more than one million) d blocks in the database.
hmm, I have soured on the solution. First I have tried to understand what could happen and failed. It looks like a system bug (Mono probably). More importantly, I have found in the Duplicati log this interesting snippet:
commit 9a6bd263cd037840851226ab06139ad24e514d29
Author: Kenneth Skovhede kenneth@hexad.dk
Date: Tue Mar 22 00:15:17 2016 +0100
Default to not attempt to load monomac on 64bit OSX as that crashes.
Unfortunately GTK seems to not be included by default either :/
so it seems that the removing of Cocoa was linked to problems in having Gtk and Cocoa enabled at the same time. And having everything in a single build is necessary or else the update logic must be reworked, a very unattractive proposition.
So I have switched to migrating Rumps to Python3. Itās not a very attractive proposition because it needs a manual step (install pyobjc), but I donāt see any other quick fix.
So far it is (almost) working on OSX Monterey. All that remains is to fix this (small) problem, test on Bigsur (seems necessary at least), then do a check of the resulting build on Windows and Linux.
Iām back having missed a step (not in debugging, in a real stair 
) so a bit of delay, I have a working Rumps version on Monterey (so needing sudo pip3 install pyobjc) here:
tomorrow Iāll try to test it on the other platforms.
Edit: works on BigSur (sudo pip3 install pyobjc needs some effort though), donāt work on Catalina, no impact on Linux or Windows (as could be expected).
Iāll do a PR on the real repo, wait a few days if anyone having a Mac tries the software, then if there is no move Iāll commit it with the PR 4921 and ask for a new Canary.
1 Like
Is Gatekeeper stopping it as described in Notarization for MacAdmins?
There appear to be workarounds, such as deleting the quarantine flag.
Potential testers whoāve had Macs for awhile might have favorite ways.
The .dmg and .pkg files are both notarized and stamped, so I would be surprised if MacOS rejects it. Perhaps a additional antivirus tool is flagging it?
no, the answer is that the tool is built for OSX11 while the system version is 10.15.