anyone knows what that is? seen it as well in a log recently
also seeing
Scheduling next refresh
and
bandwidth Performing bandwidth usage rollups
I tried google on these but it seems that Storj log messages is intentionally vague and not described anywhere.
Obviously no one knows. or this has been marked hidden
You had requested some logs so that’s what Storj provided 
You didn’t give a lot of context here… it would be helpful if you actually posted some examples of the entire log lines. Without that I only know one for sure.
This is a task that aggregates bandwidth usage into hourly summaries to prevent the bandwidth.db from becoming super huge by having to keep all individual transfers.
If you want more answers, provide more info.
I’m glad that the community is trying so solve question the company should be answering obviously that’s not going to happen- I’ve worked in it for several decades and when log messages are unknown to the developers it’s time to jump ship
Ok dude, then you’re on your own.
I’ve worked with a lot of people in support, as well as developers. And I can tell you no one is looking to go on a scavenger hunt based on incomplete information. You were looking right at those log messages. If you want answers, then post the entire thing. There is absolutely no need to make any ones job any harder than it has to be.
As you well know with your wealth of experience in the field. It’s highly unlikely that any single developer would know all the log messages. Work is done in larger teams, and responsibilities are spread among many people.
But you’re not here to get help or information, are you?
Regardless, I hope you’re having a good day and wish you and your loved ones well during this weird time we live in. 
My log file is 4 gigabytes so yea I’m not trying to post that.
No I’m no trying to make every developer remember what 0xff001 meant, my error messages are quite standard, it’s obviously you don’t know, I’m just puzzled why all the void fuzz about it. I’m very safe, my Storj business is done so enjoy 6TB of repair traffic whoever gets it
Came across this one by coincidence. I think the context explains everything.
2020-05-26T13:10:06.345Z DEBUG trust Fetched URLs from source; updating cache {"source": "https://tardigrade.io/trusted-satellites", "count": 6}
2020-05-26T13:10:06.352Z INFO trust Scheduling next refresh {"after": "8h26m30.831651562s"}
That said, these should either both be DEBUG lines or both be INFO lines. Unless you have log level set to DEBUG, that INFO line without context is meaningless.
No log lines in the Storj code are intentionally vague. They are written with an assumption that the reader is familiar with the context. Obviously not all readers will be familiar with all context, so some log lines will not make sense to those readers. But (a) if you don’t know what a log line means, and it’s at INFO level, you may ignore it; and (b) the code is easily greppable if you really want to know what’s happening.
“Interrogate request received” is logged when a Windows service Interrogate request is received. See https://docs.microsoft.com/en-us/windows/win32/services/service-control-requests .
I have not changed log level and the storj log, that, as you say should be unimportant to me has grown to over 3GB just of a few months. Thats just insane, especially on windows systems not using the event logs to log important messages is really different.
I have not seen any windows service logging this, and I have run windows enterprise servers for 20 years. But thanks for the explanation
The storagenode log is too big. The satellite logs are too big as well. I think everyone at Storj agrees with that. Once we have improved performance in other important areas to reach our targets, I expect that fixing log sizes will be a major focus.