Creating a Windows Autorun Program(After the network turns itself off)

This is a method to reconnect when the network is disconnected due to network problems or power saving.

We are using ‘UptimeRobot’ to cope, but sometimes it is difficult to connect from outside.
Just in case, let’s deal with a light shutdown.

First of all, we will use ‘Task Scheduler’, a basic Windows program.

First, before running the program, you must create an executable file with Powershell.

  1. Windows menu > Windows Powershell > Run as administrator
    Set-ExecutionPolicy Unrestricted

  2. To create an exe file, create a ps1 file in Powershell. (The name can be anything.)
    notepad storj.ps1

  3. Enter the ps1 file you created to create an executable file and enter the contents.
    powershell -Command "Start-Service storagenode"

  4. In the created notepad, go to properties and change the connection program to Powershell.


Now you are ready.


  1. Search for Event Viewer in the search bar at the bottom left and run it.

  2. Tap System Logs to see what’s wrong

  3. Right-click on the error (Service Control Manager) and click Attach task to this event. Proceed as per the screenshot.

Screenshot_4

Screenshot_5

Screenshot_6

Screenshot_7

Screenshot_9

Once the settings are complete, check whether the settings are correct in ‘Windows Task scheduler’.


You can now respond quickly even when your network turns off briefly and then comes back on.

There are many reasons why the Windows network connection is lost, and this is only one solution, so it would be good to find several ways. (I used this method because even with the power saving settings(disabled),the device disconnects once a week.)

The contents are explained for beginners. Experts may have a better way.
Even beginners like me can make it easily, so if you want, follow along.
If there is a better way, please let me know. Thank you.

(I apologize in advance for the fact that the language is not English, so the icon descriptions are in a different language and that I am not good at English.)

2 Likes

This happened to me, but it was the network/mainboard drivers fault wich was not updated automaticaly.(while windows did updates and became incompatible to the old driver once a month)
but why does node service not start itself after a reboot? normaly its on autorun anyway.
and it can be set in the services tab to start again after a failure.
Maybe there are 1min timeout errors in the storagenode.log?

2 Likes

must be disabled.

sometimes the network is not ready after reboot immediately, so you need to make some changes, if this is the case for your system:

I would suggest to check the storagenode’s logs for FATAL errors, they could be a reason for the stopped service but not the network.
You may also configure restart of the service in its settings in the Services applet (or with sc.exe program), but fixing the FATAL errors would be better.

1 Like

Its possible in the GUI also.

1 Like

I modified the meaning that I disabled it. And it’s easy to restart with the method you told me. Thank you :slight_smile: It’s a great help for beginners.

I don’t know much about computers, so I often feel barriers to entry, but it’s a great comfort for me because there are a lot of people who kindly teach me on forums, Thank you always.

You are welcome!
But your method could be useful to restart on exact issues, i.e. hardware ones, but I likely would configure to stop the service in this case: being offline is better than disqualified.

