Hi, A friend and I have developed a solution for power loss to the
Raspberry Pi 3 and 3B+ using small, cheap supercapacitors
instead of batteries which need periodic replacement.
However, the new Rachel-Pi images take too long to shut down.
They add a shutdown period in some script somewhere. Perhaps in crontab or other place.
This shutdown period exceeds the ability of the supercaps to
provide enough power to the RPi. They have been able to hold
it for the 20 seconds needed for the old images. But this is no
longer the case as the shutdown period now seems to exceed a minute or longer.
Question: can the shutoff script be disabled or modified for us?
The reason there’s a long shutdown time is that Kolibri has a stop job that takes anywhere from 30 seconds to over 1 minute depending on the device until the facility is set up. There’s a note about it in the readme file PDF that says you should set up your facility before doing anything else to avoid this. The shutdown command that the RACHEL-Pi uses (‘shutdown now’) is issued instantly once the shutdown button is clicked. Hope that helps.
My co-conspirator says he tried setting up the “facility” on the device first, but it “didn’t work”. We gotta avoid the delay or we
can’t use Kolibri. What does the “stop job” do, anyway?
I don’t know what the stop job does as Kolibri is maintained by Learning Equality. All I know is that in testing it shows up until you go through the process of setting up your Kolibri facility. Once you’ve completed the setup the next time you boot and shutdown it will not have the stop job. If you want to try it without Kolibri then “sudo systemctl stop kolibri” “sudo systemctl disable kolibri” should disable it and you can see how long the shutdown takes.
Yes, that’s kinda what we have done:
We wait until we get a shutdown on one of the RPi
pins and then…
subprocess.call([“sudo”, “/bin/systemctl”, “stop”, “kolibri.service”])
Perhaps you’ll have a chance to talk to Learning Equality. I would hate to blow up any of their file updates.
Stopping Kolibri through systemctl is always very slow so I wouldn’t do it in your python script. I only suggested it to be done first before disabling Kolibri to test the shutdown time without Kolibri at all.
How long is it taking to shut down for you after fully setting up the facility? I just tested again and the first boot after fully setting it up the shutdown time is normal.
Our RACHEL Pi custom designed servers described by my friend above are used in remote village schools in Uganda which are mostly powered by 12 volt solar panels; power shutdowns and voltage brownouts can occur randomly. The inexpensive supercaps we use in our design are able to hold power for up to 30 seconds until the Pi completes its shutdown sequence.
The 90 second power shutdown delay that has shown up in the latest images of RACHEL with Kolibri now creates a real problem for future deployments. Our Python script uses a “os.system(sudo shutdown -h now)” command line to shut down the Pi after detecting the push button off signal on a GPIO pin. Before installing Kolibri shutdown always occurred immediately. Shutdown also occurs immediately now when we add the “sudo systemctl stop kolibri” and “sudo systemctl disable kolibri” terminal commands you suggested trying.
After we installed Kolibri we set up the facility first and then imported several Gbs of Khan Academy lessons. Everything runs fine and we are assuming that we set up the facility correctly. However, one or both of the following two messages always comes up and persists for 1 min. 30 secs before shutdown: “A stop job is running for session C1 of LSB Kolibri daemon” or a “A stop job is running for session C1 of user pi”. This continues to show up even after many successive boots and shutdowns. Unfortunately this does not seem to match what you are seeing on your end!
The “systemctl stop kolibri” command line that we have added to our Python script before the “sudo shutdown -h now” line adds about 20 seconds to the power down process. It’s a hack, but we don’t seem to have a better alternative yet. Any suggestions will be appreciated!
I am looking into the issue further and have opened a post at the Learning Equality forums about it. You have to understand that Kolibri is only installed on top of RACHEL-Pi and is not maintained by me. The fix has to be either a hack fix here, or a fix in an updated version of Kolibri which is out ot my control. I am looking into what that stop job actually is to see if it can be removed. I’ll let you know when I have an update.
I worked exclusively on this since I last commented, learning some of Kolibri’s internals and debugging to look for the source of the shutdown issue with the awesome Benjamin from Learning Equality. It turns out it’s two issues. One is the 90s delay which was due to how Kolibri was started. The other is a 23s delay due to zero configuration networking in Kolibri. You can follow the latest progress at https://github.com/learningequality/kolibri-installer-debian/issues/90 and the linked posts in that. I found a fix for the 90s delay that Benjamin is implementing with other changes and he did an experimental build that disables zeroconf which I think they’re going to fix. So when they have a new version I’ll make another image. The shutdown time is now about 6 seconds with both fixes.
You’re welcome @Techncat. I think they have a lot of testing to do around changing these settings to make sure everything is working and compatible with all platforms and updating. In the meantime do you want me to make a test RACHEL-Pi image that you can try with your setup or is stopping Kolibri okay for testing?
Hi @chuckroast I am using the RACHEL-Pi in Zambia, Southern Province. I would be very interested in the way you prevent the Pi from shutting down immediately the power stops. Do you have any notes on how to do this that I could look at.
Kind Regards
Howard
You’re welcome @Techncat. I am testing a new version of Kolibri today so once I’m done that I’ll put together an image with that version if it’s working. That would be the latest Kolibri with the changes.
Hi @giakonda, @chuckroast and I jointly developed the 5 x 5 inch RACHEL-Pi server boxes that are currently installed at several Ugandan village schools using roof-mounted 12 Volt solar panels. We found that a pair of 7.5 Farad 5.4V parallel connected supercaps provide sufficient juice to the Pi-3B for about. 20 seconds until its power down sequence completes.
The Pi is mounted on a printed circuit motherboard which contains the 12V to 5V conversion and voltage sensing circuitry. It uses GPIO pins for 5V power in, and 2 pins for the power fail in / shutdown done handshaking…
We will be happy to provide you with the required documentation, let us know the best way…
Thanks @Techncat, I would be very grateful for any docs you can send, I would like to give it a try.
Thanks again
Kind Regards Howard
ps my email is howard@giakonda.org.uk
@Techncat They have put up a version with the 90s fix but not the 23s fix. I have an older package that has both temporary fixes. Do you want me to make an installer for this package for your current image? I think this is the best we’ll get for a while unless they release a patch for the zeroconf issue ( the 23 second delay ).
@jamesk, Yes, If you can make a pre-release installer that includes both your fixes on the current image it would help us to continue debugging.
Many thanks for all your good work!
You’re Welcome @benjaoming and welcome to the RACHEL forums!
Thanks for all the work you’ve been doing on this and for opening that issue. It’s very interesting you saw similar times on an i7 8GB laptop as that’s significantly more powerful than the Pi4 I was testing with. Please let me know if there’s anything I can do to help.