I had the same problem. After changed old CPU’s to CPU’s with supporting AVX2 instruction all working fine. Connect to my node http://harvest-symbol.com:3000/ for harvesting and I will be happy, if you connect to my node with 3M XYM and more I will be happy more and more times %)
2 Likes
Thank you for this guide!
First time trying to set this up … getting similar error as DIMAS:
after running symbol-bootstrap healthcheck
Interesting - I just moved virtual server with successfully running docker/symbol-boostrap instance to another physical server, and observed exactly same issue, as Bugboy described (Unhandled promise rejection). But virtual server and OS environment is exactly the same (I just did import of whole image file of virtual server). Really strange … there’s just difference due to processors. I tested virtual server firstly on AMD Ryzen, then VM has been migrated under a little bit older Xeon.
So, could it be the issue related to some missing processor sets/flags, e.g. AVX/AVX2 ?
Hi, one way …
" sudo usermod -aG docker $USER "
1 Like
Thank you very much
also i noticed that docker have new release 1.28.6
should i install this version?
For a “new” installation it is certainly recommended to use the current version.
got the same error on Xeon E-2286G
And Xeon E-2246G
Both supporting AVX/AVX2
and at the same time works great on E-2246G which I set up a week earlier
i am confused now
Same with Xeon E5-2620 ::
2021-04-07T20:47:48.941Z info Testing http://localhost:3000/node/health
(node:8937) UnhandledPromiseRejectionWarning: #
(node:8937) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see Command-line options | Node.js v15.14.0 Documentation
ctions_mode). (rejection id: 14)
2021-04-07T20:47:48.971Z warn Rest http://localhost:3000/node/health is NOT up and running YET: {“statusCode”:503,“statusMessage”:“Service Unavailable”,“body”:"{“status”:{“apiNode”:“down”,“db”:“up”}}"}
It’s really weird. I don’t know, if this could or couldn’t be related with some updates in symbol-boostrap code. But on the first server, I’m doing upgrades continuously and it’s still working. Can be some of devs so kind and give us some hint, with what this issue could be related ?
Yeah I was getting same errors … little frustrating unable to get a node up and running. Wish there was a video tutorial on this
I’m going to switch hosting companies and see if that helps.
Hi I’ve got the same issue.
I started with fresh installed Centos 8 and followed exactly the Instructions above.
The Server is a VPS from Netcup: netcup GmbH - vServer / VPS (VPS 4000 G9) @spizzerb do you use an Virtual Private Server or an Root Server from Netcup?
I tested an older netcup RS Server: RS 4000 SAS G8SE
There it worked without any problem.
Start your bootstrap with -d option (symbol-bootstrap start -d)
Next check what died:
docker ps -a (you will see container that exited)
next you can check logs for this container
docker logs <container_id>
Please make sure you not running bootstrap as root.
2 Likes
Container that died:
symbolplatform/symbol-server:gcc-1.0.0.0
Log have this string
2021-04-09 17:53:07.497411 0x00007fc08c9f8400: <important> (process::ProcessMain.cpp@99) SHUTTING DOWN PROCESS
I successfully did update by this way, everything looks fine and it’s working well (thanks!). My question is - why as Symbol Block Explorer, as symbolnodes.org/nodes/ still showing version 1.0.0.0, when node has actual version 1.0.4 (symbol-bootstrap --help shows this) ?
Are you running symbol-bootstrap as root or using sudo? Try without it.
1.0.4 is bootstrap version, 1.0.0.0 is actual symbol server version
Yeah, thanks spizzerb, meanwhile I understand from listing somewhere, that there is difference between “mainnet version” (which is 1.0.0.0) and bootstrap version (which is currently 1.0.4). I’m curious, why mainnet version has four positions and if we’ll observe minor changes (aka 1.0.0.2 or so), but … this is really not important (there are a lot much more serious issues in whole Symbol project). Just curiosity.
Anyway, maybe you will know the answer to my (and not just mine, other people are observing the same) another question (I asked in another thread ca week ago, no answer till now). If you will, thanks in advance for it 
- I also thank to gevs, this is really good hint. But I have the same issue as latkon – under the CLI (grepping the logs) I see more “successfully harvested” blocks, than I can finally see in my desktop wallet. There is no block reward from some blocks as well. Signer hash/ID in the log is still the same (my node) by all the successfully harvested blocks.
Could be related this issue, that somebody else use my node to the forging a blocks? But - if this is the right reason - I suppose there should be part of reward headed to my node (or my linked account to my node), correct ?
Anyway, can I configure somewhere in the node config, how many people / harvesters (or “who”, with some white/black-listing method) are allowed to harvest on my node ?*