1 Like
2024-01-03T01:34:20+09:00	ERROR	services	unexpected shutdown of a runner	{"name": "piecestore:monitor", "error": "piecestore monitor: timed out after 1m0s while verifying writability of storage directory", "errorVerbose": "piecestore monitor: timed out after 1m0s while verifying writability of storage directory\n\tstorj.io/storj/storagenode/monitor.(*Service).Run.func2.1:176\n\tstorj.io/common/sync2.(*Cycle).Run:160\n\tstorj.io/storj/storagenode/monitor.(*Service).Run.func2:165\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:75"}
2024-01-03T01:34:23+09:00	ERROR	orders	cleaning DB archive	{"error": "ordersdb: database is locked", "errorVerbose": "ordersdb: database is locked\n\tstorj.io/storj/storagenode/storagenodedb.(*ordersDB).CleanArchive:325\n\tstorj.io/storj/storagenode/orders.(*Service).CleanArchive:157\n\tstorj.io/storj/storagenode/orders.(*Service).Run.func2:141\n\tstorj.io/common/sync2.(*Cycle).Run:160\n\tstorj.io/common/sync2.(*Cycle).Start.func1:77\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:75"}
2024-01-03T01:34:24+09:00	ERROR	piecestore	upload failed	{"Piece ID": "V7ZWE4RWNXU3TZGHURZ7K7DNMY2SB4HY57A6ANQ", "Satellite ID": "12L9ZFwhzVpuEKMUNtbiigLiXpmZWKwmcNDDs", "Action": "PUT", "error": "manager closed: unexpected EOF", "errorVerbose": "manager closed: unexpected EOF\n\tstorj.io/drpc/drpcmanager.(*Manager).manageReader:231", "Size": 1843200, "Remote Address": "90.201.7.4:59446"}
2024-01-03T01:34:24+09:00	ERROR	gracefulexit:chore	error retrieving satellites.	{"error": "satellitesdb: context canceled", "errorVerbose": "satellitesdb: context canceled\n\tstorj.io/storj/storagenode/storagenodedb.(*satellitesDB).ListGracefulExits.func1:195\n\tstorj.io/storj/storagenode/storagenodedb.(*satellitesDB).ListGracefulExits:207\n\tstorj.io/storj/storagenode/gracefulexit.(*Service).ListPendingExits:59\n\tstorj.io/storj/storagenode/gracefulexit.(*Chore).AddMissing:58\n\tstorj.io/common/sync2.(*Cycle).Run:160\n\tstorj.io/storj/storagenode/gracefulexit.(*Chore).Run:51\n\tstorj.io/storj/private/lifecycle.(*Group).Run.func2.1:87\n\truntime/pprof.Do:51\n\tstorj.io/storj/private/lifecycle.(*Group).Run.func2:86\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:75"}
2024-01-03T01:34:25+09:00	FATAL	Unrecoverable error	{"error": "piecestore monitor: timed out after 1m0s while verifying writability of storage directory", "errorVerbose": "piecestore monitor: timed out after 1m0s while verifying writability of storage directory\n\tstorj.io/storj/storagenode/monitor.(*Service).Run.func2.1:176\n\tstorj.io/common/sync2.(*Cycle).Run:160\n\tstorj.io/storj/storagenode/monitor.(*Service).Run.func2:165\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:75"}
2024-01-03T01:53:07+09:00	INFO	Configuration loaded	{"Location": "C:\\Program Files\\Storj\\Storage Node\\config.yaml"}
2024-01-03T01:53:07+09:00	INFO	Anonymized tracing enabled

I also checked the log for fundamental confirmation, but I’m not sure what it means…:frowning:
I hope there are no more problems…

this is a usual problem for Windows and disks without a defragmentation.
You need to:

  1. Stop the storagenode service
  2. Defragment the drive
  3. Do not disable (or enable, if you disabled it) the automatic defragmentation for this drive

If that wouldn’t help - you need to increase a writeability timeout on 30s (by default it’s 1m0s), save the config and restart the node - either from the Services applet or from the elevated PowerShell:

Restart-Service storagenode

See

2 Likes

For good defrag use ultradefrag for free, will run in the background for days. maybe weeks.

2 Likes

I increased it by 30 seconds as you wrote, and I went in and saw the article you linked to.
Now I know that deactivation of sculpture collection can also cause problems…!
I feel like I’m getting more and more knowledge…

Thank you!

I’m using that too! Thank you :slight_smile:

Must be a translation error, please explain sculpture collection

Please remove the # also
otherwise it stays in standard value and the line is ignored by the node.

If you have readable timeout errors, you need to increase both - the readable check interval and readable check timeout. The first one is a frequency, the second one is the timeout itself. Increasing only the interval doesn’t make sense.

However, since the error mention only writeability check,

then you do not need to modify a readability interval and/or readability timeout.
And as @daki82 said, you need to remove a commentary character (# ) with space before the writeability check timeout, i.e.

# how long to wait for a storage directory writability verification to complete
storage2.monitor.verify-dir-writable-timeout: 1m30s

save the config and restart the node.

Complete!:slight_smile: Thank you!

1 Like

You doesn’t have a readable timeout errors accordingly to this logs excerpt:

you have only writeable check errors so far.
So, modify the config like this:

# how frequently to verify the location and readability of the storage directory
# storage2.monitor.verify-dir-readable-interval: 1m0s

# how long to wait for a storage directory readability verification to complete
# storage2.monitor.verify-dir-readable-timeout: 1m0s

# how frequently to verify writability of storage directory
# storage2.monitor.verify-dir-writable-interval: 5m0s

# how long to wait for a storage directory writability verification to complete
storage2.monitor.verify-dir-writable-timeout: 1m30s

save the config and restart the node

2 Likes