Hello again.
I originally posted here. I have since reimaged the SD card and reinstalled Witty Pi etc. The same issue manifests.
It occurred to me that I could probably replicate the behaviour I wanted by getting rid of the WAIT statements, using a very short ON time, and then putting the script which I want to run for an arbitrary time into beforeShutdown.sh. For example, I would have a schedule file which looks like:
ON M5
OFF M55
First the good news: now that I have removed the WAIT and taken the shutdown command out of my kickoff script, the Witty Pi is turning on and off reliably.
The bad news: I assumed I should NOT use a & as I DO want to block the daemon. However, when I put in a line reading:
/usr/bin/sh /home/pizero/code/rpi-timelapse/kickoff2.sh
The script does not run and the log file looks like this:
[xxxx-xx-xx xx:xx:xx] Running on Raspberry Pi Zero W Rev 1.1
[xxxx-xx-xx xx:xx:xx] Seems RTC has good time, write RTC time into system
[xxxx-xx-xx xx:xx:xx] Writing RTC time to system...
[2023-09-01 17:00:53] Done 🙂
[2023-09-01 17:00:53] Firmware ID: 0x26
[2023-09-01 17:00:54] Firmware Revison: 0x03
[2023-09-01 17:00:55] Current Vout=5.34V, Iout=0.1A
[2023-09-01 17:00:57] System starts up because scheduled startup is due.
[2023-09-01 17:01:06] Send out the SYS_UP signal via GPIO-17 pin.
[2023-09-01 17:01:09] Pending for incoming shutdown command...
[2023-09-01 17:01:40] Schedule next shutdown at: 2023-09-01 17:20:00
[2023-09-01 17:01:42] Schedule next startup at: 2023-09-01 18:00:00
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@[xxxx-xx-xx xx:xx:xx] Witty Pi daemon (v4.13) is started.
[xxxx-xx-xx xx:xx:xx] Running on Raspberry Pi Zero W Rev 1.1
[xxxx-xx-xx xx:xx:xx] Seems RTC has good time, write RTC time into system
[xxxx-xx-xx xx:xx:xx] Writing RTC time to system...
[2023-09-01 18:00:53] Done 🙂
[2023-09-01 18:00:53] Firmware ID: 0x26
[2023-09-01 18:00:54] Firmware Revison: 0x03
[2023-09-01 18:00:55] Current Vout=5.34V, Iout=0.08A
[2023-09-01 18:00:56] System starts up because scheduled startup is due.
[2023-09-01 18:01:05] Send out the SYS_UP signal via GPIO-17 pin.
[2023-09-01 18:01:07] Pending for incoming shutdown command...
[2023-09-01 18:01:32] Schedule next shutdown at: 2023-09-01 18:20:00
[2023-09-01 18:01:34] Schedule next startup at: 2023-09-01 19:00:00
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
With the ^@ line appearing where the script should be kicking off. I tried adding the & so that the kickoff line looked like this:
/usr/bin/sh /home/pizero/code/rpi-timelapse/kickoff2.sh &
This resulted in the code being kicked off but with the RPi shutting down immediately (without kickoff2 having completed it's run). The log file then looked like this:
[xxxx-xx-xx xx:xx:xx] Witty Pi daemon (v4.13) is started.
[xxxx-xx-xx xx:xx:xx] Running on Raspberry Pi Zero W Rev 1.1
[xxxx-xx-xx xx:xx:xx] Seems RTC has good time, write RTC time into system
[xxxx-xx-xx xx:xx:xx] Writing RTC time to system...
[2023-09-02 08:00:53] Done 🙂
[2023-09-02 08:00:53] Firmware ID: 0x26
[2023-09-02 08:00:53] Firmware Revison: 0x03
[2023-09-02 08:00:54] Current Vout=5.27V, Iout=0.08A
[2023-09-02 08:00:55] System starts up because scheduled startup is due.
[2023-09-02 08:01:03] Send out the SYS_UP signal via GPIO-17 pin.
[2023-09-02 08:01:05] Pending for incoming shutdown command...
[2023-09-02 08:01:31] Schedule next shutdown at: 2023-09-02 08:20:00
[2023-09-02 08:01:32] Schedule next startup at: 2023-09-02 09:00:00
[2023-09-02 08:19:53] Shutting down system because scheduled shutdown is due.
kicking off python
Sat 2 Sep 08:19:53 EDT 2023
[2023-09-02 08:19:53] Halting all processes and then shutdown Raspberry Pi...
Questions:
1. My understanding of beforeShutdown.sh is that it will wait for the OFF time to come. It will then kickoff whatever code is loaded in the file and wait an until the code finishes running (however long that takes) at which point it will turn off the RPi. Can you confirm my understanding is correct?
2. If yes, any thoughts on what's going wrong above?
Thank you!
If you read the line 189~215 of the daemon.sh file, you will understand how it works:
https://github.com/uugear/Witty-Pi-4/blob/main/Software/wittypi/daemon.sh#L189-L215
The script is blocked until the scheduled shutdown is due, then it runs beforeShutdown.sh before executing the shutdown command. So your understanding is correct.
In your case, you should not add & to kickoff2.sh because you are expecting kickoff2.sh to finish its job before shutting down your Pi.
Those "^@" should be from your kickoff2.sh, most probably the system crashed when running it. You may dig deeper in your kickoff2.sh and see what was going on.
I'm not convinced it is an issue with kickoff2.sh. I'm now running it in both afterStartup.sh:
#!/bin/bash
# file: afterStartup.sh
#
# This script will run after Raspberry Pi boot up and finish running the schedule script.
# If you want to run your commands after boot, you can place them here.
#
# Remarks: please use absolute path of the command, or it can not be found (by root user).
# Remarks: you may append '&' at the end of command to avoid blocking the main daemon.sh.
#
/usr/bin/sh /home/pizero/code/rpi-timelapse/kickoff2.sh &
and beforeShutdown.sh:
#!/bin/bash
# file: beforeShutdown.sh
#
# This script will be executed after Witty Pi receives shutdown command (GPIO-4 gets pulled down).
# If you want to run your commands before turnning of your Raspberry Pi, you can place them here.
# Raspberry Pi will not shutdown until all commands here are executed.
#
# Remarks: please use absolute path of the command, or it can not be found (by root user).
# Remarks: you may append '&' at the end of command to avoid blocking the main daemon.sh.
#
/usr/bin/sh /home/pizero/code/rpi-timelapse/kickoff2.sh
The log looks like this:
[xxxx-xx-xx xx:xx:xx] Witty Pi daemon (v4.13) is started.
[xxxx-xx-xx xx:xx:xx] Running on Raspberry Pi Zero W Rev 1.1
[xxxx-xx-xx xx:xx:xx] Seems RTC has good time, write RTC time into system
[xxxx-xx-xx xx:xx:xx] Writing RTC time to system...
[2023-09-05 17:00:53] Done 🙂
[2023-09-05 17:00:53] Firmware ID: 0x26
[2023-09-05 17:00:53] Firmware Revison: 0x03
[2023-09-05 17:00:54] Current Vout=5.34V, Iout=0.1A
[2023-09-05 17:00:56] System starts up because scheduled startup is due.
kicking off python
[2023-09-05 17:01:04] Send out the SYS_UP signal via GPIO-17 pin.
[2023-09-05 17:01:09] Pending for incoming shutdown command...
[2023-09-05 17:01:45] Schedule next shutdown at: 2023-09-05 17:20:00
[2023-09-05 17:01:48] Schedule next startup at: 2023-09-05 18:00:00
>>>>>>>>>>> Various python outputs
all done
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
This would indicate that kickoff2.sh runs just fine as part of afterStartup.sh but something goes wrong when I add it to beforeShutdown.sh.
hi, did you ever solve your problem? I'm seeing the same on a pi zero / wittypi v4.13 with my custom shutdown script. It gets executed, but wittyPi.log is corrupted with "^@^@^@" pattern and some log lines are missing. Looks like a script crash, but that script runs fine to its end. What I also observe: when logged in remotely via ssh to the pi, that session doesn't get properly terminated when shutting down. looks to me like a power cut before shutdown has completed, or so... can't find any hints in syslog files though.
seems I found the cause:
my custom script called by beforeShutdown.sh contained lazy variable assingments like this:
DATE=`date`
replacing them with
DATE="$(date)"
solved the problem.