Three days ago, I notified my docker container to keep restarting. I’ve run this node for 11 months, and have had no issues with it until now. Is there any way I could bring this node back again? 2024-09-24 09:30:10,561 INFO Set uid to user 0 succeeded 2024-09-24 09:30:10,564 INFO RPC interface 's…

[image] Mowd: command at '/app/config/bin/storagenode-updater' is not executable Hi @Mowd , it looks like this is related to the recent docker changes, see: [image] Storagenode Docker Update: Changes To Binaries Location For Persistence Between Restarts Node Operators …

There is a message “INFO spawnerr: command at ‘/app/config/bin/storagenode-updater’ is not executable” in the log. So I checked the files and the permission, storagenode is 100, and storagenode-updater is 000, which is incorrect. After chmod to 755, everything is back to normal, thanks! For such …

[image] Mowd: For such a breaking change, without any precaution before the auto-update, is a little bit unacceptable; it almost makes my suspension score drop below 70%. It’s a bug. Bugs happen. I recommend not automatically updating to any new software, and specifically, container image, un…

[image] arrogantrabbit: And there is no point in updating docker image in the first place. Why would you do it? Node works, right? Why did you feed the need to update, let alone auto-update? Well it still seems recommended according to official Storj documentation : We recommend that you ins…

Oops. That shall be fixed! Because of all the reasons above. Bad container update can nuke the whole network. @Alexey ?

I follow the storj official doc to install watchdog because very long ago there is a connecting issue of my container, then I realize I left my container way behind of the latest version. Return to previous version of docker image is simple, but the problem is storj didn’t keep the images on the do…

Honestly, there are plenty of disadvantages of this “containerize everything” approaches. There are some good uses, but I’m yet to see benefits in the context of running nodes. It adds overhead, it add points of failure, it adds this “update this entity through the process storj can’t control that…

This is weird, because the entrypoint has an explicit chmod u+x command: storj/storagenode-docker/blob/2159415f2e1848666c2f853e6f440bf4dc879295/docker/entrypoint#L19 wget -O- "${VERSION_SERVER_URL}/processes/${process}/${version}/url?os=linux&arch=${GOARCH}" …

It’s ranged by random interval between 12 and 72 hours, so we should collect enough information if we would see a big amount of offline nodes. And most of SNO have a monitoring about online and uptime. So far only a small amount of nodes are affected. Some QNAP, some Synology and some custom setups…

I run my node on Synology DSM 7.2.1, the base path is /volume2/storj the permission are: d---------+ 1 root root 186 Jun 14 13:56 storj d---------+ 1 root root 186 Jun 14 13:56 . drwxr-xr-x 1 root root 108 Aug 23 09:32 .. d---------+ 1 root root 126 Sep 25 13:58 config drwxrwxrwx+ 1 root…

[image] Mowd: d---------+ 1 root root 126 Sep 25 13:58 config bingo. It has no permissions by default. How is this happened? I would suggest to change them to at least chmod u+rw or chmod +rw to do not have issues in the future.

Sotragenode continuously restart after auto update

Node Operators troubleshooting

edo September 24, 2024, 1:11pm 2

Hi @Mowd , it looks like this is related to the recent docker changes, see: