Problem with inconsistent Syncthing version numbers on CentOS 7...

[root@2 ~]# yum list installed | grep syncthing

syncthing.x86_64 1.23.5-1.el7 @Centos7-DC

[root@2 ~]# syncthing --version

syncthing v1.21.0 “Fermium Flea” (go1.20.4 linux-amd64) mockbuild@32b1ae7b86724add898b73069a768f81 2023-06-06 20:46:31 UTC [noupgrade, purego]

[root@2 ~]# cat /etc/redhat-release

CentOS Linux release 7.7.1908 (Core)

It’s not entirely relevant to your question, but yum accepts a search pattern for the 3rd argument, so piping into grep isn’t necessary:

yum list installed syncthing

Is that a data center channel?

Syncthing isn’t in the stock @base and @updates channels for CentOS 7.

syncthing --version returning a different version isn’t unusual. It’s fairly common to have multiple versions of tools on a server.

Issuing a command without the full pathname (e.g., /usr/bin/syncthing) results in crawling the search path and executing the first match found.

What’s the output from the following command?

echo $PATH

(Please consider updating the title of your post, because unfortunately, “What is the current version?” could be easily mistakenly interpreted as asking what the current version of Syncthing is, which is much easier to find on the downloads and GitHub release pages than it is to register and post a support question on the user forum. :wink:)

Unbelieve that I could not find how to edit the original thread. Use the link here Unofficial

[root@2 ~]# /usr/bin/syncthing --version

syncthing v1.21.0 “Fermium Flea” (go1.20.4 linux-amd64) mockbuild@32b1ae7b86724add898b73069a768f81 2023-06-06 20:46:31 UTC [noupgrade, purego]

[root@2 ~]# which syncthing

/usr/bin/syncthing

[root@2 ~]# echo $PATH

/root/perl5/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin:/usr/local/swosbf/bin:/usr/local/swosbf/bin/system:/usr/java/jdk/bin:/usr/bin:/usr/sbin:/bin:/sbin:/usr/X11R6/bin:/root/bin

Hope you don’t mind that I edited the title of the thread for you. :slightly_smiling_face:

The output from which syncthing and echo $PATH look normal.

According to the RPM file, the Syncthing binary is installed as /usr/local/bin/syncthing. What does the following command return?

rpm --query --list syncthing

Without knowing more about the sequence of events and how your CentOS box is set up, best guess is that you might have conflicting repositories configured. Would you mind posting the contents of /etc/yum.repos.d/?

One thing to try is this:

  1. killall syncthing
  2. yum autoremove syncthing
  3. yum clean all
  4. yum install syncthing

During the reinstall, note which version is going to be installed and from which repo.

I tried install the local rpm which download RPM

[root@43 yum.repos.d]# rpm -i ~/syncthing-1.23.5-1.el7.x86_64.rpm

警告:/root/syncthing-1.23.5-1.el7.x86_64.rpm: 头V4 RSA/SHA256 Signature, 密钥 ID fdf4aaa1: NOKEY

[root@43 yum.repos.d]# rpm --query --list syncthing

/usr/bin/syncthing /usr/lib/systemd/system/syncthing-resume.service /usr/lib/systemd/system/syncthing@.service /usr/lib/systemd/user/syncthing.service /usr/share/licenses/syncthing-1.23.5 /usr/share/licenses/syncthing-1.23.5/LICENSE

[root@43 yum.repos.d]# syncthing --version

syncthing v1.21.0 “Fermium Flea” (go1.20.4 linux-amd64) mockbuild@32b1ae7b86724add898b73069a768f81 2023-06-06 20:46:31 UTC [noupgrade, purego]

At this point I’d do a filesystem search for all instances of syncthing:

find / -name "syncthing"

The only way that currently comes to mind that would explain the results you’ve been posting are that either there are two (or more) different syncthing binaries on your system and the command search path leads to the older version first, or there’s a shell alias involved.

Either way, if it were me, I’d first remove Syncthing and clean things up. I’d keep going until issuing the command syncthing and /usr/bin/syncthing returns the error “command not found”.

Only then would I check to see how many Syncthing packages are available from the configured repos – i.e., a yum list syncthing should only return one match with the version you want. Anything else requires more extensive cleanup first.

I tested. I think it’s this rpm package that’s the problem.

[root@dc-kafka-231 ~]# rz

rz waiting to receive. Starting zmodem transfer. Press Ctrl+C to cancel. Transferring syncthing-1.23.5-1.el7.x86_64.rpm… 100% 8490 KB 8490 KB/sec 00:00:01 0 Errors

[root@dc-kafka-231 ~]# ll

total 8492 -rw-r–r-- 1 root root 8694092 Jun 15 13:25 syncthing-1.23.5-1.el7.x86_64.rpm

[root@dc-kafka-231 ~]# rpm -i ~/syncthing-1.23.5-1.el7.x86_64.rpm

warning: /root/syncthing-1.23.5-1.el7.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID fdf4aaa1: NOKEY

[root@dc-kafka-231 ~]# rpm --query --list syncthing

/usr/bin/syncthing /usr/lib/systemd/system/syncthing-resume.service /usr/lib/systemd/system/syncthing@.service /usr/lib/systemd/user/syncthing.service /usr/share/licenses/syncthing-1.23.5 /usr/share/licenses/syncthing-1.23.5/LICENSE

[root@dc-kafka-231 ~]# syncthing --version

syncthing v1.21.0 “Fermium Flea” (go1.20.4 linux-amd64) mockbuild@32b1ae7b86724add898b73069a768f81 2023-06-06 20:46:31 UTC [noupgrade, purego]

[root@dc-kafka-231 ~]# find / -name “syncthing”

/usr/bin/syncthing

[root@dc-kafka-231 ~]# cat /etc/redhat-release

CentOS Linux release 7.7.1908 (Core)

Looks like it.

Also, whoa, zmodem. It’s been a while since I saw that last. :slight_smile:

Was totally not expecting to see rz. :smiley:

I loaded the RPM from Copr, converted it with rpm2archive, and unpacked the tarball to take a peek.

Sure enough, the syncthing binary says it’s 1.21.0 even though the RPM is labeled as 1.23.5. Copr’s build log for the package says it’s supposed to be 1.23.5 and when I checked the Syncthing source tarball that was used the release file also said 1.23.5.

Check the log build.log.gz

  • go run build.go -no-upgrade -version v1.21.0 install all

I’m not sure if this is what caused the problem here.?

:man_facepalming:

yup… it unpacks syncthing-source-v1.23.5.tar.gz but when it comes time to actually compile it… then when the RPM is assembled it’s assigned 1.23.5. :smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.