Request - update process involving duplicati.service - Linux


#1

Hello all,

New to the forum but I feel I’ve played around with Duplicati on Linux enough to give some input and suggestions for future releases and/or installation methods.

I am running duplicati on linux manjaro installing the aur package - all good. The package updater two or three days ago alerted me of an update so I proceeded to do that. I had the duplicati instance open in the browser… it lost connection and then came back, as expected when the server restarts. However, it restarted with NO JOBS present. Needless to say it made my heart sink - I instantly went to work and made sure that backup files were still present on the destination. They were, so I proceeded to do the work to figure it out.

I restarted the duplicati service as root etc and to no avail - I was looking at the forums postings about Windows and service level and all that stuff and files - no dice. I finally got the bright idea to check the /usr/lib/systemd/system/duplicati.service and sure enough the username and group lines were re-entered. I REMOVED the entries again and BAM the backup tasks that were once in Duplicati before the upgrade were present again in Duplicati.

[Unit]
Description=Duplicati
After=network.target

[Service]
ExecStart=/usr/bin/mono /opt/duplicati-latest/Duplicati.Server.exe --webservice$
Restart=on-abort
Environment=AUTOUPDATER_Duplicati_SKIP_UPDATE=1

[Install]
WantedBy=default.target

I am wondering if we can change the way that this package either installs or the defaults to allow for Duplicati to run as root, if started in root. IF I run this as root with those fields in there it takes over and runs it as duplicati and it doesn’t have access to the entire drive. ALSO, it was running as root and all and then all of a sudden after the update it runs as Duplicati user and all the jobs are lost. Obviously the jobs are per user (or user defined) which is fine but for the average user to rely on Duplicati to backup after an update (at least on Linux) it could be frightening experience.

On that note, if I couldn’t get the jobs back could I recreate the jobs and point to the backup location that was on the NAS or Google Drive? I didn’t go down that route yet… AND yes I understand that there is a backup config option but who does that that. :slight_smile:

Just my thoughts on the subject -hope we can have some conversation and/or back and forth to the methodology and perhaps why it is the way it is.

Erik


#2

Are you sure Duplicati controls this? I don’t use Manjaro or Arch, but I don’t see that Duplicati has packages.

Arch User Repository is an independent effort. Obviously it has upstream, but I’m not certain who does what.

https://aur.archlinux.org/packages/?O=0&SeB=n&K=duplicati&outdated=&SB=n&SO=a&PP=50&do_Search=Go
shows some current packages and their maintainers. Does one of those look like what you may be running?

For whatever it’s worth, my use of Duplicati’s Debian package on Linux Mint (systemd) doesn’t create a user, however I’m also not a Debian or systemd person. Perhaps you or someone can find the source of the issue.


#3

I am running the duplicati-latest update as you linked above.

Anyway it would be interesting to do a test of an install on Ubuntu with a deb package and then see what the default duplicati.service file has for those lines, if that at all. Can you post what you see in /usr/lib/systemd/system/duplicati.service ?

Perhaps the install of the aur package is different and therefore no other user would have these issues installing from the duplicati site. Maybe you are onto something with the packaging of the AUR repo for duplicati. Mind posting that and seeing? I don’t have another system readily ready to image - I shall if you can’t or don’t want to.


#4

It’s not precisely Ubuntu, but here’s 2.0.4.5 on Linux Mint 18.1 which is based on Ubuntu 16.04 I believe.

/lib/systemd/system/duplicati.service is the file I could find. I don’t have the /usr path that you mentioned.

[Unit]
Description=Duplicati web-server
After=network.target

[Service]
Nice=19
IOSchedulingClass=idle
EnvironmentFile=-/etc/default/duplicati
ExecStart=/usr/bin/duplicati-server $DAEMON_OPTS
Restart=always

[Install]
WantedBy=multi-user.target

Source for above might be here. Installer flavors might be here.


#5

Fair enough. Yeah so it would appear that the install goes fine but there differences in potentially the duplicati.service file. That’s fair then. I am looking at other examples and it almost seems like there is a few oddities with them but that’s how it all gets controlled.

None the less I’ll let this issue fade now - I honestly thought perhaps based on my experience that I could shed some light but that’s obviously no real need. My info on removing those lines is valid using the package I installed so I’ll leave it at that.

Merry Christmas!


#6

You might be able to achieve the desired behavior by using systemd drop-in units to override or add new options:

https://wiki.archlinux.org/index.php/systemd#Drop-in_files