Forums » Software Development »
Shutdown misbehaving
Added by Helmut Forren about 11 years ago
Under Angstom linux on a mityomap L138F, I've created /etc/rc0.d/S99poweroffAPP.sh, a symbolic link of /etc/init.d/poweroffAPP.sh, which in turn echos recognizable "KILL POWER SUPPLY" text and then outputs to a GPIO pin and causes my power supply to shut off. Thus, when I hand type the command "poweroff", the OS shuts down, ending with "Unmounting local filesystems...", followed my recognizable "KILL POWER SUPPLY" text echo, and the power led extinguishing. This manual "poweroff" command works.
Meanwhile, I've made a ~/application/poweroff.sh script that echos it's own recognizable "POWERING OFF NOW..." text, sleeps for 3 seconds, and then runs "poweroff". When I execute this script manually, it also works as expected.
So now I've added that capability to my always-running application, using a C-language statement "system()". When I use system("poweroff.sh"), I see my "POWERING OFF NOW..." text followed by the OS shutdown ending with "Unmounting local filesystems...". But I do NOT see the "KILL POWER SUPPLY" or led extinguish. So it seems that the shutdown caused by the "poweroff" command in the ~/application/poweroff.sh script loaded via system("poweroff.sh") is failing to run /etc/rc0.d/S99poweroffAPP.sh. This is my problem. (Regarding possible confusion of names, I know ~/application/poweroff.sh is run by system("poweroff.sh") because I see the "POWERING OFF NOW..." echo it performs. And I know the shutdown and halt occurs because I see the "Unmounting local filesystems...". I just don't see the immediately followup with "KILL POWER SUPPLY".
Why might /etc/rc0.d/S99poweroffAPP.sh not be getting executed in this case? Remember, it does get executed when I manually run ~/application/poweroff.sh as "poweroff.sh" from cwd ~/application/ from the shell prompt. And both shutdown.
Thanks very much,
Helmut
Replies (3)
RE: Shutdown misbehaving - Added by Helmut Forren about 11 years ago
Probably RESOLVED.
There was another bug I thought unrelated, where I was calling system("poweroff.sh") multiple times. When I fixed this bug, the shutdown followed by power supply kill worked once. So it seems that the triple run of "poweroff" within poweroff.sh somehow caused the failure.
In addition, my program often closes with a long hex dump. No, I don't have funding or time to fix whatever memory corruption leads to this. But that's in response to receiving a term signal from shutdown. Well, when that dump occurs, sometimes it runs so long (over 10 minutes) that I get impatient, and that won't work for low battery shutdown either. Other times, the dump is shorter. Anyway, in these cases, the power supply kill doesn't happen either. But I find adding a "killall -9 application" does NOT cause the dump, and the power supply kill seems to happen reliably. I know it's not optimal, but it works reliably so I'm going to stick with it. If I ever get funding to fix the memory corruption implied by the dump, I will.
Thanks nevertheless,
Helmut
RE: Shutdown misbehaving - Added by Michael Williamson about 11 years ago
My guess is that the DSPLINK driver library is catching the signals and shutting itself down (a default behavior to support cleaning up programs terminated by CTRL-C), most likely prior to your app/dsp shutting down nicely, so there is a kernel dump when the DSP tries to send messages to the ARM.
You can tell DSPLINK to ignore signals and then handle them yourself in the application code. Or.... make sure that your application quits / shuts down the DspLink interactions before trying to power off.
-Mike
RE: Shutdown misbehaving - Added by Jonathan Cormier about 11 years ago
Helmut,
As long as your application doesn't need to do any cleanup (saving files), the kill -9 should be ok.
If you want to try to diagnosis it quickly, i've had good luck using valgrind memory analyzer. This was easiest if you can compile your app for x86 and run it on the vm. Not always possible though.
