Powering multiple Pi boards and controlled shutdown/restart on power failure

[JimS]

Raspberry Pi boards (and Beagle Bone and many other similar boards) can have SD card corruption if power is cut off without proper shut down. (it has happened to me a couple times).   There are various battery backup solutions but there is still a need to tell the board to shut down before the battery runs out and somehow to restart the units.  There are solutions that have all that but the backup ends up being more expensive than the Pi boards. 
 
So I am going another direction.  For the ones that have wired ethernet (which is all of mine so far) I am running power from my wiring closet through the unused ethernet wires.  I have a UPS in the wiring closet.  I just need a 12V power supply at the UPS and a 12V to 5V buck converter at each Pi.  Then run the program nut to supervise the UPS and tell the boards to shut down (via the network) before the UPS runs out of battery.  All the parts are readily available for low cost except the UPS which I already have.
 
NUT makes sure the UPS shuts down the output power at least momentarily even if the power comes back on before the UPS finishes shutdown.  That is necessary to restart the Pi.
 
I can also send myself a notification or do other things.
 
Just thought I would post this as it might give others some ideas.  Wondering if anyone else is doing something similar.
 
 
 
 

 

[linuxha]

You might find this interesting:
 
https://tech.scargill.net/more-uninterruptable-thoughts/
 
It's Pete Scargill's blog, on his take for a proper UPS for things like the Pi.

 

[JimS]

Interesting, yes.  But the "dog's breakfast" is part of what I was trying to avoid (Not familiar with that expression but think this is similar to "rats nest").  And the batteries at each location charged by cheap electronics gives me some worries.  He has a point that for wireless nodes POE isn't a valid solution (in the comments) but I think my plan works well for my situation.

 

[pete_c]

Currently assisting a Homeseer user that is utilizing an RPi at his vacation home. 
 
It appears that he is unplugging and plugging in his RPi in a cold reboot sequence (or having someone do this at his vacation home) Windows hardware PC wise.
 
None the less he has lost access to his automation and it is not working.
 
I suggested keeping the RPi and router on with a UPS.
 
Here I do not pay much attention.  I am switching over to using eMMC but not sure anyhow if that would fix anything like unplugging the RPi.

 

[linuxha]

Interesting, yes.  But the "dog's breakfast" is part of what I was trying to avoid (Not familiar with that expression but think this is similar to "rats nest").  And the batteries at each location charged by cheap electronics gives me some worries.  He has a point that for wireless nodes POE isn't a valid solution (in the comments) but I think my plan works well for my situation.

 
Pete's total story may have been spread out over several blog entries. Pete's board was built in one evening (but not the design). Yes a dogs breakfast (rats nest) was new to me also though I do understand as I've had dogs most of my life. I think Pete's going to actually build a board and blank may be available in the future. But that might not be a solution for you.

 

[LarrylLix]

Think "Dog's breakfast" after it comes up.
 
I think I just had this happen to me yesterday. I rebooted my RPi 3  and it hung at the same spot each time complaining about some non-existent sector.
 
The RPi3 was new about 3-4 months ago and has worked well until a few months ago with one of the later upgrades. Pixel seems to be the main problem with hanging on some webpages and showing blanks (no files) when opening folders.. Now this.
 
Luckily I had backed up my latest project each night using Filezilla over to a Win 7 laptop and now have installed a new 32 GB SD card, starting from scratch, rebuilding the system from scratch. What a PITA as no browser bookmark files could be located and the SD "secret" sectors could not be found or read.. No usable files could be recovered in a Win 7 system as the Raspbian system makes a partitioned mess of the SD card. I am back using it here again.
 
Why does every system have to create their own sector allocation system and not just stick to one like Fat32, exFat or something readable in other systems?
 
Sector scans can find no bad sectors or any problems with the failed SD card.

 

[JimS]

Yes, the dogs breakfast thing was obvious to me but just hadn't heard it before.
 
I have taken to making an image of the SD card at each major change - configuration change, program install, etc.  That way I can easily get back to very close to where I was without setting up everything again.
 
But that also has some pitfalls to watch out for.  If you copy the whole card then it may not fit on another card of the same basic size because of minor variations between individual cards.  The solution is to not expand the partitions to fill the whole card - it looks like the latest raspbian automatically expands but leaves a bit of room.  Or you can use gparted to resize the partitions.  The latest Win32 disk imager has an option to only read used partitions.
 
If you need to mess with the SD card at a low level you need to do it on a Linux system.  There is a FAT partition and an ext4 one. 

 

[pete_c]

Today's SD cards are built better but none the less they are still SD cards.
 
Very first Homeseer Zee on the RPi-1 used a standard sized 4 Gb SD card.  Software ran fine.  Lifespan was 6 months to trashing of the SD card properly shutting it down when necessary.   I did originally copy the SD card to a "better" SD card. 
 
I also wanted a real RTC in my RPi's and used a PiFace RTC shim. 
 
I had a similar issue here using the Seagate Dockstar Debian running from two USB sticks which did an OS backup every night many years ago.
 
