Sure, something like syncthing > /tmp/somelog.txt 2>&1. Are you sure that it’s not simply your shell that is killing syncthing when you log out of telnet?
Thanks I’ll try! Yes sure, I check every time with web gui, it’s running for one or a couple of hours (or more sometimes) and in sync! In background process. But if I leave drives on writing log I think that issue won’t appear! Will try on /tmp as You say!
With new version 0.8.9 connection seems more stable, no shutdown for 5 hours, and goes on…
Today no luck! "10:40:53: Connection to Zyxel NSA320S closed: unexpected EOF" NAS drives in sleep mode… so no connection till I’ll restart them… and restart Syncthing. I’ll see log on NAS if there’s something useful… Update: “18:05:37: Connection to Zyxel NSA320S closed: read tcp —.–.—.–:22000: connection reset by peer”
It’s the logs from the NAS that are necessary…
Sorry no log found for the casual shutdown! I’ve only seen that if Syncthing on NAS is started after office PC connection goes on ok, if Syncthing starts before office PC does not connect or disconnect and shuts down on NAS.
This morning Syncthing refused to start, and here the log (this time there is a log 
):
“[5J5KW] 09:48:24 INFO: Starting web GUI on http://—.---.-.-:8888/
[5J5KW] 09:48:24 INFO: Populating repository index
panic: runtime error: slice bounds out of range
goroutine 1 [running]:
runtime.panic(0x34d2c0, 0x7aae12)
/usr/local/go/src/pkg/runtime/panic.c:266 +0x134
github.com/calmh/syncthing/xdr.(*Reader).ReadBytesMaxInto(0x10cc8320, 0x40, 0x0, 0x0,
0x0, …)
/Users/jb/src/github.com/calmh/syncthing/xdr/reader.go:58 +0x478
github.com/calmh/syncthing/xdr.(*Reader).ReadBytesMax(0x10cc8320, 0x40, 0x10cdc780, 0x20,
0x20)
/Users/jb/src/github.com/calmh/syncthing/xdr/reader.go:36 +0x48
github.com/calmh/syncthing/protocol.(*BlockInfo).decodeXDR(0x10b792d0, 0x10cc8320, 0x0,
0x0)
/Users/jb/src/github.com/calmh/syncthing/protocol/message_xdr.go:152 +0x50
github.com/calmh/syncthing/protocol.(*FileInfo).decodeXDR(0x10d2dee8, 0x10cc8320, 0x0,
0x0)
/Users/jb/src/github.com/calmh/syncthing/protocol/message_xdr.go:113 +0x1b8
github.com/calmh/syncthing/protocol.(*IndexMessage).decodeXDR(0x40101948, 0x10cc8320,
0x10b3482c, 0x11f0c8)
/Users/jb/src/github.com/calmh/syncthing/protocol/message_xdr.go:56 +0x154
github.com/calmh/syncthing/protocol.(*IndexMessage).DecodeXDR(0x40101948, 0x4000cc20,
0x10c5ec80, 0x0, 0x0)
/Users/jb/src/github.com/calmh/syncthing/protocol/message_xdr.go:39 +0x88
github.com/calmh/syncthing/model.(*Model).loadIndex(0x10caba50, 0x10cac4c0, 0xf,
0xbedd7eb9, 0x33, …)
/Users/jb/src/github.com/calmh/syncthing/model/model.go:730 +0x3dc
github.com/calmh/syncthing/model.(*Model).LoadIndexes(0x10caba50, 0xbedd7eb9, 0x33)
/Users/jb/src/github.com/calmh/syncthing/model/model.go:684 +0xc4
main.main()
/Users/jb/src/github.com/calmh/syncthing/cmd/syncthing/main.go:364 +0x1604
goroutine 4 [chan receive]:
main.trackCPUUsage()
/Users/jb/src/github.com/calmh/syncthing/cmd/syncthing/gui_unix.go:18 +0x124
created by main.init2
/Users/jb/src/github.com/calmh/syncthing/cmd/syncthing/gui_unix.go:11 +0x3c
goroutine 6 [chan receive]:
main.saveConfigLoop(0x10beedc0, 0x3e)
/Users/jb/src/github.com/calmh/syncthing/cmd/syncthing/main.go:454 +0x48
created by main.main
/Users/jb/src/github.com/calmh/syncthing/cmd/syncthing/main.go:164 +0xcfc
goroutine 7 [sleep]:
time.Sleep(0x2a05f200, 0x1)
/usr/local/go/src/pkg/runtime/time.goc:31 +0x3c
github.com/calmh/syncthing/model.(*Model).broadcastIndexLoop(0x10caba50)
/Users/jb/src/github.com/calmh/syncthing/model/model.go:541 +0x7c
created by github.com/calmh/syncthing/model.NewModel
/Users/jb/src/github.com/calmh/syncthing/model/model.go:96 +0x374
goroutine 8 [IO wait]:
net.runtime_pollWait(0x4000eca8, 0x72, 0x0)
/usr/local/go/src/pkg/runtime/netpoll.goc:116 +0x6c
net.(*pollDesc).Wait(0x10bfc6f8, 0x72, 0x4000c890, 0xb)
/usr/local/go/src/pkg/net/fd_poll_runtime.go:81 +0x38
net.(*pollDesc).WaitRead(0x10bfc6f8, 0xb, 0x4000c890)
/usr/local/go/src/pkg/net/fd_poll_runtime.go:86 +0x34
net.(*netFD).accept(0x10bfc6c0, 0x40aa1c, 0x0, 0x4000c890, 0xb)
/usr/local/go/src/pkg/net/fd_unix.go:382 +0x2e8
net.(*TCPListener).AcceptTCP(0x10bfb540, 0x10b70808, 0xc36a8, 0xc)
/usr/local/go/src/pkg/net/tcpsock_posix.go:233 +0x50net.(*TCPListener).Accept(0x10bfb540,
0x496b0, 0x1af0a8, 0x0, 0x21acd2)
/usr/local/go/src/pkg/net/tcpsock_posix.go:243 +0x2cnet/http.(*Server).Serve(0x10b770f0,
0x4000dd10, 0x10bfb540, 0x0, 0x0)
/usr/local/go/src/pkg/net/http/server.go:1622 +0x94
net/http.Serve(0x4000dd10, 0x10bfb540, 0x4000ee20, 0x10cc8160, 0x10c4ace0, …)
/usr/local/go/src/pkg/net/http/server.go:1561 +0x7c
created by main.startGUI
/Users/jb/src/github.com/calmh/syncthing/cmd/syncthing/gui.go:90 +0x13f8”
And no way to start Syncthing (till saturday (almost) all worked)!
This I’ve seen reported before, but been unable to narrow down. Please grab the *.idx.gz files from the syncthing config directory and upload them somewhere where I can get them for troubleshooting. They will include the file names and hashes of your files, which I hope you can live with me seeing. You can send me the link in a PM if you like. Then, remove those index files and syncthing will start again.
OK, removed broken indexes and now all OK.
For other problem, still the same! If I start syncthing on office PC first all OK, if I start NAs first and then office PC no connection and then Syncthing shuts down at NAS disk sleep! Weird!
It’s really a strange thing, but it’s real, every day Syncthing startup on NAS and fully functional, but starting Syncthing on office PC no connection with NAS over Internet (same error “Connection to Zyxel NSA320S closed: read tcp —.–.—.–:22000: connection reset by peer”)
Then Syncthing in some way stops on NAS (tried > /home/shares/syncthinglog.txt 2>&1 but file is empty), no pid, no gui, no process, no activity.
Restarting Syncthing on NAS connects to other two nodes over the internet and is fully functional and stable.
Even if office PC disconnect, they can reconnect easily!
Can’t understand! 
Today new shutdown! Think for not upgrading office PC to 0.8.12. After 2 minutes of activity: $ [5J5KW] 14:41:48 FATAL: update before replace for cid 1 And Syncthing stop!
Finally got log from NAS, as asked! Only a simple “connection reset by peer”! Nothing about the shutdown of Syncthing! Shutdown happened even if disks are in activity without sleep (another app keeps them awake)! Any idea? And the new error what is?
Hi Alessandro, did you automate the start of syncthing at NAS start?
Thanks,
Max
Seems like 0.11.x is no longer getting built for ArmV5, is that correct?
If I’ve digested things correctly it requires building from source in with a specific version of Go. Is there a guide for people wanting to do that?
Use case: I’m trying to get 0.11.x running on a Synology DS213 (armv5te). The Synocommunity package is stuck at 0.10.30 and doesn’t start… the github binary for arm-10.30 does run, yay, but I can’t get arm.11.10 to run and I’m assuming that’s because it not longer include armv5.