GitHub Build Tags

Node Operators FAQ
,
1

Hey Friends,

I mostly just leave my node to do its thing, but when I checked it today, I saw that I was on v1.77.2, vs v1.79.4 being the latest release in GitHub. After downloading the latest version from the website, I noticed it was giving me 1.76.2. I finally came to the assumption that all builds after 1.76.2 are pre-release or release candidates. Is there a reason all the 1.79.x and 1.78.x releases aren’t tagged in GitHub? Some are (ex. 1.78.1) but others aren’t (ex. 1.79.4). The only way to see what the latest release is, is to scroll to the middle of page 2 on the GitHub releases and see that 1.76.2 has the “Latest” tag.

Thanks!

2

You can also check https://version.storj.io/ where it shows 1.76.2 as the latest/suggested, whilst 1.78.3 is being rolled out.

The history is that interim releases were withdrawn due to various problems.

2 Likes
3

Please do not use manual/custom updaters, use the provided storagenode-updater service instead, it follows rolling cursor on https://version.storj.io/

We do not update all nodes asap to do not shutdown the network after each release, so we updates nodes in waves. This allow us to stop an rollout in case of a bug and release the fix before the problem will affect the whole network.

1 Like
4

Got it, thanks again!

1 Like
5

I’d love to, but on FreeBSD this still does not work, and my reported issue was confirmed but closed with non-working fix.

I’ve commented on why this does not solve the problem here: cmd/storagenode-updater: restart storagenode after update on BSD unix… · storj/storj@b5d0021 · GitHub

I’ll explain here too:

Why the fix does not work?

  1. The code searches for process id based on service name with pgrep. This will fail or provide wrond pid

    root@storagenode:~ # service -e | grep storagenode
/usr/local/etc/rc.d/storagenode-updater
/usr/local/etc/rc.d/storagenode
root@storagenode:~ # pgrep -n -x storagenode
root@storagenode:~ #
root@storagenode:~ # ps aux | grep storagenode | grep -v grep
root   5290  0.0  0.0  13676   2832  -  IJ   19:14    0:00.04 /bin/sh /usr/local/bin/storagenode-updater    run --config-dir /mnt/storagenode/config --identity-dir ...
root   5305  0.0  0.4 906428 146480  -  IJ   19:14   21:57.77 /usr/local/bin/storagenode run --config-dir /mnt/storagenode/config --identity-dir ...

  2. even if the process is found, terminating it with a kill(os.Interrupt) will immediately restart it, after which updater will replace binary, and attempt to start the service, and fail. As a result, storagenode remains unchanged.

The correct fix is to:

  1. download and unpack the new binary
  2. execute service <servicename> restart.

Until then I’m forced to use custom dumb updater script that ignores rolling cursor. (I could not implement rolling cursor support in my script either because that code is not opensource for me to match the implementation)

6

I see. I have reported this issue to the team.

1 Like