Change request: tie Power Off/Reboot directly to /sbin/poweroff and /sbin/reboot
Closed this issue · 7 comments
Instead of current implementation which ties these to emhttp API 'shutdown' and 'reboot' calls. I guess this would apply to "System Buttons" plugin too.
You are saying emhttp needs to be updated or the plugin needs to be updated?
In ArrayOperations.page the "Reboot" and "Power down" buttons are tied to emhttp API calls "reboot" and "shutdown". I want to remove the emhttp API calls and instead have those buttons directly invoke /sbin/reboot and /sbin/poweroff. Also get rid of the "yes I want do this" next to those buttons, and instead, upon click, a javascript confirmation box opens with appropriate "are you sure" dialog. [I guess this part can stay the way it is if it's still possible to invoke reboot/poweroff if emhttp is in stop-array polling loop, see next paragraph.]
This way, suppose someone clicks 'Stop' to stop array, but emhttp is stuck in unmounting loop because something is holding open file on a mounted volume, or perhaps loopback file is open on a mounted volume, or some other reason exists for volume to not umount. If user does not want to investigate cause, they can click 'Reboot' and system execute shutdown code (which make take a while but eventually will complete), and then reboot.
Also, even if array is not stopped, and even if parity check is running, user can still initiate a shutdown/reboot. (The shutdown code in 6.2.1/6.3 will invoke emhttp cmdStop API call with timeout.)
Similar treatment should be done by System Buttons plugin I suppose.
Question: both "poweroff" and "reboot" refer to "halt". How to make a differentiation?
(in my tests 'reboot' powers down the system completely)
Another "challenge" is emhttp. When the array is stopped and it get stuck in retries then emhttp is waiting too and does not accept another HTTP request, preventing the 'reboot' or 'shutdown' invocation.
(it comes down to emhttp not being multi-threaded)
/sbin/reboot and /sbin/poweroff are symlinks to /sbin/halt. 'halt' looks at the program name it was called as, like $0 in a bash script, to determine what argument to pass to 'shutdown'. It's a bit tricky but it's designed so that one can use 'poweroff' or 'reboot' or 'shutdown'. The man page of halt and shutdown explains how this works.
If 'reboot' powers off your system that is unusual, I've never seen that happen before. I use 'reboot' all the time on various servers.
re: emhttp: yes if it stuck in cmdStop you can't use 'reboot' or 'shutdown' api calls - that is why those buttons should directly invoke /sbin/reboot or /sbin/poweroff. They could invoke
/usr/local/sbin/powerdown -r
or
/usr/local/sbin/powerdown
but that script is just a wrapper now and I want to avoid using it.
In other words, I want to make the Reboot and Power-off buttons independent of emhttp.
Ok, wait, I understand what you are saying about emhttp now... standby
reboot not working as expected was due to my implementation. After your explanation I understand how it works, and it is okay now.
Leaves open the emhttp question. I'm in standby mode...