Crashes before login. It happens only in Win 10. Syrius in win 11 is fine…
I did the 2nd one… extracted and ran the .exe file from extracted folder, didn’t move it.
Reinstalled my win10, i have the following issues
- Syrius crashes if znnd is not running in parallel
- Closing znnd after syrius is up disconnected syrius from node
- I can’t connect to any community nodes, says failed to connect
Completely fresh install?
1 Like
Just the c drive. Its formatted and win 10 installed
hey guys, just an update on the crash! I ran znnd v0.0.5 and am now able to run Syrius v0.0.6 without any issues.
I did not redownload Syrius or anything… So I think it’s really a node issue!
3 Likes
I had Syrius crash on one of my Win10 machines, force closed itself after pressing collect on delegation rewards, and ever since can’t re-open it (experiencing the same issue as the others now).
Really odd it would manifest itself randomly, trawling through logs now. Means it’s unlikely to be a dll or missing dependency issue
0.0.5 also crashing before login as well now
both on embedded mode, same affected PC
log file in znn/consensus just shows this over and over again when opening, usually when working it obviously undertakes a lot more. Maybe its indicative to someone who has experience with Syrius @aliencoder @sumamu ?
=============== Apr 23, 2023 (AEST) ===============
08:37:02.570650 log@legend F·NumFile S·FileSize N·Entry C·BadEntry B·BadBlock Ke·KeyError D·DroppedEntry L·Level Q·SeqNum T·TimeElapsed
08:37:02.572655 version@stat F·[1 63 211] S·507MiB[726KiB 99MiB 406MiB] Sc·[0.25 1.00 0.41]
08:37:02.572655 db@open opening
08:37:02.573655 journal@recovery F·1
08:37:02.573655 journal@recovery recovering @29766
08:37:02.574653 version@stat F·[1 63 211] S·507MiB[726KiB 99MiB 406MiB] Sc·[0.25 1.00 0.41]
08:37:02.581653 db@janitor F·277 G·0
08:37:02.582654 db@open done T·9.9993ms
Also the last file that Syrius has any interaction with (a successful ReadFile operation) before crashing is below:
C:\Users\romeo\AppData\Roaming\znn\nom\438508.ldb
getting closer - this is from running Syrius 0.0.6 (not built from source, just extracted with syrius-alphanet-windows-amd64):
t=2023-04-23T12:59:18+1000 lvl=crit msg="can't start node because don't have all sporks implemented" module=chain hash=9e2438a0ac72fcd8afe230323798270ea77b96edf9c76ca7c0e0695c7a15d331 height=4188199 unimplemented=[0xc0008c6e10]
4188199 was the momentum prior to the first spork
Before the issue started, the zenon.log started warning about this:
t=2023-04-23T07:51:13+1000 lvl=warn msg="Find non-empty bucket" module=embedded peers=table entries="[enode://8da3624a825e9cc3536c6065f06f0dd38c4703bf32299f171a1d0e69d249c887220b875e1a82a38f8ecb37971d6c6d7741889abe942a1ddef75ac9dce3aa0575@62.171.148.56:35995 enode://0c5213f89c748aab5c39e63bdc65bd97bf446a5229e640086e2784217d24731d78ab53ee5316619dc4299ab759304c5859272d35cfab74fd9106753e0db3d14e@135.148.32.194:35995 enode://0812b9dc68542286330dc768ff87719d13733400022c556a777152dac42e664f29c23a415125c9645783384fc18de91c6ece82b54338875db66530fc1da6ceeb@158.247.209.220:35995 enode://0220d5ed0e17344023d70f8e72259fe0940e232777d88f828c5be5cf67071eae26501182fdc6a9be2ce14db7a8315456594aad5d6f88609c73ad052b8183dd23@139.99.169.68:35995 enode://4c38beeab6bc5531fbe49ebc8c2297d708631a41431b1fd624ddaecd2adda516b25e6de6483a59dededd92b763ad5afc805dcc9b49d6acfdf58c8d244387ff18@216.128.178.220:35995 enode://2155ec9ee05593174451fa0109224f590b039811748274ea754eff2d541c6831cec4c4ab33184e0482e249c245707f88c2588722ca329556f19bfbaf8560be72@5.9.153.75:35995 enode://00be0ab173fa0c60e4f93a8cac0670f0169ffab7e18e9b502e0d59ed0779f88d1cc8cbdea4f1fe784fae5358ef5ade78206fa3444ba6c215a99d0fd07fe89105@51.79.220.30:35995 enode://c10eb6a097b174041cdf59b200b37a9312593e52807e438faac4cba9e65007dad71d7fa2a979a6e2f5b355b7c12d59cf56a6a3dee2c40c7d8f8c5665387c072d@198.244.149.192:35995 enode://446698548dff0319e363927d4fb566af72f1fdb30094d62d217cb71505949cd1936e4781998e6df32d7859d81ef84745e9f73dee1b4d69a076d34098a7879f3e@51.79.207.58:35995 enode://7a57e3a373f5a85a39ca61df1488c2107c7494ac6f2bb36a1671ecb051bd03f1aace5f5eeddb86d3ae0d5959c617801c4c2740a9938625d39f619a04fabb6b6c@51.195.138.179:35995 enode://45b3da04b79407127c7e172920a6fee7ce46b040a46cb563b447db6f9750460cb71cf3ce4b769057621e1dedd7ec25351d1335c955bba46dd90e3b76a3fccb85@149.56.108.141:35995 enode://0509c14897283f99f6cc36dc1b3de53f7290b51866c4c95469b2f956864ad016c59c243127cec28bf9b92816ddf89310e6d57493403ad8a7ec4f38ec47f4edae@193.149.189.76:35995 enode://e65a83e5c4b3976f80b60ce39cb461fbfffa00b3d7390c654e30816713e6567e907aeb75c59130fb4369879ad6e072ff507cd7fe4a020c8ac6732ed61024915c@178.18.250.182:35995 enode://7227e01a72e223c5f8284a62061a5bb4ab97305605b7f325ba2ff5db56323b4e3a41d871722a44a4e45abe8bbdc4a1bd79497fd108370ff4db0a9473d5522b3c@137.184.138.57:35995 enode://895a7ad858af86a0f85578d549a41b35b8565da2833a3731e6605f2efbc90c08d7a12d44f808729d703ef14f99034e57c7261d1808a021810316ecd5b9153410@135.148.121.53:35995 enode://55786f9013e2399cbd7bd8b1bdf52a42b3f09b9b2f713b9b8996702e870634deae8e673c65d123ceb8aab7c374a94f6b7992ce6982427d78a7eb8c1f25619214@95.216.146.33:35995]"
copying syrius 0.0.6 files and over writing my previous copy of 0.0.6 allowed it to sync past the Spork momentum
1 Like
Ah, I see. Weird that it got in a loop like that, acted like it was using znnd 0.0.4 for some reason
does that mean SYRIUS should load now that the sporks were activated?
If that’s the case then it’s worth still fixing the issue for future periods between sporks activations with new syrius releases.
Another way is to time the release of new SYRIUS versions with the timing of approving sporks.
I don’t think my issue is the same as the others as it only reared its head after the Spork, whereas others had dramas prior
Is this function meant to print something for the user to see? Or just to a log? At the moment I don’t believe it is shown to the user
Is it possible for this to be changed to show the msg to the user and requiring a prompt prior to closing?
fmt.Printf("===== Error =====\n")
fmt.Printf("Can't start node. %v height %v\n", frontier.Hash, frontier.Height)
fmt.Printf("Detected an unimplemented spork.\n")
for _, spork := range unimplemented {
fmt.Printf(" Spork name `%v` id:`%v`\n", spork.Name, spork.Id)
}
fmt.Printf("\n")
fmt.Printf("Please upgrade your znnd binary\n")
fmt.Printf("znnd is terminating\n")
os.Exit(2)
I think it was designed this way. They are already shown to the user in the console and it’s closing the node on purpose.