It is possible I was doing something on the computer that bogged down the resources but I fail to see how it would be possible to not generate the log entry. If my understanding is right you would need to have an issue with returning audit data - drop the audit request packets on the network side; or receive and fail to respond, caused by bogged down disk, which would generate a log entry; or the node to crash which would be obvious. Looks like something in-between happened.
I had this happen on 2 separate windows nodes (on different machines) yesterday. Both machines are solely used for storj and when i check the logs there was no errors at all. Checked nodes this morning both nodes recovered from around 54% back to 100%.
Yeah, looks like a peak yesterday, though I was shuffling some data around in the background as well. But there should be a log entry, I’m curious to know what went wrong, unless satellite got overwhelmed or something.
So the GET_REPAIR failures are dropping the suspension score?
I don’t seem to have any though. I tried looking for entries with ERROR && GET_REPAIR, excluding (“use of closed” && “broken pipe”) and didn’t get any such GET_REPAIR errors in the last 4 weeks. Didn’t get any GET_AUDIT errors altogether so I don’t know what should be wrong.
Unlikely. But there is can be a bug somewhere.
Please, try to search for ERROR event. If you use a docker version and if you did not redirect logs, then likely your logs are gone after re-creation of the container and there is no traces anymore.
No i checked even previous logs and as i said there are not any more logs with errors than those i said above. I run the command in all logs that were used while i was offline and i know that because the logs before don’t have any errors.
From a statistical point of view though, watching all those guys getting suspended lately yeah its pretty obvious that there are some bugs going on