The odd initial log, odd “ps” results, and finding from looking at where this occurs fit with the theory:
duplicati/Installer/Synology/scripts/start-stop-status
-
The start-stop-status script records and observes the PID of the Server process it launched.
-
The Server is now two processes due to updater redesign in Oct 2017 canary, and now in beta.
-
The relatively gentle kill that Linux does to the parent kills the parent, leaving the child around.
-
The child is where backup service happens. For example child has the port that you browse to.
The same hidden-child problem exists on Windows command line, killing a Server using a Control-C.
On Linux systems, this kill can be caught (.NET looks harder but possible). Not sure about Windows.
Unless things (how many?) are taught parent/child, parent should catch request and also close child.
For a workaround, one possible approach is to stop automatic updates export environment variable:
AUTOUPDATE_Duplicati_SKIP_UPDATE=1 (might not need the -1 part) will revert to a single Server.
On to another branch of the original issue, seeing an example commandline layout reinforced my theory that the start script launching Server with no options might not supply the options one would want to use in DSM.
You can refer to the script source linked earlier, or find, check, and edit your own local copy.
–parameters-file in the script would allow actual options to be put somewhere else if desired.
I’m not sure about interactions between custom scripts and Duplicati updates, however custom is avoided if a workaround of both the parent/child preventer and the option-supplier could be shipped as a standard install, however agreeing on where --parameters-file should point to might be hard (and what if that file’s not there?)