Spksrc: NAS Synology and Syncthing - Syncthing not starting

[safersurfing]

I have a NAS Synology DS715 and Syncthing 0.12.8-7 installed. My issue may relate to the above comments.

I start Syncthing (run syncthing via the package center, but it stops straight away. The only logs I have found are following.
Any idea?

2016/03/04 06:33:37 start syncthing: begin to start version 0.12.8-7
2016/03/04 06:33:37 start syncthing: start version 0.12.8-7 successfully, result 0

Mar 4 06:33:42 DiskStation php: Failed to delete keys [F3ECC2A519CA01C85D04EDA6D0C2F18694A0B88E].
Mar 4 06:33:42 DiskStation php: DeleteOtherKeyServer failed.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[Dr-Bean]

Missing some information here, e.g. DSM version. Please follow instructions here: https://github.com/SynoCommunity/spksrc/blob/master/CONTRIBUTING.md#issue-content, and add this please.

Try and start the package manually (log in via SSH as root): https://github.com/SynoCommunity/spksrc/blob/master/spk/syncthing/src/dsm-control.sh#L17:

start-stop-daemon -b -o -c syncthing -S -u syncthing -x env HOME=/usr/local/syncthing/var/ /usr/local/syncthing/bin/syncthing -- --home /usr/local/syncthing/var/

[safersurfing]

OK, here you go:

Model name
DS715
CPU
ANNAPURNALABS Alpine AL314
CPU clock rate
1.4 GHz
CPU cores
4
Total physical memory
2048 MB
DSM version
DSM 5.2-5644 Update 5

I cannot find logs and do not know how to set them up.

I tried to enter what you wrote and it started
start-stop-daemon -b -o -c syncthing -S -u syncthing -x env HOME=/usr/local/syncthing/var/ /usr/local/syncthing/bin/syncthing -- --home /usr/local/syncthing/var/

However when i launch https://192.168.178.35:7070 I do not enter the GUI, even though the package is marked as "running". I did all that was listed in https://github.com/jedie/syncthing/wiki/Syncthing-in-Synology-DSM#creating-file-usrlocalsyncthingbinrunsyncthing but it did not work. Do I have to restart the server after changes?

Is there a chance you could login life via teamviewer or anydesk onto my NAS?

[cytec]

@safersurfing spamming all syncthing issues won't get you a solution any faster...

[safersurfing]

sorry

[Dr-Bean]

Two things:

• If you have made any changes to the package, e.g. the user Syncthing runs as, such as described in that link you referred to, you're on your own. There's no way we can support altered packages.
• Note that Syncthing's webui takes a while to start (probably up to a couple of minutes). In other words: after starting the package (either via Package Center or manually), I would expect a Syncthing process to be running. If that's the case, just wait longer.

You can verify that with something like ps -www | grep syncthing, which should return a running process or two. It looks like this:

NAS> /var/packages/syncthing/scripts/start-stop-status stop 
Stopping Syncthing ...
stopped /usr/local/syncthing/bin/syncthing (pid 25956 25951)
NAS> ps -www | grep syncthing
25982 root      4188 S    grep syncthing
NAS> /var/packages/syncthing/scripts/start-stop-status start
Starting Syncthing ...
NAS> ps -www | grep syncthing
25951 syncthin  779m S    /usr/local/syncthing/bin/syncthing --home /usr/local/syncthing/var/
25956 syncthin  779m S    /usr/local/syncthing/bin/syncthing --home /usr/local/syncthing/var/
25971 root      4188 R    grep syncthing

[safersurfing]

No changes to the package. Is installed as provided (Alpine).
Waiting more than 10 minutes, however what I found was following log:

Found following ... DiskStation> /usr/local/syncthing/ /usr/local/syncthing/app/ /usr/local/syncthing/bin/ /usr/local/syncthing/var/ DiskStation> /usr/local/syncthing/bin/syncthing unexpected fault address 0x492cf4 fatal error: fault [signal 0xb code=0x2 addr=0x492cf4 pc=0x492cf4]

goroutine 1 [running, locked to thread]: runtime.gothrow(0x5b4278, 0x5) /spksrc/native/go/work-native/go/src/runtime/panic.go:503 +0x84 fp=0x10c1b61c sp=0x10c1b610 runtime.sigpanic() /spksrc/native/go/work-native/go/src/runtime/sigpanic_unix.go:29 +0x2a4 fp=0x10c1b644 sp=0x10c1b61c github.com/golang/snappy.init() ?:0 fp=0x10c1b648 sp=0x10c1b648 github.com/syndtr/goleveldb/leveldb.init() /spksrc/spk/syncthing/work-alpine-5.2/syncthing/Godeps/_workspace/src/github.com/syndtr/goleveldb/leveldb/version.go:457 +0x70 fp=0x10c1b680 sp=0x10c1b648 github.com/syndtr/goleveldb/leveldb.init() /spksrc/spk/syncthing/work-alpine-5.2/syncthing/Godeps/_workspace/src/github.com/syndtr/goleveldb/leveldb/version.go:457 +0x70 fp=0x10c1b6b8 sp=0x10c1b680 github.com/syncthing/syncthing/lib/db.init() /spksrc/native/go/work-native/go/src/github.com/syncthing/syncthing/lib/db/virtualmtime.go:76 +0x8c fp=0x10c1b6e8 sp=0x10c1b6b8

goroutine 2 runnable: runtime.forcegchelper() /spksrc/native/go/work-native/go/src/runtime/proc.go:90 runtime.goexit() /spksrc/native/go/work-native/go/src/runtime/asm_arm.s:1322 +0x4

goroutine 3 runnable: runtime.bgsweep() /spksrc/native/go/work-native/go/src/runtime/mgc0.go:82 runtime.goexit() /spksrc/native/go/work-native/go/src/runtime/asm_arm.s:1322 +0x4

goroutine 4 runnable: runtime.runfinq() /spksrc/native/go/work-native/go/src/runtime/malloc.go:712 runtime.goexit() /spksrc/native/go/work-native/go/src/runtime/asm_arm.s:1322 +0x4

goroutine 5 /spksrc/native/go/work-native/go/src/github.com/syncthing/syncthing/lib/dialer/internal.go:46 created by github.com/syncthing/syncthing/lib/dialer.init·1 /spksrc/native/go/work-native/go/src/github.com/syncthing/syncthing/lib/dialer/internal.go:49 +0x260

goroutine 6 /spksrc/native/go/work-native/go/src/os/signal/signal_unix.go:19 created by os/signal.init·1 /spksrc/native/go/work-native/go/src/os/signal/signal_unix.go:27 +0x40

[safersurfing]

Tried Dr-Bean suggestion, but only get 25982 root 4188 S grep syncthing returned, no matter if stop or start entered.
It looks like syncthing is actually not running. The log see above is shown.

[safersurfing]

Anybody have an idea what the issue could be here?

[safersurfing]

Really stuck here ... it looks like syncthing does not run on DS715 Synology (Alpine).

[Dr-Bean]

ping @cytec Maybe update Go to whatever version Syncthing uses (1.5 last time I checked, could be even newer now)

@safersurfing Here's an alternative then, at least unless we can figure out what causes the package to fail on Alpine.
Get Syncthing's build here: https://github.com/syncthing/syncthing/releases/download/v0.12.21/syncthing-linux-arm-v0.12.21.tar.gz. Extract the syncthing binary, and put that in /usr/local/syncthing/bin/, replacing/overwriting the existing file.
/edit: note that if we release a package update, you might need to redo this. So far, no one else has reported an issue with the Alpine arch, and other ARM arches don't seem to be affected.

[cytec]

yeah... was thinking on updateing the go stuff for a while now... starting with 1.5 cross compile became a lot easier to handle and we may be able to produce arm5 and arm7 bins ...

[cytec]

@Dr-Bean so... i've just looked into this and it seems like since go 1.5 you'll need 2 versions of go to build the cross compiler... basically you need to have go >= 1.4 installed to build the 1.5+ binaries. How are we gonna handle this? donwload and build 1.4 in the same Makefile via CONFIGURE_TARGET or better create a new native/go1.6 package and depend on the "old" native/go?

[Dr-Bean]

Hm...there doesn't seem to be a way around it indeed. The debian packages in stable are all too old to use for bootstrapping (both gccgo and golang-go), and getting them from testing or jessie-backports is a hassle.

Are there any reasons/upsides for us to provide different versions of go? E.g a go-1.5 alongside a go-1.6?
If we can get away with always using the latest version of go, maybe do it the other way around as you suggested: set up native/go and native/go-1.4. Bootstrap native/go with native/go-1.4, and continue to use native/go to depend upon from Syncthing or other cross packages.

[cytec]

i'd go with your suggestion to use latest go version and use go-1.4 for bootstrapping... maybe that'll change in the future and we can get rid of native/go-1.4 again at some point...

[scyto]

I have 1815+ with DSM 6 update 3 and syncthing fails to start from the UI, no logs in the UI. I am unclear where to go / what to do after i SSH in? I tried start-stop-daemon command above but it said command not found.

[erikvanoosten]

I had similar problems. Syncthing wouldn't start up after a reboot of my synology.

Syncthing started working once I realized that:

• no syncthing user was created
• /usr/local/syncthing has rights that are all over the place, not all them can be read by the syncthing user

As a 'fix' (not sure it is a fix) I did the following:

• Created user syncthing, put it in the sc-syncthing group and gave it access to the syncthing share
• Logged in via ssh and executed sudo chown -R syncthing:users /usr/local/syncthing

Now syncthing started fine. I wonder what will happen on the next reboot.
This issue might be related to #2140.

[Jamesits]

Have the same issue on DS1817+, DSM 6.1.3-15152 Update 1. Syncthing stopped and refused to start after a reboot.

$ /var/packages/syncthing/scripts/start-stop-status start
start-stop-daemon: unknown user syncthing
Starting Syncthing ...
start-stop-daemon: unknown user syncthing

@erikvanoosten 's fix didn't work for me. After applying that, there are no more "unknown user" error messages but still it won't start.

[cinghialino]

@Jamesits did you fixed it? I noticed that there is a new update of the DSM, maybe will start back..

[Jamesits]

@cinghialino I've applied the newest update, but it seems to be only firmware updates:

Fixed Issues

1. BIOS update to improve system stability. Applied models: DS1515+, DS1517+, DS1815+, DS1817+, DS2415+, DS415+, RS2416+, RS2416RP+, RS815+, RS815RP+.
2. Enhanced USB 2.0 compatibility for DS415+, RS2416+, and RS2416RP+.

I gave up running this version of Syncthing on DSM... Waiting for a clear fix. Reinstalling wipes all its config and I need a lot of time setting it up again. I'm using VM Manager to run a Ubuntu in DSM, install Syncthing on that OS and mount shared folders over CIFS. (This is not stable either but at least no serious bugs)

[cinghialino]

@Jamesits I agree we synology users need a easy package.

[shavenewok]

Hi All

I followed @erikvanoosten instructions and still couldn't get it to work.

I found i didn't have the rights to access /usr/local/syncthing/var

Once i ran sudo chown -R syncthing:users /usr/local/syncthing/var i was able to start Syncthing from the package centre. I also tested with a reboot and Syncthing auto started after the reboot

[erikvanoosten]

Unfortunately it soon stopped working for me also. I gave up and now run syncthing on a Ubuntu machine. Would be great if it would just work though.

[jamesd]

On my system, /usr/local/syncthing is a symlink to where the appstore puts syncthing and the chmod did not follow through the link.

I changed the chmod in @erikvanoosten's intructions to:

sudo chown -R syncthing:root /usr/local/syncthing "$(readlink -f /usr/local/syncthing)"

syncthing has been stable through reboots for me for awhile now.

[KingDuckZ]

Same problem on DSM 6.2-23739 Update 2
I logged into ssh and:

admin@DiskStation:/usr/local/syncthing/var$ /var/packages/syncthing/scripts/start-stop-status stop
/var/packages/syncthing/scripts/service-setup: line 6: [: : integer expression expected
/var/packages/syncthing/scripts/start-stop-status: line 43: start-stop-daemon: command not found
 is not running

admin@DiskStation:/usr/local/syncthing/var$ /var/packages/syncthing/scripts/start-stop-status status
/var/packages/syncthing/scripts/service-setup: line 6: [: : integer expression expected
/var/packages/syncthing/scripts/start-stop-status: line 43: start-stop-daemon: command not found
 is not running

admin@DiskStation:/usr/local/syncthing/var$ /var/packages/syncthing/scripts/start-stop-status start
-sh: /var/packages/syncthing/scripts/start-stop-status: No such file or directory

Otherwise I seem to have the sc-syncthing user set correctly in /etc/passwd and file permissions look ok to me. syncthing version available at this time is v0.14.49-15 https://synocommunity.com/package/syncthing

[acolomb]

Starting service over SSH doesn't work like that anymore I've been told. See https://github.com/SynoCommunity/spksrc/pull/3391#issuecomment-407108440

Sorry I can't give you the correct commands, but it works from the Package Center.

[KingDuckZ]

acolomb it doesn't start from the gui either, that's why I had to try over ssh.

Edit: I just tried again following your suggestion and I get this:

admin@DiskStation:/$ synopkg start syncthing
package syncthing start successfully
admin@DiskStation:/$ synopkg status syncthing
syncthing package is stopped
Status: [3]

[ymartin59]

Sill commenting on a two years old issue... maybe time to create a dedicated new one.

By the way, to provide more details you may start service from script: https://github.com/SynoCommunity/spksrc/wiki/Frequently-Asked-Questions#how-to-query-package-status-or-start-from-command-line

Please also report log files content from /var/packages/syncthing/target/var/syncthing.log and /var/packages/syncthing/target/var/syncthing_install.log

[KingDuckZ]

ymartin59 that's exactly what I did, in fact I followed that same link you posted in the issue linked by acolomb. And I already posted the output I get from doing that ;)
As for the logs:

$ cat /var/packages/syncthing/target/var/syncthing.log
Sat Sep 15 11:09:17 IST 2018
Starting syncthing command /volume1/@appstore/syncthing/bin/syncthing -home=/volume1/@appstore/syncthing/var

and

$ cat /var/packages/syncthing/target/var/syncthing_install.log
Sat Sep 15 00:22:11 IST 2018
===> Step preinst. USER=syncthing GROUP=sc-syncthing SHARE_PATH=
Sat Sep 15 00:22:12 IST 2018
===> Step postinst. USER=syncthing GROUP=sc-syncthing SHARE_PATH=
Installing service configuration /var/packages/syncthing/conf/syncthing.sc
Creating group sc-syncthing
Group Name: [sc-syncthing]
Group Type: [AUTH_LOCAL]
Group ID:   [65538]
Group Members: 
0:[sc-syncthing]
Invoke service_postinst
Granting 'sc-syncthing' unix ownership on /volume1/@appstore/syncthing/var
Sat Sep 15 00:23:36 IST 2018
===> Step preupgrade. USER=syncthing GROUP=sc-syncthing SHARE_PATH=
Sat Sep 15 00:23:37 IST 2018
===> Step preuninst. USER=syncthing GROUP=sc-syncthing SHARE_PATH=
Sat Sep 15 00:23:37 IST 2018
===> Step postuninst. USER=syncthing GROUP=sc-syncthing SHARE_PATH=
Sat Sep 15 00:23:37 IST 2018
===> Step preinst. USER=syncthing GROUP=sc-syncthing SHARE_PATH=
Sat Sep 15 00:23:37 IST 2018
===> Step postinst. USER=syncthing GROUP=sc-syncthing SHARE_PATH=
Installing service configuration /var/packages/syncthing/conf/syncthing.sc
Invoke service_postinst
Granting 'sc-syncthing' unix ownership on /volume1/@appstore/syncthing/var
Sat Sep 15 00:23:38 IST 2018
===> Step postupgrade. USER=syncthing GROUP=sc-syncthing SHARE_PATH=
Granting 'sc-syncthing' unix ownership on /volume1/@appstore/syncthing/var
Sat Sep 15 00:35:22 IST 2018
===> Step preuninst. USER=syncthing GROUP=sc-syncthing SHARE_PATH=
Removing service configuration syncthing.sc
Sat Sep 15 00:35:23 IST 2018
===> Step postuninst. USER=syncthing GROUP=sc-syncthing SHARE_PATH=
Removing user sc-syncthing
Sat Sep 15 00:36:15 IST 2018
===> Step preinst. USER=syncthing GROUP=sc-syncthing SHARE_PATH=
Sat Sep 15 00:36:15 IST 2018
===> Step postinst. USER=syncthing GROUP=sc-syncthing SHARE_PATH=
Installing service configuration /var/packages/syncthing/conf/syncthing.sc
Adding 'sc-syncthing' to 'sc-syncthing'
Group Name: [sc-syncthing]
Group Type: [AUTH_LOCAL]
Group ID:   [65538]
Group Members: 
0:[sc-syncthing]
Invoke service_postinst
Granting 'sc-syncthing' unix ownership on /volume1/@appstore/syncthing/var
Sat Sep 15 00:52:25 IST 2018
===> Step preuninst. USER=syncthing GROUP=sc-syncthing SHARE_PATH=
Removing service configuration syncthing.sc
Sat Sep 15 00:52:25 IST 2018
===> Step postuninst. USER=syncthing GROUP=sc-syncthing SHARE_PATH=
Removing user sc-syncthing
Sat Sep 15 11:08:42 IST 2018
===> Step preinst. USER=syncthing GROUP=sc-syncthing SHARE_PATH=
Sat Sep 15 11:08:43 IST 2018
===> Step postinst. USER=syncthing GROUP=sc-syncthing SHARE_PATH=
Installing service configuration /var/packages/syncthing/conf/syncthing.sc
Adding 'sc-syncthing' to 'sc-syncthing'
Group Name: [sc-syncthing]
Group Type: [AUTH_LOCAL]
Group ID:   [65538]
Group Members: 
0:[sc-syncthing]
Invoke service_postinst

[ymartin59]

By running first start-stop-status as root, files have been created in var with "root" owner which prevents "standard" startup from Package Center as non privileged user.
As "var" content is kept with improper owner during upgrade process, it is not enough for fixing situation.
Only complete uninstall and new install can fix your syncthing configuration in "var".