What is the latest Storj version? I see somebody has 1.72. I have 1.71.2 and 1.71.2 is the latest one on Github but I am not getting any uploads now. version.storj.io also shows a newer one, so what is the deal here?
As https://version.storj.io/ says, the actual version is 1.73.4 and the minimum version is 1.72.5.
You can use the Storagenode-Watchtower to update the node automatically for the future.
On version.storj.io also is a link to GitHub for 1.73.4: Release v1.73.4 · storj/storj · GitHub
On Github, nothing above 1.71.2 was ever released, only pre-releases which I never use.
I’m not using the Docker.
1 Like
How do you update? Could you not use the updater?
I simply swap the executable.
There were no official instructions on how to actually use the developed updater and unofficial instructions that one of the members helpfully posted were too laborious for me to examine, understand and implement, so I simply continued using this as it was simple and effective. Didn’t have a lot of time to fiddle with stuff lately and learn how the operating system works. Problem is that there is no installer…
If your checking github you can clearly see theres new versions out though. Been seeing this more and more the latest version isnt updated as fast as updates are coming out. Probably the fault of storj not updating releases to latest versions…
Yeah I’ve said something about this in another thread as I’ve run into this as well. I update manually and always waited for “release” versions. Well… now I update to pre-releases.
1 Like
On Linux I’m using this to update, it is running via Cron once a week, simply comparing suggested version with the running one, then downloading the binary and replacing it.
You will probably need to install jq, curl, wget (you can probably rework this to use only one) and unzip if you don’t have it.
Cron job is running as user storj which is the reason I need to use sudo to stop and start it.
Had pretty much no issues with it.
#!/usr/bin/env bash
# get suggested version
current=$(curl -s 'https://version.storj.io/' | jq -r '.processes.storagenode.suggested.version')
# if empty
if [ -z "$current" ]; then
exit 1
fi
# get running version
running=$(/opt/storj/storagenode version | sed -n 2p | sed 's/[^0-9].[^0-9].[^0-9]//g')
# if empty
if [ -z "$running" ]; then
exit 1
fi
# if update is needed
if [[ "$current" != "$running" ]]; then
echo "Update needed, current ${current}, running ${running}"
# get current version
wget -q "https://github.com/storj/storj/releases/download/v${current}/storagenode_linux_amd64.zip" -O /opt/storj/storagenode.zip
# if download failed
if [ $? -ne 0 ]; then
exit 1
fi
# stop node
sudo /etc/init.d/storj stop
# replace binary
unzip -o /opt/storj/storagenode.zip -d /opt/storj
# chown (needed if running this manually)
chown storj:storj /opt/storj/storagenode
# cleanup
rm /opt/storj/storagenode.zip
# start service
sudo /etc/init.d/storj start
fi
@Storgeez @zip
Why do not just run an storagenode-updater designed exactly for this?
It’s used to rolling updates by waves to do not shutdown the whole network.
If more operators would start to use DIY bicycles with square wheels it could become a problem for the network.
1 Like
You are right. I was in the impression that is some sort of a Dockery thing. But I see the binary is available as well, so will have to take a look on how that is used and will start using it.
@Alexey I gave that a try. The system I’m using is not running systemd but open-rc and it looks like the updater is not able to restart the service as it is using systemctl to find the pid of the process. Is there some workaround for this problem?
2023-03-11T16:28:15.195Z INFO Anonymized tracing enabled {"Process": "storagenode-updater"}
2023-03-11T16:28:15.196Z INFO Running on version {"Process": "storagenode-updater", "Service": "storagenode-updater", "Version": "v1.73.4"}
2023-03-11T16:28:15.197Z INFO Downloading versions. {"Process": "storagenode-updater", "Server Address": "https://version.storj.io"}
2023-03-11T16:28:15.890Z INFO Current binary version {"Process": "storagenode-updater", "Service": "storagenode", "Version": "v1.72.5"}
2023-03-11T16:28:15.890Z INFO Download started. {"Process": "storagenode-updater", "From": "https://github.com/storj/storj/releases/download/v1.73.4/storagenode_linux_amd64.zip", "To": "/tmp/storagenode_linux_amd64.3267739515.zip"}
2023-03-11T16:28:29.404Z INFO Download finished. {"Process": "storagenode-updater", "From": "https://github.com/storj/storj/releases/download/v1.73.4/storagenode_linux_amd64.zip", "To": "/tmp/storagenode_linux_amd64.3267739515.zip"}
2023-03-11T16:28:29.433Z INFO Restarting service. {"Process": "storagenode-updater", "Service": "storagenode"}
2023-03-11T16:28:29.442Z ERROR Error updating service. {"Process": "storagenode-updater", "Service": "storagenode", "error": "error stopping storagenode service: Error retrieving service pid: systemctl: exec: \"systemctl\": executable file not found in $PATH", "errorVerbose": "error stopping storagenode service: Error retrieving service pid: systemctl: exec: \"systemctl\": executable file not found in $PATH\n\tmain.restartService:38\n\tmain.update:68\n\tmain.loopFunc:27\n\tstorj.io/common/sync2.(*Cycle).Run:99\n\tmain.cmdRun:136\n\tstorj.io/private/process.cleanup.func1.4:377\n\tstorj.io/private/process.cleanup.func1:395\n\tgithub.com/spf13/cobra.(*Command).execute:852\n\tgithub.com/spf13/cobra.(*Command).ExecuteC:960\n\tgithub.com/spf13/cobra.(*Command).Execute:897\n\tstorj.io/private/process.ExecWithCustomConfigAndLogger:92\n\tmain.main:20\n\truntime.main:250"}
2023-03-11T16:28:29.456Z INFO Current binary version {"Process": "storagenode-updater", "Service": "storagenode-updater", "Version": "v1.73.4"}
2023-03-11T16:28:29.456Z INFO New version is being rolled out but hasn't made it to this node yet {"Process": "storagenode-updater", "Service": "storagenode-updater"}
I can suggest to try to use a storagenode-updater for BSD, or build it locally.
That does not work either. The updaters try to find the process by the service name and kill it, instead of using service manager to restart the service by the name that is provided to the updater. .
This is fundamentally broken approach. There can be more than one executable, the updater kills the first one. Furthermore, because storagenode does not handle SIGHUP properly we have to run it under daemon, and therefore it’s the daemon that needs to be found and restarted, if they go that wrong route. Correct solution is to restart the service by name. It’s not only correct but also removes 90% of that broken code. Less code → less bugs.
I filed a bug, it was “fixed” and closed, and my objections were ignored.
I gave up — I think I’ve done enough to move this issue forward — and continue using similar “dumb” script myself
1 Like
I see. I thought it’s fixed. But seems only for the single node setup.
In Linux you would setup several services with storagenode-updater, each for own node (since a binary name or path will be different).
But since there is no usage of system tools related to services in BSD, it wouldn’t work.
Maybe only using a different name for the binary?
Could you please reopen an issue?
For me the FreeBSD version gives a segfault.
Tried using GDB, but it is complaining about missing FreeBSD ABI and is returning useless information in backtrace.
Not sure how to build from GO source, never done that, but the other question then would be how the updater itself is being updated and if it would rewrite the locally built version with a binary again.
Just FYI, I’m using Gentoo, amd64 in case someone would be willing to experiment and fix the updater for this specific distribution.
But maybe a better approach would be to include the updater part into the storagenode software itself.
Yea, I guessed because:
I think it should be implemented in the code, but due to percentage of Gentoo usage, it become very unlikely, unfortunatelly…
I don’t think so. But the distribution-specific - may be. At least we have a different implementation of storagenode-updater for Linux, Windows, macOS and FreeBSD (I believe thankfully to TrueNAS usage mostly).
I wanted to use it, but it had no installer and there were no official instructions for using it so I was unable to. I gave up on it a long time ago.
Lmao!
Will then start updating to beta versions. Hopefully it doesn’t corrupt any data.
fair enough, but you may use this instruction:
I am on FreeBSD though…