I switched over to a true USB-SSD stick (much more expensive) and it never became a problem.
 
The issues relating to the use of SD media for an OS came up with the introduction of the first RPi and later for the use of the RPi in commercial or DIY software.
 
I tinker here with micro routers using the OpenWRT firmware and have never had any corruption on the firmware RW media.   Much smaller measured in Mb versus Gb.
 
Been in to automobile computers for a while and earlier endeavors used a tank battery and circuit for the Windows car pc software.
 
There are solutions like using a small boot (with fat partition) SD card to a SSD USB drive for the RPi and the new arm based Rock 64 uses a modular eMMC card.  My Joggler tabletops use 1Gb and 2Gb eMMC drives.  Over the years I have seen them get corrupted but typically here didn't use them that much replacing the main OS drive to an SSD card.
 
Most recently here have had two Samsung microSD cards fail. The microsd cards have a hidden lock now and on the Samsung this failed.
 
Typically you cannot see the hidden sectors or even format them. 
 
These days I do a preboot fsck check on the media but really do not know how well this works on an SD card.
 
Going back to the OP really best to just keep them running 24/7.

 

[JimS]

Going back to the OP really best to just keep them running 24/7.

That's what I do and not really a solution.  The utility power fails occasionally, sometimes for longer than the UPS can last - it has happened to me and my power reliability is at or above average (IMHO).  Thus, a solution that includes shutdown is still needed.  (or some different memory scheme, etc)

 

[pete_c]

Yes it is not a solution to keep them on 24/7.
 
Goofy thing here is that the mono processes I use do not get shut down with a reboot even using systemd.
 
I have to manually either kill the PID or use the GUI.  Killing the PID is not really a good way to shut it down.
 
The mono processes are each writing log entries here which doesn't help anything.
 
Relating to the use of Linux Nut see much more information about older linux versus newer linux.
 
The media replacement could work maybe writing the boot on the fat sd partition and booting to a USB SSD drive.
 
 
I used Kingspec SSD USB sticks here but they are large; well same size as a regular SSD drive with a USB on them.
 
It is a true SSD drive.  I see many USB 2.0 / 3.0 sticks advertised as SSD where as they are not.
 
These SSD USB drives though are power suckers and typically you have to put a delay in the fat boot partition to boot from them.
 
Another solution is to do most of the RW's in RAM. 
 
I see a PiDrive SSD which would work but sort of an expensive alternative.
 

 

[linuxha]

Currently assisting a Homeseer user that is utilizing an RPi at his vacation home. 
 
...
Here I do not pay much attention.  I am switching over to using eMMC but not sure anyhow if that would fix anything like unplugging the RPi.

eMMC on the Pi? Which Pi are you working with? Please let us know what you think of the eMMC. Thanks

 

[linuxha]

Yes it is not a solution to keep them on 24/7.
 
Goofy thing here is that the mono processes I use do not get shut down with a reboot even using systemd.

Just a guess but I'm betting that the mono code is written from a Microsoft style of thinking.

I have to manually either kill the PID or use the GUI.  Killing the PID is not really a good way to shut it down.
 
The mono processes are each writing log entries here which doesn't help anything.

I wouldn't be surprise if many of the shutdown script in syslogd simply kill the process.
 
Good Unix coding practices are to catch certain signals so you can clean up politely. That doesn't happen so much anymore.

hese SSD USB drives though are power suckers and typically you have to put a delay in the fat boot partition to boot from them.
 
Another solution is to do most of the RW's in RAM. 
 
I see a PiDrive SSD which would work but sort of an expensive alternative.

I've played with an SSD (USB 2.0) on the Pi 2 & 3. Seems to be faster than the SD cards I've used. I have extrenal power for the expernal SSD. I played with a lot of experimental features and shutting down some services and redirecting other (rsyslog) to send to a network server and using NFS and CIFS for some directories. It mostly works but it crashes from time to time. I might reduce some of features I'm running all at once so I can figure out what breaks. I think it's the experimental SSD feature I'm using. I can't recall what it is right now.

 

[pete_c]

For a bit too here wrote logs to RAM. Only thing is the you only have a total of 1Gb of RAM to play with.
 
The original Kingspec SSD drives I used 8-16Gb were large.  To fit them inside of my experiment removed the plastic outer shells.  For use with the Seagate Dockstart I just left the two SSD drives sticking out of the side of the device.  It still worked better than the use of the PogoPlug which got way too hot.
 
The drive itself was the standard SSD size drive.  I have now been using the .m2 sized SSD drives for other computers.
 
The Pine64 2Gb ARM computer here has a built in RTC with battery.  This device was less than $35.
 
The new Rock 64 2-4Gb machine has similar plus a modular eMMC drive.  This devices starts around $35 and goes to over $50.
 
All in all when you start to add regular PC stuff to an RPi or ARM based CPU computer then the costs go up, power use goes up, footprint goes up....
 
Testing a micro router inside of my Leviton can.  This device is powered by the battery inside of the can.  The OS is very tight - Openwrt and modular.  Play space though is in Mb ....like 128/256 Mb.