Version 38 runs fine. When v42 is run as Mac LaunchAgent, I see nothing in the log file. When run from the Mac command line, syncthing immediately aborts with “illegal instruction”.
bmmbp:bin brian$ ./syncthing.0.14.42-illegal-instruction
Illegal instruction
bmmbp:bin brian$
Any way to make this work? I’m running an older version of a Mac, but “illegal instruction” seems to be a hard kill, and not an OS-version dependent thing.
I personally hope that we don’t back down and drop support for operating systems that are not supported by the vendor itself. You can probably try to compile syncthing yourself if you wish to keep using it.
Your comment is confusing, probably because you left one too many “not” in it. Based on the demeanor of your reply, I think you meant “I personally hope that we don’t support OS that are not supported by the vendor itself”. Your curt reply seems to indicate that you are aware of the problem and have no cause to mitigate or change it. If I misunderstood, please repost clarifying what you mean.
If I DID understand what you meant to say, that makes me sad. I’m sure you’re a mean and keen program developer that is part of offering Syncthing for free to the community. But you may strangling your own success.
Stability is invaluable to me as a user. If I spend 40% of my time doing upgrades, updates, version repairs, and negotiating whatever someone else things needs to be changed, that is a burden. Is the goal to write a cool program with the newest technology -OR- is the goal to write something that users really value? I think it should be the latter, but I don’t own that decision because you are the one putting in all the effort to develop this program.
For perspective, TotalCommander and Irfanview have become my absolute GO-TO apps, mostly because they have been stable, with some increasing features, for about 20 years. I want Syncthing to become one of my base apps that I can trust for years. I understand that I don’t get to choose the development paradigm because you have development skills beyond me. However, at least hear the other side from the user community. It’s all about what you really want: are you doing software new coolness or are you answering a need among the user community?
For me, it looks like I’ll be stuck at v.40 forever. For others, at a minimum, please make NOT upgrading versions the install default. The prior poster simply automatically had syncthing quit working with no explanation. At least in my case, I have dealt with this type of thing before and manually allow updates when I have time to deal with crashes.
As explained in the issue explains, this is not our decision, but Go not supporting such an old OSX version (neither is apple, support ended in 2014 - personally I would worry about running such an outdated OS before even thinking about Syncthing). Of course we could go to the length of keeping and testing builds for every outdated but still in use OS there is, but beside the (possibly doable) coding part that would mean keeping a build/test system of that OS and version. “We” in this case means calmh, which graciously offers and maintains all our infrastructure. Now compare that to the effort you have: Either jiust use an old but compatible (0.14.x) version (no effort) or get the source, build and test it locally. If building works, you’re good to go, if it doesn’t you can always ask here in the forum and even if nobody knows a solution, you can still go back to the old but compatible version approach.
Simon,
Yes. True. I’ll have to look into building. Currently just running on the older syncthing version until that creates another problem I can’t work around.
Plus, we have to make custom builds to support it or otherwise give up on providing some features to newer platforms.
Probably relevant, though I’m not 100% sure where the illegal instruction comes in as that’s a CPU and not OS thing: Mac OS 10.6.8 32 bit crash, v0.14.41
I’m still open to making the 32 bit Mac build special as it’s only reason for existing is compatibility with obsolete unsupported machines. But no one has so far said “yeah, please do that, that would be great” and as Audrius says it implies extra work and oddness.
Calmh,
Yes, I tried to emphasize your observation in my original post:
Upgraded the Mac to .40 without problem and confirmed that .41 and .42 immediately abort with an illegal instruction. I’m running the same Mac OS as the OP in the thread Calmh referenced.
Ultimately, I guess it’s a developer decision - what range of users will syncthing support? Those with the newest and best, or a larger range of users? Syncthing already pursues a reputation of broad platform types (each with some ops and feature limits). It might be reasonable to think of older OSes as a different platform type.
As a continuity issue, no need to reach back and support everything, but if syncthing did/does support an OS, and you bring a user on board, that is a user base worth keeping because they’re already invested in syncthing.
Calmh, you mentioned releasing “older” 32-bit Mac builds. I think any 64-bit Mac would also run a 32-bit build. So maybe you can release a build for older machines every 3rd or 5th version or something like that.
I would be happy to do compile and release for older compatibility, but I don’t have the skill set to do so. Also, I think you’ve said that Go requires at least Mac 10.8 and stripping Go out of the picture would be architecturally impossible, right?
They could, and this is part of the problem. Currently the 32 bit build is equivalent to the 64 bit build, except it uses a crappier instruction set and will crash if it needs more than 500 or so megs of RAM. It’ll mostly just work if someone uses it by accident on modern hardware.
To make it work on pre-10.8 OSX we need to disable the filesystem notification feature, making it a strictly worse edition and causing support issues for the people who download it accidentally and wonder why it doesn’t work.
I’m also suspicious against the illegal instruction bit, as that is another problem that shouldn’t be caused by linking against the system libraries. However I can’t debug it, lacking the relevant hardware. I think someone who actually has one of these and wants it to work will have to carry the torch.
It’s not that I don’t care, but it is an obscure issue that affects less than a tenth of a percent of the user base so there are lots of bigger fish to fry.
There is also a workaround - use an older version of Syncthing, or build yourself (maybe). Using old hardware and operating systems is fine, but part of that life is accepting that you may be not be able to run the absolute latest version of everything else.
Calmh,
I’ll run .40 as long as I can, kicking the upgrade can down the road. Thanks for your thoughts.
Regarding the illegal instruction, if you know of some way to collect debug information when a Mac runs a command line program, I’d be happy to send you the information.
I also have a old Mac Pro that is just my syncthing box (lots of internal drive bays!) and I believe the 64bit version is doing the same thing. I am staying on an older build, and turned off auto update to prevent it from breaking itself.
I can completely understand wanting to leave this OS / old machine behind, Apple certainly has, some metrics of how many users this effects would maybe add some context to this discussion, there is some sort of hack that can be performed to install the latest OS, I have not needed to try it, until now.
The lack of warning that an auto upgrade would be unable to even start did catch me out a bit, but downgrading to the last version that worked seemed to be okay, it does now mean I am running different versions on different nodes, so I can see that causing trouble in the future, but for now it seems okay.
I would be able to justify replacing this machine if I had to, I’m just trying to keep it out of landfill for as long as possible.
We didn’t warn about the auto upgrade breaking this because we were not aware of it, because it isn’t a configuration we test. It used to work due to a combination of luck and attention to backwards compatibility, but the luck has run out.
Currently there are 24 darwin-386 users reporting in out of a total 34334.
Thank you for the reply Jakob, I am running 64bit on OS 10.7.4 This is the version I am running:
syncthing v0.14.26 “Dysprosium Dragonfly” (go1.8 darwin-amd64) jenkins@build.syncthing.net 2017-03-23 11:04:35 UTC
And again, it is not a priority for me that this be addressed, just adding some data to the thread, I can think of far more important things to focus on than decade old Mac Pros
Thanks again.
I’m not following what needs to be addressed here. Are you saying you’re getting an “illegal instruction” trap using the 64 bit binary on your 64 bit Mac, on anything newer than 0.14.26? That seems odd.
Jakob,
In my case, I have a 64-bit binary on my Intel 64-bit Mac running 10.6.8. Anything newer than Syncthing 0.14.40 (.41 and .42) immediately aborts with the illegal instruction error message shown in the original post. So my syncthing is locked down at v.40 for the life of that machine, probably. I have one more OS upgrade in my desk drawer (10.7) but that would change some security methods on the Mac that I can’t afford to break right now.
On the good side, .40 syncthing seems to work fine with newer Syncthing on my other computers.
I understand everything about not supporting old OSes. This info is just for you to think about what cause “illegal instruction”. That may be indicative of bigger problems lurking for the future. Perhaps there are issues with Go libraries at a deeper level. I believe this is the type of work/effort that happens with steady upgrades. That’s why, personally, I value stable software combinations and architectures so much.
All the best.
Odd, indeed.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.