I have a RS3D in the field with internet connection. I can connect remotely to it using ssh, but no web and no acquisition data.
I reboot the RS3D but nothing changed (sudo reboot). I downloaded the log files.
Maybe the problems are due to the fact that during the end of December and beginning of January, this station suffered several reboots without control due to lack of power due to foggy days (it has solar panels).
What do you suggest I can do or check?
yes, those continuous reboots could have caused the issue you are experiencing, especially with low to no power available due to the weather conditions you described.
However, before launching other hypotheses, could you please shut down the Shake. Wait for around 10 minutes, turn it on, wait once again for around 10 minutes, download the new logs and send them to me zipped (in a .zip or .rar file) together?
I would like to see what they say (and if there are any differences) from a fresh start.
The problem is that I have only remote access for the moment and I can’t do this fresh start that you ask for. I will try “shutdown -r 10” and give you the logs again…
This raspberryshake is not deployed in a easy place to visit…
Ouch! I think this “shutdown -r 10” the only thing that will do is to wait to reboot after 10 minuts…no shutdown and after that wait for 10 minuts to restart…
Here, I attach a normal reboot that I just did…log.zip (388.5 KB)
Thank you for the new logs Mtapia.
Unfortunately, they confirmed what I was suspecting. All those reboots and low power events have corrupted some (or most of the) files in the microSD card, thus making the system unstable.
This line that appears in both logs confirms this fact:
Cannot connect to the Docker daemon. Is the docker daemon running on this host?
The only solutions I can advise you to do are the following:
- re-burn the ShakeOS on your current microSD card
- or get a new microSD (to erase the chance that this one got ruined) and burn the Shake OS there.
I know that this means to retrieve the Shake from its remote location, or going there personally, but there is no other way of correcting this via remote actions.
In both mentioned cases, these are the instructions to prepare the new OS image:
I followed the numbered list points to burn the files on my SD cards, and I have not used Etcher or similar software.
Thanks, I suspected this. I saw this messages about docker and I tried to check or re-run the docker without lucky…I hoped that I will learn some way to “reboot” daemons inside de RS3D to force the acquisition.
But, I’m pretty lucky because, I have another new 3D rasperryshake that goes to another location and I am preparing it. I will try to prepare new microSD using this new RS3D, configure equal to my RS3D at field and then go to the field, replace it and check if all it’s ok. I think is the easiest way I have.
Any more suggestion are welcomed! Thanks a lot for the answers.
No problem at all Mar, you’re welcome.
Yes, what you propose seems the best way for you, since you are preparing another one, adding this secondary task will not be that taxing.
The only suggestion that I may have is to try and add a larger battery storage together with the solar panels, or increase the size of the solar panels themselves. But I understand that these solutions can be expensive, and difficult to implement.