Changelog v1.18.1

If the folder is not empty it will not create databases
But I think the problem in the not full command

&"C:\Program Files\Storj\Storage Node\storagenode.exe" setup --config-dir e:\storagenode6 --storage.path e:\storagenode6 --storage2.database-dir e:\storagenode6

ls E:\storagenode6\


    Directory: E:\storagenode6


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----         12/5/2020   8:53 PM                blobs
d-----         12/5/2020   8:53 PM                garbage
d-----         12/5/2020   8:53 PM                temp
d-----         12/5/2020   8:53 PM                trash
-a----         12/5/2020   8:53 PM           4096 bandwidth.db
-a----         12/5/2020   8:53 PM           8590 config.yaml
-a----         12/5/2020   8:53 PM           4096 heldamount.db
-a----         12/5/2020   8:53 PM           4096 info.db
-a----         12/5/2020   8:53 PM           4096 notifications.db
-a----         12/5/2020   8:53 PM           4096 orders.db
-a----         12/5/2020   8:53 PM           4096 pieceinfo.db
-a----         12/5/2020   8:53 PM           4096 piece_expiration.db
-a----         12/5/2020   8:53 PM           4096 piece_spaced_used.db
-a----         12/5/2020   8:53 PM           4096 pricing.db
-a----         12/5/2020   8:53 PM           4096 reputation.db
-a----         12/5/2020   8:53 PM           4096 satellites.db
-a----         12/5/2020   8:53 PM           4096 storage_usage.db
-a----         12/5/2020   8:53 PM           4096 used_serial.db

Interesting - I got the notification that docker image was updated, ran my update script, it pulled the new image, but version stayed at 1.17.4.

1 Like

Wait, I reread the OP and if I understand this correctly they continue to use the old solution, they just changed the algorithm to not write the file if it cannot be opened in the first place and/or not write to it at all?
And this update is only for Docker version?

my watchtower did not auto update my Storj node. It is still on v1.17.4. Nothing in the logs. any ideas?

docker is a week behind… so 3rd dec for this thread, so around the 10th dec

Keep Calm
And
Keep Storjing

The change is not only for docker. Now the node will not create databases and folders tree in runtime. You need to call setup first. It should be done once.
In case of docker it’s implemented via passing a variable to the docker run command to call the storagenode setup under the hood.

As result, if you pass an empty data folder during the normal run it will fail, because there is no databases and needed folders tree.

What that means? If your drive is not mounted for any reason the node will not start.

4 Likes

and like one guy did the other day… if you launch a run command in the wrong storagedata location, then it won’t just create a new blobs folder and databases…

1 Like

@SGC @Pac
I agree with @Alexey. In the documentation, the suggested command for setup does not include the -d flag, in which case any error encountered should be printed to the terminal. I figured skipping the container removal step would help streamline the setup process for new users. What do you think? Perhaps it would be helpful to indicate that you can check that the setup was successful by verifying that the <storage-dir> was populated with the appropriate files/folders/etc?

@mike the check is the same on everyone’s node. Before the update, all nodes already had the directory verification file, as it would be created on startup even if it already existed. The update moved the creation of the file into the setup step. This was to avoid breaking nodes due to auto updates

1 Like

A post was split to a new topic: What is the traffic less than a gig of traffic a day what gives

Since my Update to the latest Version I do get this error: Error: rpccompat: dial tcp 127.0.0.1:7778: connect: connection refused - see latest posts.

The node is starting but not online. From time to time it is online and then the other way around.

That sounds like your external address is wrong.

the install can be rather cumbersome, but it’s not really one command, but the whole flurry of extensive codes, i know it’s not always relevant and usually people can copy paste it directly off the website…
but i was working through proxmox using webvnc and it didn’t want to copy paste it, so i ended up just writing them out directly…

sure that’s the docker install so strictly not Storj Labs issue, but it might be nice with some kind of curl web script thing… kinda like what netdata uses…

the netdata one works brilliantly, might be a security risk tho… but i duno… and then the run command…
i know you guys try to make it simple… but maybe there should just be a default simple installer that asks about the stuff… most people don’t really need to use the advanced run command parameters at first…
but it’s not an easy problem to solve… lots of things to take into account and ways it can go wrong or not work…

maybe i should try and make a easy install script, been using windows for many years and just recently really started using linux, so it can get very confusing and difficult to do some very simple things, i think many linux users takes for granted… and i’m sure i would do that same eventually…

i can see my storagenode is using the -d parameter on the docker run command.
maybe i should remove that… would be kinda nice with the errors on console

was just “moving” my storagenode into a container and forgot that i had the storagenode docker image still running on baremetal, after i had changed the permissions so the container could correctly access the files… the blobs are still on baremetal…

so the permissions wasn’t all changed and maybe some of the files where locked because the other storagenode was using it… anyhow…

the node perfectly tried to start recognized there was a problem and shutdown again… that was a very nice change from what i’ve seen thus far
but been a few months since i been dealing with stuff like this, so it may have been that way for a long time,

