Keeping your node up to date, changes to storage node software! PLEASE READ this thread!

I was hoping for some evidence of failure where :arrow_down: was evident.

The length of 98% of your posts give a visual belief that you do know a lot about a lot of things but as previously mentioned you can refer the blog or whitepaper.

How is that even remotely connected to storagenode dependencies !

Storj takes pride in providing nine 9s durability so I am 100% sure they would like to get to the bottom of this claim. I have purposefully made the text bold in above quote to point out the base of this claim.

Again how’s that related to storagenode dependencies.

Could you please elaborate that point in short ?

Yes that’s summarizing first post. Thank you.

I understand where this originates from but whenever it’s possible devs do respond to genuine queries and bugs. You have to also understand nobody runs a business just to run it to the ground for no reason. So your point is absolutely correct there needs to be verification of stable and working releases. I have witnessed when a bug was affecting a lot of SNOs and devs worked over time to release a patch in matter of hours which fixed it (during alpha days).

Every staff that has ever interacted with SNOs have asked again and again to point out any bugs/issues that you encounter. Hence I would like to ask you to point out any chaotic experience you have encountered.

I remember Stefan mentioning about getting satellites on track with proper decentralization so that is on the roadmap too but other priorities take precedence.

After reading 8 points I think you have a beautiful mind. You do indeed have wealth of knowledge but sometimes you club valid points with theories that don’t necessarily relate to point/topic under discussion.


DQ for tool old version seems a bit too fast though. Probably would be better if the satellite just did not accept connections from a node that’s too old, so the node would eventually be suspended/DQ for downtime, but, assuming the node did not have downtime before getting too old, it would take some time and would still allow the operator to update.


You REALLY should send out an email to all storage node operators about this. Not everyone reads these forums.


Would there be any issues with just using a script that checks on a weekly basis if docker pull gets a newer version and then just relaunches each container?

How is it different from the watchtower?


I think instead of disqualifying nodes, the network should simply stop nodes with older versions from connecting with the network completely. IIRC node does check for valid version every 5 mins.

A log message should reflect the same as to help SNO understand the issue.

Error: Outdated version, node’s version is older than minimum allowed version

Except older SNOs (older in terms of node’s age) most SNOs are in the mindset of setup and forget. We have to understand they come from “mining” background. There will be SNOs that have faulty watchtower setup or use older watchtower command. A bug in storagenode-updater that won’t automatically update the node so to be fair to them, denying connectivity to the network would be appropriate action than DQ.


Mostly that I am currently unfamiliar with watchtower at this time. What sort of a delay does watchtower operate with?

The Storj Labs’ version checking for updates every 12-72 hours (random number from that interval)

1 Like

I think you think to far into something, storj needs a control and a way to control a bunch of people not maintaining there nodes. This is why Auto updates is prudent for keeping the service strong not because storj hates everyone. Your node is the only thing that can get you DQed not your docker version or your updates for your OS.


I believe the exact quote was 3 minor versions behind.
Version numbers have the format v[major].[minor].[patch]
So v1.14.1, v1.14.4 and v1.14.7 are all the same minor version v1.14.x.


There is a problem - not all SNOs uses their real email addresses in the storagenodes.
You are allowed to do not specify it at all or use a fake one.


It’s in post 1

curl -s | jq .processes.storagenode.minimum.version

That’s not a reason for not sending emails. You could say the same about the forum and the GUI dashboard, not everyone looks at them regularly. So why not using all available channels of communication? Send an email, display it in the dashboard AND have a sticky topic here.

1 Like

I think that it would still reach more people than a post on the forum even if some people didn’t put their real email.
Also it’s kind of a sensitive subject since it involves a possible disqualification and from my point of view it doesn’t hurt to send an email to all SNOs.

1 Like

and because some emails could be fake, you don’t send out emails to ANY SNOs? I don’t understand that reasoning.


Ok, let’s wait for @brandon

The email was sent to the SNOs with outdated software.
However, if their email addresses are fake - then they should monitor the forum.
I do not see any other option to reach them out…


Sure, that’s all I can ask for. If someone prevents you from contacting him, that’s his problem.

Actually I wouldn’t mind receiving such an email as well, even if my node is up to date, just so I am informed about that important change too.


Hey @Pentium100 this is actually on purpose! We do NOT want the entire network to update all at the same time which is why we have the random interval delay between 12 and 72 hours. If all nodes updated as soon as we published a new release we would see adverse side effects across all of the parts of the network.


You should send an email to SNO’s every time you have an important announcement in the future as well.

This already done as far as I remember.
We even have the information in each such email:

We’re contacting you to let you know you need to update your Storage Node’s software. It’s currently out of date, and we don’t want your reputation impacted if you were unaware of the situation.