The systemd exit code definitions (introduced in c586a17, refs #1324) caused
problems. Per default systemd considers a return code != 0 as failed. So when
you click on "Restart" in the WebUI an error appears:
systemd[953]: syncthing.service: main process exited, code=exited, status=3/NOTIMPLEMENTED
systemd[953]: Unit syncthing.service entered failed state.
systemd[953]: syncthing.service failed.
systemd[953]: syncthing.service holdoff time over, scheduling restart.
systemd[953]: Started Syncthing - Open Source Continuous File Synchronization.
systemd[953]: Starting Syncthing - Open Source Continuous File Synchronization...
syncthing[13222]: [LFKUK] INFO: syncthing v0.10.30 (go1.4.2 linux-amd64 default) builduser@jara 2015-03-29 07:46:44 UTC
To fix this error we have to add the "succes codes" 2, 3, 4 to
"SuccessExitStatus":
syncthing[13006]: [LFKUK] INFO: Restarting
syncthing[13006]: [LFKUK] OK: Exiting
systemd[953]: syncthing.service holdoff time over, scheduling restart.
systemd[953]: Started Syncthing - Open Source Continuous File Synchronization.
systemd[953]: Starting Syncthing - Open Source Continuous File Synchronization...
syncthing[13031]: [LFKUK] INFO: syncthing v0.10.30 (go1.4.2 linux-amd64 default) builduser@jara 2015-03-29 07:46:44 UTC
To make sure that syncthing restarts in case of error, and to make sure
that "Restart=on-failure" actually works, let's remove
"RestartPreventExitStatus=1". Systemd considers this as an error per
default and the restart will be triggered successfully.
This reverts the GC behavior to the Go default of triggering GC when the
heap has grown 100% compared to after the previous GC. We were setting
this to 25% to keep memory usage at a minimum, but it has a pretty
severe performance cost (especially when syncing large files) as we keep
triggering GC too often.
This documents the tweak in the `-help` message so users can decide for
themselves, and sticks to whatever the Go runtime developers thinks is
best for the default.
We need an explicit chmod() when creating a new directory.
Otherwise a new directory may be created with a different permission
from the one received from an originating device, because the umask
is applied to the mode given to mkdir().
The incorrect permission is later sent back to the originating device
and the original permission will be lost.
