Does Duplicati have a background automatic update system?
It appears to have automatically deleted itself.
I was using my computer last night and noticed a visual change in the icon area at the top right on my Ubuntu 18.04 system. The Duplicati icon had turned invisible - the menu was still there if you click on the icon’s space but the visual icon had gone. I clicked “Quit” on the menu and then went to the web interface in my pinned browser tab.
The web interface had an error for both backup jobs along the lines of “some part of the path /usr/lib/duplicati not found” (a manual check on the filesystem confirms that file/folder does not exist). Refreshing the page resulted in “Resource not found: http://localhost:8200/ngax/index.html”.
The .config/Duplicati/updates directory is empty apart from installation.txt and README.txt.
I couldn’t see any file/directory that’s obviously Duplicati related in /var/log/.
I don’t remember exactly how I got Duplicati to install in the end but I have found a duplicati_2.0.3.3-1_all.deb file in my downloads folder which indicates that I at least attempted to install it using the package manager at some point.
Ubuntu is configured to install security updates automatically but everything else is manual and I haven’t run any update to any part of the system for a few days.
A variety of sqllite files in the config directory suggest that it is only the application affected by this rather than data. However, I am concerned that this situation can happen at all so would prefer to not run through a full re-installation process until we’re sure there’s nothing that can be learnt from the current system state.
I’m not an expert in this, but I had a Linux Mint VM, so had Firefox download, and gdebi install Duplicati.
dpkg could then see it, and “man dpkg” followed by "grep duplicati /var/log/dpkg.log showed the action.
Duplicati is able to add updates into the updates directory, but you have the latest Beta, so have none.
The base software seems to load mostly (by volume) in /usr/lib but yours has somehow been removed.
There seem to be times (and tools) to clean up systems that have un-needed or third party packages:
@ts678 is correct that Duplicati processes updates by adding them to a ~/.config/Duplicati/updates folder - not but by removing the old version and installing a new one. So the installed version is your “base version” while any updates would be the “current version”. But as you stated, 2.0.3.3 (your base / installed version) is the newest beta out there so you shouldn’t see any anything in the updates folder.
So I’m not sure how Duplicati would manage to delete itself.
I’m not a Linux expert, but is there an “uninstall history” available that might indicate when it happened?
Or maybe the modified date on the ~/.config/Duplicati/ folder might be an indicator.
It seems pretty unlikely, but could an antivirus program have decided it was a threat and quarantined it?
Although I think apt runs dpkg (so check in /var/log/dpkg.log) I believe it also has its own logs in /var/log/apt.
The automatic security updates might be from the unattended-upgrades package which appears to use apt.
For a long shot you could look at timestamps on directories like /usr/bin or /usr/lib. Might show removal time.
I’ve now looked in /var/log/apt/history.log and found when the problem occurred. The uninstall was triggered when I installed an unrelated application the day before.
@JonMikelV, thankfully I have left the joys of overzealous anti-virus programs behind on Windows when I switched to Ubuntu a few months ago but it appears I’ve swapped that risk for the risk of new software installations secretly uninstalling existing applications!
It seems that the 64 bit versions of libappindicator and libindicator can’t co-exist with their x86 equivalents so installing this other x86 application that depends on those libraries triggered the removal of the x64 versions as well as packages like duplicati that depend on the x64 versions. Which is all fine and understandable… if only the package manager would have explained this at the time and offered a chance to abort.
Here’s the relevant line from the history log showing what got removed:
As expected, re-installing insomnia or duplicati causes the opposite change to occur and the x86 application gets removed silently. Since I don’t need the other application as much as duplicati and insomnia, I’ll just leave it off my system and we can rest easy knowing the bug lies somewhere in the Debian/Ubuntu package manager rather than Duplicati.
@ts678 is correct that there is extra information in /var/log/dpkg.log but in this case I don’t think it changes the conclusion from looking in the briefer /var/log/apt/history.log
I’ve reinstalled Duplicati now but it has lost all of my configuration which is a shame. I thought this would have been stored within the ~/.config/Duplicati folder but I can’t see any way to turn those sqllite files into a working backup configuration. Have I missed something or should I just set up new backup jobs from scratch?
Edit: Per discussion below, the solution to the missing configuration was to run duplicati using the same method as I was before it were uninstalled. For me that was upon user login rather than the system service approach that I tried when initially writing this post.
I think there’s hope but I can’t give you exact steps, especially for Duplicati on Linux. If you have Duplicati running, try looking in a job at Advanced->Database at “Local database path:” and the buttons near that.
Possibly that hint will be enough for you to find the answer somewhere here. You seem very capable.
I’m glad you got to the bottom of the original mystery.
Good job tracking that down! I’m flagging that as the “solution” in case anybody else runs into this.
In the mean time, this is definitely something that @kenkendk should be made aware of so we can try and work around it or at least make the information known in an appropriate location.
I’m not exactly sure where all the parts are stored (@Pectojin might have a better idea) but what I’ve seen is ~/.config/Duplicati/dbconfig.json seems to contain a list of basic job informtaion (type, database path, etc.) but no details (parameters, excludes, etc.).
I think the job specific information is stored in Duplicati-server.sqlite (not the job specific sqlite fie) so if you happen to have a copy of that lying around (or maybe in a backup) I suspect you could get your job info back from that.
Yep, all the info you want is in Duplicati-server.sqlite, which would put the server “state” back the way it was. Then, if you don’t have the job specific DB’s, you’d simply recreate those from the UI where the jobs are already present.
As mentioned by @Pectojin, Duplicati will look for ~/.config/Duplicati/Duplicati-server.sqlite when it starts. This database contains everything configured and related to the Web userinterface.
Most likely, you are running Duplicati as a new user, which means ~ is translated to a new folder with no database.
For the OP problem, I am not sure how to fix it. The package manager is designed to prevent conflicting packages, so it works “as designed”, and so does both Duplicati and insomnia. I am not sure why libappindicator cannot exist in two versions, but I don’t think we can assume that it gets fixed anytime soon.
Duplicati itself is actually 100% architecture neutral, but it calls a few native libraries, mainly libsqlite3 and libappindicator. You can run Duplicati in either x86 or amd64 mode, simply by giving a flag (-m32?) to Mono. Doing so will make Duplicati run as a 32bit process, and thus will only load 32bit binary libraries.
However, I would like to avoid (as much as possible) the split with individual debian packages for x86, amd64, arm etc.
I’ve got the configurations back. I ran the duplicati service via systemctl when I finished installing it this time but it transpires that this is not how I was running it with the initial installation. Once I rebooted and duplicati was started upon login, the configuration files were found correctly and the backups are running as normal again so thankfully some of the more advanced recovery information you all helpfully provided was unnecessary this time
The tray icon no longer appears but this is not as critical as the backups not running at all so I’m happy with my progress for today!
I think that personally I will just use this whole experience as a reason to make a concerted effort to not install any i386 packages on my system but this information could be useful in a pinch.
For the record, I have also just ran sudo apt autoremove which cleared out the scores of i386 packages that are no longer needed and sudo apt install libcanberra-gtk-module to make an error message when running duplicati go away (in the hope that this was what was causing the tray icon to no longer work but no).