was a very nice surprise, tho looking at the logs… its so difficult to understand what it’s saying, i’m not totally lost… but still i didn’t feel helped by the error message the storagenode gave…

it being two attempts of getting access to the file, being a total of maybe 1 A5 sheet of paper worth of information, that is mostly just nonsense, atleast to me… :smiley:

but yeah props for my storagenode not starting to self destruct.

Wondering if anyone else saw an issue when their node upgraded to this latest version?

I have 3 nodes running here at the house, and two of them updated (docker via watchtower) without an issue. But one of them updated in the middle of the night, and when I woke up all I saw in the logs was the “upload/download started” lines, no completed lines, and my raspberry pi CPU was flooded. I tried stopping the container, then tried killing the container, neither of which would register since the CPU was overloaded. Ultimately, tried to shut down the machine via the shutdown button on the desktop, and the machine even hung up on that…could still see the HDD activity light flickering away.

Having no other option that I could think of, I ended up just killing the power to the raspberry pi all together…praying that I didn’t severely screw things up. In the end the machine rebooted just fine, I ran update and upgrade, saw there was an updated to docker packages, and then I restarted Storj container and everything’s been working fine.

Looking at my web dashboard, looks like that period of time between update and when I noticed the issue, at least 6 hours, the node was not fully communicating with the network since my audit scores all dropped below their normal 100%.

I don’t have logs to share as I don’t have them directed to a file, but thought I’d post the experience just in case this is a wider spread issue. if not then no biggie, although if I had not been home to discover the problem…like in a few weeks for the holiday, this node with 4-5TB of data very well could have been DQ’ed.

May look to disable watchtower over the holidays just to avoid a situation like this again.

2 Likes

I would like to recommend:

  • check your SD card for errors. Maybe just flash a latest OS image (do not forget to copy your identity to the disk with data).
  • buy a smart plug to be able to reset the power of your raspi remotely.
1 Like

Did not face similar issue on my end.

You know what? That’s a great idea! never thought of that :slight_smile:

Actually, each of my Rpi 4’s are running off of usb-connected SDDs, better speed and performance with boot/load, and thought it might be a more robust solution than using the microSD cards.

It’s a good suggestion, which I have utilized for other applications such as my Helium hotspot and XYO bridge (which is actually just a Rpi 3B+), but both of those applications boot right up upon power on. Whereas the Storj node requires some manual commands to start…

Although, for my Storj nodes I do run all of my nodes on GUI Raspberry pi OS and I connect to them via VNC from my main PC. So the reboot process is a little more nuanced in the sense that when I reboot the Rpi’s I have to plug in the HDMI so that the desktop loads correctly for viewing via VNC… which is the part that I can’t do if I’m not here.

Either way, appreciate the responses, and again I was merely just sharing my experience just in case it was not a one off experience.

you can get an adapter/box for the hdmi issue i think or install a driver that does it virtual i also think i’ve heard mentioned… it’s a common issue with hdmi
doesn’t it have a display port or something other output… hdmi isn’t always great because of the inherent boot issue…

L1tech sells a box or adapter in their store which should fix it, think it was one of those boxes where you hook up multiple systems and switch them between 1 keyboard, mouse, audio and monitor or whatever…

was just checking the prices…just no…lol
or KVM switchs sure aren’t cheap…

It should not require that, if you used an option --restart unless-stopped and static mounting of your disk via /etc/fstab, see How do I setup static mount via /etc/fstab for Linux? - Storj Docs

For remote access you need only ssh server running, the CLI is only what you actually need.
See How to remote access the web dashboard - Storj Docs and What if I'm using a remote connection? - Storj Docs

By the way, I’m not surprised to have hangs of Raspi4 if you use a GUI on it. The GUI usually requires a lot more RAM than a headless (i.e. no GUI)

yep, I totally understand that this is the case. I’m just a lot more comfortable with GUI, of the 3 nodes I have running on Rpi’s, all are running on separate Rpi 4’s, each with at least 4GB of RAM. My newest node is currently running on an 8GB model with a USB powered 1TB portable HDD, but planning on migrating that to another 4GB model here soon that I have recently set up with the Geekworm X832 and X735 modules, with an old NAS 4TB HDD.

My main rationale for using the GUI though is it’s nice to be able to view multiple windows, sometimes overlaid on each pi, plus I like to save my “reference” text files right on the desktop that contain my frequently used commands, like my docker container start, so I can quickly copy and paste. Again, I know it’s not the ideal set up, but it has never really been a problem for me. I also like the ability to take one node down at a time without having to touch the other machines.

Although, I have never seen that issue where the node hangs up before this instance that I originally posted about. I have done a bit more research and found what I need to do to get the pi’s to boot without the HDMI connected. The downside simply just appears to be that on my main PC, I have two 27" monitors, which I have HDMI switches connected to, so I can easily switch between inputs, and when I boot the raspberry pi without HDMI connected and then connect via VNC, the desktop size doesn’t fill my whole screen…an annoyance, but a solid trade off from having to whip out the HDMI/microHDMI cable every time I need to reboot a machine.

Thanks to all for the various replies and good discussion.

1 Like