Hello, the node worked stably for more than 22 months, and 1 satellite was disqualified, the screenshot shows that only he, the rest are working properly, perhaps you had problems with the server, my node worked stably.
node ID:12aTHGbgHd69BeonBQKe27biLUKYAZP1YhsJcHr11GervDPDq8A
Audit below 96% is the reason for DQ
1 Like
But on the rest the audit is 100%
You are DQ only on 1 settelite, rest of them not.
3 Likes
Hello @Mishanstvo- we’ve been noticing something wrong with that node on our side as well. It seems that it suddenly sent a whole lot of pieces into the trash that weren’t supposed to be in the trash. When the pieces were requested later, and your node couldn’t find them in main storage, it checked the trash and found them there. We get an alert if a node reports that this has happened, and this node is the only one that has been reporting it. So that is definitely the reason for the audit failures and the disqualification.
We’d be really interested to know if there was anything out of the ordinary that happened on that system that you noticed, and would you mind sharing your logs going back to the beginning of May?
6 Likes
@thepaul Sorry, but the logs from the docker container are not saved, there are only system logs, tell me which ones you need to send to you.
Ok. Unfortunate. I don’t think any system logs will help to diagnose this.
Thank you for this. Clearly something was going on. This might not be enough to track down exactly what, but it could give some clues.
I would be in favor of it. I think a community lead like @Alexey knows who would have to make the final decision.
I was unbanned but then they banned me again(((
Which means your node is losing data if the audits keep failing.
1 Like
But did You keep logs this time? So it is possible to troubleshoot the reason?
2 Likes
The logs are cleaned every day (I didn’t think it would break again.
I can turn off log cleaning.
It’s better to keep logs, so you can debug problems at any time.
Log rotate is a good way to clean old logs but keep a set amount of days as a backup.
Also for the next time, if you know your node has a problem, look in the logs for errors at regular intervals. So you can act fast if you detect a problem
2 Likes
I believe it’s too late, unfortunately. We hoped to get your logs to understand why only your node tried to delete more than it should.
Without logs we cannot solve this mystery.
The second DQ is an expected result unfortunately, because your node deleted a legit data for some (now completely unknown) reason, and the only positive thing here, that auditors works perfectly…
1 Like
But maybe you should have given him the chance to change his log setup before you undisqualified him without notice ?
Then he would be able to halt the automatic log deletion and provide those logs to you.
This is doesn’t matter, their node deleted all pieces, otherwise they wouldn’t be failed audits in a second time…
We implemented a feature, that the node checks also a trash for audit or retrieval requests and sends an alert to us. Since their node was unable to pass an audit even from the trash, well, that’s mean that piece(s) is(are) gone…
And we wanted to know, why their node is decided to move these pieces to the trash in a first place. It can be a bug or some not standard config, we do not know now.