syncthing-bin

Hello. This package is really useful. Thank you, man!

I have a question about updating. The frontend tells me to be not allowed to update.

Do I have to do anything ? Maybe set permissions? Or can I ignore and wait for updating in storeman?

Thanks again

Stefan

Mon, 2018/06/25 - 12:55

Sorry, for not updating this. My plan was to make an installer for syncthing and discontinue this package as it is just a repackaging for the binary (didn't manage to compile the binary myself) and syncthing has a good updating mechnism itself.

So I would recommend to you to uninstall this package (and syncthing-inotify (it is discontinued by upstream, syncthing has inotify now built-in)) and install the binary manually somewhere in your home path and then let syncthing update itself. I would not recommend leaving syncthing-binary in system path and just change permission.

If you need some help for this, let me know.

DarkTuring

Thu, 2017/08/10 - 17:20

I am getting the following inotify error. The permanent fix to the described for the inotify systemctl.conf doesnt work for me. Please check if you are getting the same error amd if there is a fix for it. Notice 2017-08-10 07:08:06: [Inotify] Failed to install inotify handler for SyncSD. Please increase inotify limits, see http://bit.ly/1PxkdUC for more information

Fri, 2016/12/16 - 19:06

https://github.com/syncthing/syncthing/releases/tag/v0.14.14

Two days ago syncthing 0.14.14 with important security update was released

Fri, 2016/12/16 - 23:21

Done with new systemd unit files.

Fri, 2016/12/16 - 19:04

syncthing frequently stops

For me syncthing daemon started by systemd does not run more than 1-2 hours. It stops most of the time with exit code 3. Guys have already reported such behaviour so to address this issue syncthing.service was extended with following directives:

SuccessExitStatus=3 4
RestartForceExitStatus=3 4

Unfortunately, RestartForceExitStatus is implemented since systemd v215, but Sailfish OS uses systemd 208 (and that is pretty ancient :( ). So systemd does not restart syncthing daemon as was intended by upstream.

As a workaround for myself I switched to using native syncthing daemonizing method with master daemon watching for worker daemon. At least it seems to restart worker on demand. Here is my workaround (changed daemon run cmd to exclude -no-restart switch):

$ cat /home/nemo/.config/systemd/user/syncthing.service
[Service]
ExecStart=
ExecStart=/usr/bin/syncthing -no-browser -logflags=0

And don't forget `systemctl --user daemon-reload; systemctl --user restart syncthing`

Fri, 2016/12/16 - 23:04

Yes, you are right I already came up on this when writing syncthing-sf and forogt about it later. Do you think this unit is ok:

EDIT: oh, i see...

[Unit] Description=Syncthing - Open Source Continuous File Synchronization Documentation=http://docs.syncthing.net/ After=network.target Wants=syncthing-inotify.service

[Service]
ExecStart=/usr/bin/syncthing -no-browser -logflags=0

[Install]
WantedBy=default.target

Fri, 2017/01/27 - 19:16

Finally I've switched to

[Service]

ExecStart=/usr/bin/syncthing -no-browser -no-restart -logflags=0
Restart=on-failure

Systemd appears to restart service just fine if told to. In other words commenting

SuccessExitStatus=3 4

in upstream service file is enough. But memory savings in comparison to variant with watchdog syncthing process is under measure error, i.e. there is no visible difference in memory consumption.

Sun, 2017/01/29 - 19:57

Ok, thanks. Will keep it in mind for next release.

Tue, 2016/12/13 - 14:32

>The package contains the binary downloaded from syncthing.net.

I've compared binaries from https://openrepos.net/sites/default/files/packages/5162/syncthing-bin-0.... and https://github.com/syncthing/syncthing/releases/download/v0.14.13/syncth...

$ du -b syncthing-bin-0.14.13-1.armv7hl.rpm_extracted/usr/bin/syncthing syncthing-linux-arm-v0.14.13/syncthing
12132568        syncthing-bin-0.14.13-1.armv7hl.rpm_extracted/usr/bin/syncthing
12134301        syncthing-linux-arm-v0.14.13/syncthing

Why do these binaries differ? Seems suspicious to me.

Tue, 2016/12/13 - 22:49

Ok, this happens due to binary-stripping when creating the package.

I disabled this now and will upload a new release.

Tue, 2016/12/13 - 01:52