Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

--fast-sync option issue #208

Closed
twofaktor opened this issue Nov 6, 2023 · 15 comments
Closed

--fast-sync option issue #208

twofaktor opened this issue Nov 6, 2023 · 15 comments
Labels
correctness Improvements to correctness

Comments

@twofaktor
Copy link

twofaktor commented Nov 6, 2023 •
edited
Loading

After the initial sync, I found this error appeared me when I restart Fulcrum:

Started Fulcrum.
Oct 31 08:46:33 minibolt Fulcrum[3602272]: [2023-10-31 08:46:33.999] fast-sync: Specified value (4096000000 bytes) is too large to fit in available system memory (limit is: 3903692800 bytes)
Oct 31 08:46:33 minibolt Fulcrum[3602272]: [2023-10-31 08:46:33.999] Use the -h option to show help.
Oct 31 08:46:34 minibolt systemd[1]: fulcrum.service: Main process exited, code=exited, status=1/FAILURE

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?
@twofaktor twofaktor changed the title [BUG] Feature fast-sync not working properly [BUG] fast-sync not working properly Nov 6, 2023
@cculianu
Copy link
Owner

cculianu commented Nov 6, 2023 •
edited
Loading

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.

@cculianu cculianu changed the title [BUG] fast-sync not working properly fast-sync question Nov 6, 2023
@cculianu cculianu added question Further information is requested QA Ensure quality (minor fixups, etc) documentation Improvements or additions to documentation labels Nov 6, 2023
@cculianu
Copy link
Owner

cculianu commented Nov 6, 2023 •
edited
Loading

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).

@cculianu cculianu removed documentation Improvements or additions to documentation question Further information is requested QA Ensure quality (minor fixups, etc) labels Nov 6, 2023
@cculianu cculianu changed the title fast-sync question --fast-sync option issue Nov 6, 2023
@cculianu cculianu added question Further information is requested wontfix This will not be worked on labels Nov 6, 2023
@cculianu
Copy link
Owner

cculianu commented Nov 6, 2023

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.

@cculianu cculianu added correctness Improvements to correctness and removed question Further information is requested wontfix This will not be worked on labels Nov 6, 2023
@cculianu cculianu self-assigned this Nov 6, 2023
cculianu added a commit that referenced this issue Nov 6, 2023
@cculianu
Change to the way --fast-sync is checked and enforced.
2c1b263 
It turns out some users leave this option alive in their conf files, so
it can cause intermittent startup failures if the option happens to be
in the conf file, even after initial synch, and the machine happens to
lack enough available RAM at startup.

But after initial synch this option is ignored anyway so enforcing it at
startup is almost nonsensical.

The check has been moved later into the pipeline -- into Storage.cpp,
and it becomes a soft check, whereby if the --fast-sync option is there
it will just be capped at available physical RAM should it happen to
exceed it.

Fixes issue #208.
@cculianu
Copy link
Owner

cculianu commented Nov 6, 2023 •
edited
Loading

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!

@cculianu cculianu closed this as completed Nov 6, 2023
@cculianu cculianu removed their assignment Nov 6, 2023
@twofaktor
Copy link
Author

twofaktor commented Nov 6, 2023 •
edited
Loading

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 ❤️

@cculianu
Copy link
Owner

cculianu commented Nov 6, 2023

Hmm. I could just post up some binaries here in this thread. What platform? x86_64 linux? arm64 linux?

@twofaktor
Copy link
Author

twofaktor commented Nov 6, 2023 •
edited
Loading

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!

@cculianu
Copy link
Owner

cculianu commented Nov 6, 2023

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.

@twofaktor twofaktor mentioned this issue Nov 6, 2023
Closed
@twofaktor
Copy link
Author

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: #209

@cculianu
Copy link
Owner

cculianu commented Nov 6, 2023

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-----

@twofaktor
Copy link
Author

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!! 🔥

imagen
imagen

Anyway, will be this fix included in the next v1.9.6 release, right?

@cculianu
Copy link
Owner

cculianu commented Nov 6, 2023

Anyway, will be this fix included in the next v1.9.6 release, right?

Yeah, for sure.

@cculianu
Copy link
Owner

cculianu commented Nov 6, 2023

Hey that's pretty cool console highlighting you got going on -- off-topic but: how do you do that?

@twofaktor
Copy link
Author

Hey that's pretty cool console highlighting you got going on -- off-topic but: how do you do that?

MobaXterm default config, nothing more 😁

@cculianu
Copy link
Owner

cculianu commented Nov 6, 2023 •
edited
Loading

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..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
correctness Improvements to correctness
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@cculianu @twofaktor