Closed twofaktor closed 8 months ago
Well .. “initial synch” is defined differently than what people expect; it’s the first synch that happens when fulcrum starts up. Whether fulcrum is at block NIL, block 1, or block 800,000.. usually when it starts up it downloads all blocks from where it is to tip — this is the initial synch (it needs to do this because if it’s been offline for a while it’s guaranteed to be behind the tip). It does this as a special task before it opens up tcp listening ports..
Maybe the docs/help needs changing to specify this more clearly as I see how it can confuse just about everybody the way it’s worded.
EDIT: The above explanation is incorrect. See my comment below.
Oh wait you know what? I'm wrong 100%. I just checked the code. You are right in that this option really has no effect on the first synch at startup. You were 100% correct in your initial bug report. The app ignores this options on the first synch at startup typically. Only on the actual initial synch does it use this option.
My bad -- I just got home and opened up the code.
Yeah so what's going on is the arg parser has no way of knowing whether the --fast-sync
option is legit going to be applied or not (that decisions happens later), but it DOES enforce the memory checking thing up-front.
Hmm.
This def is a surprising behavior of the app .. not sure if I would classify it as a bug per se.
Sorry for the false explanation before. I mis-rembered how this worked and who was responsible for what I had to check the code again (I implemented this like ~1.5 years ago, heh).
You know what? I'll move the enforcement to be a non-fatal error to later in the pipeline. This way you can leave your config file undisturbed. Will fix this.
Ok, I pushed 2c1b263 which addresses the issue you experienced. Are you set-up to re-build Fulcrum and check that it solves the situation you encountered?
By the way thanks for the bug report. If this happened to you, and it annoyed you enough to report it -- chances are it annoyed others too in the past or will in the future!
Closing for now.. report back if it still happens.
Thanks again!
Uhm...I don't compile Fulcrum from source code (there are no easy instructions to get this on the README 😜) and I can see you didn't change the precompiled binaries, should I wait for the next 1.9.6 release to test it?
Thanks for your fast response ❤️
Hmm. I could just post up some binaries here in this thread. What platform? x86_64 linux? arm64 linux?
Hmm. I could just post up some binaries here in this thread. What platform? x86_64 linux? arm64 linux?
If you can, I use both arches (x86_64 linux + arm64 linux)
Anyway, I am approaching to tell you, that since 1.9.2, I can't use Fulcrum precompiled arm64 binary on Raspberry OS arm64 (bullseye) - Debian 11 based, it shows me this error:
Fulcrum: /lib/aarch64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by Fulcrum)
Fulcrum: /lib/aarch64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by Fulcrum)
Fulcrum: /lib/aarch64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.13' not found (required by Fulcrum)
Fulcrum: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by Fulcrum)
Fulcrum: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by Fulcrum)
Fulcrum: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by Fulcrum)
I think since that release, you updated dependencies and your precompiled binary is no longer compatible with this OS version, I will need from now on I will have to build it from the source code, am I wrong?
I could open a new issue to discuss this if you prefer and do not mix both topics
Thanks!
Oh yeah what happened is I am using a new docker image to build it. Yeah, I think that may have broken for some people. It needs a newer glibc, etc. Yes, open a new issue.
I'll post both binaries in here... and sign them. Off latest master.
Oh yeah what happened is I am using a new docker image to build it. Yeah, I think that may have broken for some people. It needs a newer glibc, etc. Yes, open a new issue.
New issue opened: https://github.com/cculianu/Fulcrum/issues/209
x86_64 linux:
Fulcrum-1.9.5-2c1b263-x86_64-linux.tar.gz
signature for above (signed the binary itself).. github won't let me attach it for some reason so i'm pasting it here:
-----BEGIN PGP SIGNATURE-----
iHUEABEIAB0WIQTUZRNfl9AEfhjpncMhgQpUIDHALAUCZUkGpgAKCRAhgQpUIDHA
LJLFAP4z55tHiasgGNCJMmzOgtYO8WbhH0E4uJV41B+HW8SuCgEAnkJ3Dog7XtJK
tqxQRUlV9x/tjWwu6iemXFBTHZNSyLs=
=SUcw
-----END PGP SIGNATURE-----
x86_64 linux:
Fulcrum-1.9.5-2c1b263-x86_64-linux.tar.gz
signature for above (signed the binary itself).. github won't let me attach it for some reason so i'm pasting it here:
-----BEGIN PGP SIGNATURE----- iHUEABEIAB0WIQTUZRNfl9AEfhjpncMhgQpUIDHALAUCZUkGpgAKCRAhgQpUIDHA LJLFAP4z55tHiasgGNCJMmzOgtYO8WbhH0E4uJV41B+HW8SuCgEAnkJ3Dog7XtJK tqxQRUlV9x/tjWwu6iemXFBTHZNSyLs= =SUcw -----END PGP SIGNATURE-----
Ok, solved!! thanks!! 🔥
Anyway, will be this fix included in the next v1.9.6 release, right?
Anyway, will be this fix included in the next v1.9.6 release, right?
Yeah, for sure.
Hey that's pretty cool console highlighting you got going on -- off-topic but: how do you do that?
Hey that's pretty cool console highlighting you got going on -- off-topic but: how do you do that?
MobaXterm default config, nothing more 😁
Ah never used MobaXterm. Pretty cool. I'll check it out.
EDIT: Oh, it's for Windows. I'll try it out in my Windows box..
After the initial sync, I found this error appeared me when I restart Fulcrum:
According to these lines, this requirement should not exist outside of the initial sync: https://github.com/cculianu/Fulcrum/blob/master/doc/fulcrum-example-config.conf#L706-L707
This is solved by commenting on that line in the configuration file, but I think it should not be the expected behavior according to the parameter comment
Is it a known issue?