I maintain two Raspberry Pi computers running Syncthing. One of them is happily running “v0.14.54, Linux (ARM)”. I just noticed today that the other one is stuck at version “v0.14.18-dfsg1, Linux (ARM)”.
How do I get the second one to upgrade? Where is the “Auto upgrades” option on the GUI? Did I accidentally get down some bad fork in the software on the second Pi? I don’t know what the “dfsg1” means, but maybe that was a mistake?
“Dfsg” means it’s packaged by Debian. Hence it is upgraded by apt, not by itself.
You probably want to add our apt.syncthing.net or uninstall and use the binaries from GitHub directly.
Jakob,
Thank you again for an answer that gives a little bit of new understanding that helps scope the answer. I understand 3 choices:
install from separate 3rd part repository (raspberry). Upgrades only when the OS distributor chooses to upgrade their version. Upgrade options do not show in the web GUI.
install from a syncthing.net repository. Upgrades available using apt-get externally whenever syncthing releases a new version. Upgrade options do not show in the web GUI.
install from the github compiled binaryies. Auto-pushed upgrades (or not) according to the in-GUI selection.
I decided on Option 2. I visited apt.syncthing.net from your link above and followed the instructions for using the stable repository and did and apt-get upgrade. At first the installation appeared broke when it hung without a web GUI interface. Actually, the pi was saturated re-scanning many gigabytes through an encrypted filesystem; the v 0.14.54 upgrade must rebuild indexes or something. After about 1/2 hour, everything settled down and everything appears normal.
For the ~other~ pi installation, I guess I must have used binaries from Github. It’s been almost a year since that system was stood up at a remote location, and it’s been stable enough that I’ve done nothing with it. That speaks well for the pi and for Syncthing.
On the pi I just changed, I bring up Syncthing with an @boot option with cron. I need to look at command line options for Syncthing to bring up the “terminal window” or log to a log file 'cause otherwise I’m kind of blind if something doesn’t work right upon boot.
This is my crontab entry:
@reboot /path/to/syncthing -logflags=7 2>&1 >> /var/log/syncthing/instance1.log
The log lines then look like this:
[XXXXX] 2018/12/29 15:32:22.656607 INFO: Established secure connection ...
while the user which runs syncthing has write access to /var/log/syncthing/ of course
wwelch,
Thanks!
Does the 2>&1 combine stderr and stout? Can you help me understand exactly what each part of that does? 2? >&1?
Wouldn’t the >> alone append syncthing output to the log file?
Also, how does this compare to just specifying the -logfile option on the syncthing command line? When I try your method, I get permission denied for the log file. Even with sudo. When I try the logfile method, I get no errors (and a log file).
Yes. So there only needs to be one >> to get both into the file.
For the snycthing log output, yes. But I also want errors inside the log file.
This command predates -logfile also working on non Windows OS.
How did you get your log file to create when operating the pi under the normal user “pi”?
When I run syncthing from an ssh command line with a sudo option, 2>&1 gives a permission error on the log file, however the -logfile options works.
When I run syncthing from the @reboot cron line, I get no log file. Indeed the /var/log directory is write to only root, and my pi boots up and runs syncthing under the user “pi”, so I imagine it cannot create the file.
I’d like to get a log file after starting with the @reboot method.
As I said, the folder where you want your your logfile has to writable by the user running syncthing. pipes don’t preserve sudo, so sudo some-command > somefile will write the file with the current user, not root.
I understand pipes don’t preserve sudo (so the 2>&1 won’t work), however, that seems to conflict with when I run from a command line and sudo as non root, the -logfile option DOES work. However, when I run syncthing from cron, no logfile is created (and I can’t see why because I don’t have the log available). I’ll keep working on it…
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.