web gui suddenly stopped working on ARM v1.21.0

I have syncthing running on my ARM-based NAS (Zyxel NSA 325 v2) for over 7 years already - never had any issues with GUI-access. Suddenly today I realized it doesn’t work anymore. Unfortunately I can’t tell if that happened after autoupdate to v1.21.0 - realized just now. (last time I used GUI around half year ago).

The system and config was untouched since ages. Sync works flawlessly though. Just GUI.

config.xml:

    <gui enabled="true" tls="true" debugging="false">
        <address>0.0.0.0:8888</address>
        <user>admin</user>
        <password>###</password>
        <apikey>###</apikey>
        <theme>default</theme>
    </gui>

logs:

[start] INFO: syncthing v1.21.0 "Fermium Flea" (go1.19 linux-arm) teamcity@build.syncthing.net 2022-08-16 08:01:49 UTC
[start] WARNING: Error opening database: resource temporarily unavailable (is another instance of Syncthing running?)
[start] INFO: syncthing v1.21.0 "Fermium Flea" (go1.19 linux-arm) teamcity@build.syncthing.net 2022-08-16 08:01:49 UTC
[start] WARNING: Error opening database: resource temporarily unavailable (is another instance of Syncthing running?)
[start] INFO: syncthing v1.21.0 "Fermium Flea" (go1.19 linux-arm) teamcity@build.syncthing.net 2022-08-16 08:01:49 UTC
[start] WARNING: Error opening database: resource temporarily unavailable (is another instance of Syncthing running?)
[start] INFO: syncthing v1.21.0 "Fermium Flea" (go1.19 linux-arm) teamcity@build.syncthing.net 2022-08-16 08:01:49 UTC
[start] WARNING: Error opening database: resource temporarily unavailable (is another instance of Syncthing running?)
[start] INFO: syncthing v1.21.0 "Fermium Flea" (go1.19 linux-arm) teamcity@build.syncthing.net 2022-08-16 08:01:49 UTC
[57PPE] INFO: My ID: ###
[57PPE] INFO: Single thread SHA256 performance is 7.9 MB/s using crypto/sha256 (6.3 MB/s using minio/sha256-simd).
[57PPE] INFO: Hashing performance is 5.76 MB/s
[57PPE] INFO: Overall send rate is unlimited, receive rate is unlimited
[57PPE] INFO: Using discovery mechanism: IPv4 local broadcast discovery on port 21027
[57PPE] INFO: Using discovery mechanism: IPv6 local multicast discovery on address [ff12::8384]:21027
[57PPE] INFO: TCP listener ([::]:22000) starting
[57PPE] WARNING: Listen (BEP/tcp): Accepting connection: accept tcp [::]:22000: accept: function not implemented
....
[57PPE] WARNING: Listen (BEP/tcp): Accepting connection: accept tcp [::]:22000: accept: function not implemented
[57PPE] INFO: Relay listener (dynamic+https://relays.syncthing.net/endpoint) starting
2022/09/12 00:19:44 failed to sufficiently increase receive buffer size (was: 110 kiB, wanted: 2048 kiB, got: 255 kiB). See https://github.com/lucas-clemente/quic-go/wiki/UDP-Receive-Buffer-Size for details.
[57PPE] INFO: QUIC listener ([::]:22000) starting
[57PPE] INFO: GUI and API listening on [::]:8888
[57PPE] INFO: Access the GUI via the following URL: https://127.0.0.1:8888/
[57PPE] WARNING: GUI/API: accept tcp [::]:8888: accept: function not implemented (restarting)
[57PPE] INFO: GUI and API listening on [::]:8888
[57PPE] INFO: Access the GUI via the following URL: https://127.0.0.1:8888/
[57PPE] WARNING: GUI/API: accept tcp [::]:8888: accept: function not implemented (restarting)
[57PPE] INFO: GUI and API listening on [::]:8888
[57PPE] INFO: Access the GUI via the following URL: https://127.0.0.1:8888/
[57PPE] WARNING: GUI/API: accept tcp [::]:8888: accept: function not implemented (restarting)
[57PPE] INFO: GUI and API listening on [::]:8888
[57PPE] INFO: Access the GUI via the following URL: https://127.0.0.1:8888/
[57PPE] WARNING: GUI/API: accept tcp [::]:8888: accept: function not implemented (restarting)
[57PPE] INFO: GUI and API listening on [::]:8888
[57PPE] INFO: Access the GUI via the following URL: https://127.0.0.1:8888/
[57PPE] WARNING: GUI/API: accept tcp [::]:8888: accept: function not implemented (restarting)
[57PPE] INFO: GUI and API listening on [::]:8888
[57PPE] INFO: Access the GUI via the following URL: https://127.0.0.1:8888/
[57PPE] WARNING: GUI/API: accept tcp [::]:8888: accept: function not implemented (restarting)
[57PPE] INFO: My name is "###"

What is this “accept: function not implemented” about? Is that a broken build? Or any ‘end of support’ era? Or was this warning like that all the time?

There’ve been at least a few similar issues reported recently. I believe you need to downgrade to v1.19.2 and disable automatic upgrades. The old Linux kernel is no longer supported by Golang.

Please check https://forum.syncthing.net/search?q=accept%3A%20function%20not%20implemented for more details.

1 Like

It still surprises me how vendors always manage to be so far behind on software versions.

Syncthing doesn’t work anymore on this NAS because it doesn’t support a feature that was implemented in Linux over 14 years ago - even though the model named here was first released 8 years ago. And of course Zyxel has produced a number of firmware updates over the years, but a port to a more recent kernel was too much to ask apparently. A common theme nowadays…

(Sorry for the rant, just disappointed with device vendors. I’m stuck with similar issues on a number of devices)

Well, Android was also stuck on very old kernel versions for quite a long time, so if Google couldn’t do it, it’s probably no surprise the others can’t…

I don’t think that’s comparable. Being “a few years” behind is a lot different to being half a dozen years behind. Android 1.6, released September 15, 2009, already supports the feature this 2014 Zyxel model fails on.

Actually, looking at Android’s version history, fresh major AOSP releases are rarely based on a Linux kernel older than a year. Of course, with patches and downstream vendors it all gets delayed to 2-3 years, but the upstream source was always recent - and certainly never 6 years behind.

You’re right that the situation on Android is better, although it was only a few years ago around 2019 that Google decided to bring the kernel closer to the mainline. Before it was very much custom, and as such difficult to upgrade and keep up-to-date.

One thing that seems common between Android phones and the NAS vendors though is that once released to the market, a device is extremely unlikely to receive any kernel upgrades with the exception of security fixes (and those aren’t guaranteed either). This means that even if buy the absolute best phone on the market today with a recent Linux kernel, it will likely stay on that kernel version basically forever. I’m not 100% sure if that’s still the case with Google-manufactured devices, but it’s certainly true for Samsung and others, which dominate the market.

Actually it’s not the kernel, but the C standard library, glibc. Go developers decided to use the newer API and drop support for the older function starting with Go 1.18 IIRC.

Since this has come up several times lately, maybe we should start bugging them to reintroduce a more backwards-compatible fallback code path. I haven’t checked whether there is already an issue for this on the golang repo. But certainly more efficient than trying to convince X hardware vendors to supply updated firmware images.

Afaik the cutoff point is kernel 2.6.36 (for ARM, it was added a little bit earlier for x86), from Oct 2010. That’s what’s needed for the accept4() syscall. Glibc shouldn’t matter, Go generally doesn’t use it.

Just for completeness, the device in question here runs kernel 2.6.31.8, so not that far away from the required one, but still too old nevertheless.

For the record, you could probably compile the current version of Syncthing with Go 1.18 and still have it functional this way a little longer (at least until Go 1.20 comes out). Alternatively, it should still be possible to revert the accept4() patch in the Go source (see the details in the other forum topic).

Puh. Thank you for all replies. Seems I’m stuck with v1.19.2, or have to upgrade my NAS hardware.

Just in case I’ve filed an issue: Legacy ARM support on releases 1.20+ · Issue #8534 · syncthing/syncthing · GitHub - who knows, may be it will be resolved by community in some way. Unfortunately I can’t file an issue on Golang community, as can’t provide a valid technical description of the issue due to lack of deeper understanding of the problem.

Yeah, unfortunately, I closed your issue because this is not something that’s easily actionable by us, nor a priority in the larger scheme of things. Sorry.

I see.

Unfortunately request to Golang maintainers seems to be not an option either, as according to minimal requirements they support 2.6.32+ ( Go 1.18 Release Notes - The Go Programming Language ). Mine is 2.6.31.8. soooo close :slight_smile:

Bad for me.

Seems I’m stuck with 1.19.2 (already rolled back). Or have to upgrade my NAS to something more modern (I hate touch working systems).

The good thing is that v1.19.2 is still very recent, so you should probably be fine with it for quite a long time.