it will pass round 842217.
In limits.conf, since it will not be validated via PAM, you must manually start up NIS as a prerequisite.
If it is running automatically, you can examine the boot process and release limit at the proper place, but it is not common.
I am using CENT OS 7.4 systemd environment, auto start daemon, only NIS, change the limit.
Because the setting method changes depending on the difference in OS or version, it is very difficult to explain.
Thanks
@BloodyRookie @Quantum_Mechanics
About API of NIS operation
Currently, NIS itself is moving but Night, which is delayed by hight, has increased.
Even with NanoWallet, NG can not be detected for those with a delay in hight, Green circle is displayed on Node display.
In creating Node automatic selection program, you can think of hight of multiple NIS, but it is not a smart way.
If you have an API that lets you know that there are no delays beyond a certain amount on the NIS side, I would like to use it.
Could you please describe the feasibility of this?
Thank you.
1 Like
Hello BR and Minarin-san
I did 3 procedures that told me from Minarin-san , yesterday
But ip adress of my supernode(NoiseR6) don’t change yet.
I will wait more? or I did wrong procedure?
Please tell me what happened.
Thank you
To @chibi
Because the name Norisa 6 already exists, it is considered to do such behavior. In this case, Mr. BR( @BloodyRookie ) needs to do manual work, so please wait for BR’s contact.
Thanks.
I think the client should simply ask 10 NIS for their height and then estimate the real height. Next step would be to select a NIS and check the height of that NIS. If the NIS reports a height which is too far behind, the client should select the next NIS.
I need the data for the node to add a new entry in the db.
Thank you very much.
The verification of the short term hight did not necessarily make a long chain good, and understood that Super Node itself should solve it.
Thanks
Not sure i understood that answer. Are you saying that a supernode should give information if it is fully synced or not?
(by the way, hight => height)
I recognized that interpretation of thinking that the longest one at the root of the block chain is positive is to leave it to the judgment program of node instead of doing it arbitrarily by looking at height.
Since recognition about this is out of the original question, please do the following question again.
Supernode height provided by the official did not satisfy the condition of SN and fail continued to appear in the servant for a long time. More than a week, san.nem.ninja was in a state where the height was not updated. Currently fixed.
If you selected that node with NanoWallet, no error occurred. The node displayed a green circle. Continue to display the old balance, flooded with inquiries.
Nodes whose original height is delayed by one week think that it is a correction point that the green circle is displayed even in NanoWallet.
We are asking the following questions on the premise that such a situation occurs.
I would like to add an implementation that eliminates nodes whose heights have not kept up with automatic node selection program implemented in NEMLibrary. For that, what kind of method / judgment is appropriate?
I was interacting as follows, so I asked you a question.
I have raised a case like san.nem.ninja on a product related to NEMLibrary and raised an issue on automatic node selection.
"Is the node considered very high in the height considered by the program?"
At that time, I was asked a question whether there is an API for making that judgment.
thanks
Well yes, but i think Nano Wallet has to decide that the node is not a good choice. So i think that the question should be raised in the Nano Wallet thread. Nano wallet could for example retrieve the latest test result for a node for the height test. If it failed the test, then it is removed from the list of nodes. Or Nano Wallet retrieves the height for 10 nodes and estimates the current chain height from that and removes nodes that are too far behind. Either way i don’t think the Supernodes program or testing has to be changed. It’s up to the client to decide which nodes are good and which are bad.
1 Like
There was no API etc. to judge, I understood that implementation on the client side is the current answer.
I will also report the solution to the NEMLibrary project.
Thank you very much.
Dear Bloody Rookie
Please help me!
I want to change my supernode’s delegated key and IP adress of NCC to
nanowallet it.
(Alias name:NoiseR6)
I sent message etc. but not change it yet.
Please tell me what is wrong thatI did.
Thank you.
Thank you! Thank you very much, BR!
And happy Halloween!
2 Likes
Dear BloodyRookie
I sent another message(change ip 153.122.85.122 to 153.122.87.2) to forum.
Please respond to that.
Thank you.
Ip was changed.
Thank you very much , BR!
Hi BloodyRookie!
I sent a request to activate the Super Node … IP 89.107.56.153
))) this information for dating
I’m worried about the servant …
It does not change at all. Look at the attached file.
This is normal?
Your enroll message is not correct try
enroll 89.107.56.153 ANECHKA2017 ced6c80a85114724636c47444c92587ce358438f976c36bf2e2e46e29cf72e27