Duplicati webui cannot start on my system because it is running twice.
When I try “sudo duplicati-server --webservice-port=8200 --webservice-interface=any”
It says: Another instance is running, and was notified
It does the same thing if I try a different port.
Systemctl status duplicati output:
● duplicati.service - Duplicati web-server
Loaded: loaded (/etc/systemd/system/duplicati.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2021-03-05 16:50:10 UTC; 2 days ago
Main PID: 1046 (mono)
Tasks: 30 (limit: 17837)
Memory: 5.3G
CGroup: /system.slice/duplicati.service
├─1046 DuplicatiServer /usr/lib/duplicati/Duplicati.Server.exe --webservice-interface=any --webservice-port=8200 --portable-mode
└─1445 /usr/bin/mono-sgen /usr/lib/duplicati/Duplicati.Server.exe --webservice-interface=any --webservice-port=8200 --portable-mode
Mar 05 16:50:10 toby systemd[1]: Started Duplicati web-server.
I have tried changing the port like in this post to no avail.
I also tried deleting the lock file and rebooting a few times like in this post.
Thanks in advance, I love the duplicati interface and being able to manage my backup schedules so granularly.
The two processes in systemctl status is normal. The parent finds the latest update and starts the child. Your service started March 5, and now you’re hand-starting a server two days later, and getting a clash?
Where did the service put its lock_v2 file? I see you chose portable-mode, which might put it under your installation folder, maybe under /usr/lib/duplicati/data, This would probably confuse a not portable-mode startup which would look for the usual file which is ~/.config/Duplicati/control_dir_v2/lock_v2
I’m not that familiar with the code, but I’d expect confusion to result in a missed clash, not an extra one.
So maybe we need to go wandering through some testing that you might have seen in the other issues.
Maybe you can do sudo lsof -i :8200 to see if it shows more than one process. Also test with :8300 however I think what actually makes this error is not a port conflict, but whether or not it can get the lock.
A sudo ps -ef | grep Duplicati sequence might also find what’s running that should not be running.
You can also cat whatever lock_v2 files you can find, to see what got them. Removing a lock file would probably make the next Duplicati think it was the first one, which again is the opposite of the current error.
1046 and 1445 are seen in your systemctl status as your --portable-mode service.
3960 and 3965 are maybe the non-service non portable-mode one that’s clashing.
What’s PID 3959? Is that a bash or other shell? It’s not using a tty (pts/#) currently.
If you reboot the system and the extra Duplicati shows up again, try to find out how.
Someone hand-tailored it to port 8021, so maybe that will help to jog your memory.
It’s running as root, so would block next manual start that you show in original post.
Does cat ~root/.config/Duplicati/control_dir_v2/lock_v2 point to 3965?
I was the one starting it on port 8021, I was trying that as a workaround to this problem, but might have just cemented my problem in. I don’t know how to stop this. Every time I try to kill the PID connected to a duplicati task, it just pops up under a new ID.
cat ~root…lock_v2 does indeed point to 3965.
This is a two month old setup gone weird. I haven’t checked my localhost:8200 in a few weeks. It worked 3 days ago, and duplicati has been doing all of my 4 scheduled backups. But as of a couple days ago, the webui isn’t working. I didn’t do anything weird to it.
I think the parent restarts the child. You should kill both processes, maybe kill the parent first.
But since this was a manual start, a system reboot should also come up with only a service.
While you have 8201 up, is anything there, even a home sreen with no jobs? If so, you got it.
But you say 8200 (the service) is down. Can you describe what it looks like, as not working?
I’m not that familiar with systemctl, but if the Memory: 5.3G is its size, that seems very large.
I guess you could look at the Duplicati child with ps or top to see how big or busy it appears.
Killing a busy process can make a mess, but sometimes there’s no other way to get it down.
Does it give exactly the same “The connection has timed out” and not something else to port 8202 or some other not-expected-to-work port? Firefox messages are vague. What about trying a known-bogus address?
FWIW mine gives “The connection has timed out” to a bad IP address, but an “Unable to connect” to a bad port on a good IP address (localhost). Got any other browser? Chrome and Edge give more specific clues.
Is coming in from the same system possible? That might reduce the chance of being blocked by a firewall.
What OS is the browser on? Windows includes a few network tools. Others (e.g. Linux) have better tools, which means probably on the Duplicati system you can try things like telnet localhost 8200 to test the connectivity at the lower TCP level. Firefox and most browsers also have developer tools to show network activity. If you see a bit of chit-chat, then you’re connected to Duplicati, but something is hanging up inside. Alternatively, if request looks like it’s raised, but server never answers, that might be low-level connectivity.
Preliminary to all above is looking on the server as before to see if Duplicati or several are up and listening.
Here is my setup:
Duplicati is running on an Ubuntu 20.10 server with a couple hard drives for backups in it.
I am connecting to this server via SSH on my Manjaro Linux desktop. It has other things like nextcloud and NFS mounts that are working well.
I’ve tried both my servers IP: and localhost:8200, 8201, and 8202. I get “refused to connect” ERR_CONNECTION_REFUSED on all 3 ports with localhost on Chrome. And “took too long to respond” ERR_CONNECTION_TIMED_OUT when using my IP: and all 3 ports on Chrome.
Ok. This is odd. As I was doing this I decided to try disabling my UFW firewall. I did that and it was back up and working at port 8200. I re-enabled the firewall and it was still working (because I have a rule for port 8200, that let duplicati through in the past. I am thinking this refreshed something on the network. I’m just glad to see the webui again.
ERR_CONNECTION_REFUSED sounds to me like an active TCP-level rejection from the remote or FW.
ERR_CONNECTION_TIMED_OUT sounds to me like there was no response at all to TCP-level connect.
During this time, netstat would show something like SYN_SENT which is the way of asking for connect.
Something like tcpdump or Wireshark could get a better view of it at the network level if issue reoccurs…
