I’ve checked my NAS this morning where v1.5.0 was expected to be (still) running. Instead, it showed v1.6.0 and 2 hours uptime. Checking the log it had automatically upgraded. I had set “No upgrades”, of course.
Did I miss anything or is this a bug?
Log:
[start] 10:21:55 INFO: syncthing v1.5.0 "Fermium Flea" (go1.13.10 linux-amd64) teamcity@build.syncthing.net 2020-04-21 20:45:03 UTC
[start] 10:21:55 INFO: Using large-database tuning
[VPYAM] 10:21:56 INFO: My ID: VPYAMUE-D44JYED-5DNCNOV-QNNFESH-QLVRLP4-525HK3X-GK5RXN4-XXXXXX
[VPYAM] 10:21:57 INFO: Single thread SHA256 performance is 373 MB/s using crypto/sha256 (368 MB/s using minio/sha256-simd).
[VPYAM] 10:21:57 INFO: Hashing performance is 316.42 MB/s
[VPYAM] 10:21:57 INFO: Overall send rate is unlimited, receive rate is unlimited
[VPYAM] 10:21:57 INFO: TCP listener (0.0.0.0:Port) starting
[VPYAM] 10:21:57 INFO: Established secure connection to REDACTED at IP:40710-IP:Port/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256
[VPYAM] 10:21:57 INFO: Device REDACTED client is "syncthing v1.5.0" named "NAS01" at IP:40710-IP:Port/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256
(...)
[VPYAM] 08:03:53 WARNING: Automatically upgraded to version "v1.6.0". Restarting in 1 minute.
[VPYAM] 08:04:29 INFO: Established secure connection to REDACTED at IP:56850-IP:Port/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256
[VPYAM] 08:04:29 INFO: Device REDACTED client is "syncthing v1.6.0" named "NAS01" at IP:56850-IP:Port/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256
[VPYAM] 08:04:29 INFO: Device REDACTED folder "Installationsquellen" (n4q4z-ohpfz) has a new index ID (0x8A5CCB3E5E3ABD7B)
[VPYAM] 08:04:29 INFO: Device REDACTED folder "Archiv" (ngnzq-fyq6p) has a new index ID (0xA765EC859C4FB02E)
[VPYAM] 08:04:29 INFO: Device REDACTED folder "Images" (nux7m-yfmea) has a new index ID (0xE2D1DB72902A0F6A)
[VPYAM] 08:04:29 INFO: Device REDACTED folder "Temp" (omxrd-dex9c) has a new index ID (0xC3EFF4DE86836194)
[VPYAM] 08:04:53 INFO: Connection to REDACTED at IP:56850-IP:Port/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256 closed: reading length: read tcp4 IP:56850->IP:Port: use of closed network connection
[VPYAM] 08:04:53 INFO: TCP listener (0.0.0.0:Port) shutting down
[VPYAM] 08:04:53 INFO: Exiting
[start] 08:04:53 INFO: syncthing v1.6.0 "Fermium Flea" (go1.14.4 linux-amd64) teamcity@build.syncthing.net 2020-05-20 09:04:45 UTC
[start] 08:04:53 INFO: Using large-database tuning
[VPYAM] 08:04:54 INFO: My ID: VPYAMUE-D44JYED-5DNCNOV-QNNFESH-QLVRLP4-525HK3X-GK5RXN4-XXXXXX
[VPYAM] 08:04:55 INFO: Single thread SHA256 performance is 372 MB/s using crypto/sha256 (367 MB/s using minio/sha256-simd).
[VPYAM] 08:04:55 INFO: Hashing performance is 315.53 MB/s
[VPYAM] 08:04:55 INFO: Migrating database to schema version 10...
[VPYAM] 08:04:56 INFO: Migrating database to schema version 11...
[VPYAM] 08:04:56 INFO: Compacting database after migration...
[VPYAM] 08:05:01 INFO: Detected upgrade from v1.5.0 to v1.6.0
[VPYAM] 08:05:01 INFO: Checking db due to upgrade - this may take a while...
(...)
I’m pushing a 1.6.1 with a corrected auto upgrade routine. Won’t help while you’re still on 1.5.0 (it will upgrade to 1.6.1), but it should then work moving forwards towards 1.7.0 etc.
That’s because you’re on a build that doesn’t have upgrade built in, or it’s been disabled by environment variable. Both of those ways are unaffected by this issue.
I’m fairly sure you’re wrong about either where the program comes from or not having set STNOUPGRADE. Or you’re using some wrapper that disables upgrades and manages it externally.
Hmm, maybe an error fetching upgrades manifests the same way in the GUI. That’s misleading in that case… Or, well, “unavailable” is true and it might just be me misinterpreting the error message. Sorry.
It reminded me of the error we had many s ago when we fetched the update list directly from Github and their API just stopped working after too many requests.
This happened to me as well. Unfortunately it completely broke my network as 1.5.0 and 1.6.x use incompatible quic protocols.
Interestingly, my “server” (which does not have upgrades barred by administrator but where upgrades were turned off) did upgrade and the “clients” which all do have upgrades barred by administrator all did not upgrade.
Is it only that environment variable which administratively bars upgrades or is there another mechanism?
EDIT: Recommend setting the immutable bit on the binary to prevent bugs from upgrading it in the future.
It should fall back to a different transport in that case or are you purely relying on quic?
Also, I was under the assumption that different versions of the draft were still compatible, but you seem to suggest they are not. Do you have an error you’ve seen?
My setup is essentially client-server. A “server” with a quic4 listener, and clients that explicitly are given its address and no discovery.
WRT quic drafts, I am getting an error when a 1.5.0 “client” tries to connect to the now 1.6.1 server. It’s not shown in the logs, it’s only displayed on the web interface: “No compatible QUIC version found. We support [QUIC WG DRAFT-24], server offered [0x8aaafa7a 0xff00001b]”
I should be, and will probably be reverting. I’m a fan of UDP in general and I was curious about whether a protocol built on it had anything to offer speed wise. But using a draft protocol in my environment wasn’t the best move.
s ago when we fetched the update list directly from Github and their API just stopped working after too many requests.