Reboot ending up in standby

Something must not be running properly in the reboot script then.

When your box is in a position where the output is '01 00 00 00 00', could you please run the 'sbreboot' diagnostic and post the output?
 
Code: 
Humax /mnt/hd2/mod # hwctl d
01 00 00 00 00
Humax /mnt/hd2/mod # diag sbreboot
Running: sbreboot
LBR: 3
Wakeup: 01 00 00 00 00
Setting wakeup timer...
Success
Wakeup: 01 57 48 2d 0b
01 57 48 2d 0b
Humax /mnt/hd2/mod #
 
There is a bug in the reboot script. I suggest something similar to the followiing:
Code: 
--- /mod/webif/lib/bin/reboot.old
+++ /mod/webif/lib/bin/reboot
@@ -79,7 +79,7 @@

 # Stop mod services
 for f in /mod/etc/init.d/S??*; do
-       [ -f "$f" ] || continue
+       [ -x "$f" ] || continue
        $f stop
 done
 
Ecpanding on the above, I seem to have the following script left around which does not have execute permission.
Code: 
# ls -l /mod/etc/init.d/S00env.sh
-rw-rw-rw- 1 root root 101 Jul  5  2011 /mod/etc/init.d/S00env.sh
It doesn't seem to be owned by any package but does cause the reboot script to fail with permission denied if the above patch has not been applied.

Perhaps this may be the reason for some of the unexplained recording failures reported here over the weekend.
 
I've only just got round to looking at this.
It's interesting to see how things get modified by others and then you wonder why.
For example, here's what I wrote:
Code: 
dir=/mod/etc/init.d
for f in `ls -r1 $dir/S*` ; do
  echo "  $f stop"
  $f stop
done
and here's how it ended up:
Code: 
for f in /mod/etc/init.d/S??*; do
  [ -f "$f" ] || continue
  $f stop
done
I accept there should have been a -x test in there.
I went to the trouble of making sure things were stopped in the reverse order to which they were started, which can be important, but that seems to have been 'simplified' out, wrongly IMHO.

The code to delete the EPG cached data didn't make it either. I can't really see why not as the epg.dat (or epgsavedata) file serves no real purpose, being recreated almost immediately after restart, and leaving it there just accumulates a few stagnant entries which the Humax software seemingly 'forgets' to delete, causing other problems downstream.
 
I don't have any non executable files in /mod/etc/init.d/ so wouldn't be suffering from the -f / -x bug but I am still seeing the reboot following scheduled event wakeup ending up in standby.

I did try prpr's original faster reboot script when it was first published and it worked for me but didn't solve the reboot into standby problem (nor was it designed to) so what is the extra magic that is supposed to fix the standby part of the problem and why isn't it working for me? :(
 
Not working for me either. I fact, I don't recall anyone reporting that it actually does work. I guess it is still a 'work in progress'.
 
MymsMan said:
I don't have any non executable files in /mod/etc/init.d/ so wouldn't be suffering from the -f / -x bug but I am still seeing the reboot following scheduled event wakeup ending up in standby.
Click to expand...

It is working for me on three different boxes, I've been a bit busy so haven't had time to look at it again yet. I'm surprised it's failing for everyone else though, could be tricky to diagnose!

The -f / -x thing wouldn't stop the script from running properly, it would just print an error if there were any non-executable files. It's only for the fast reboot case anyway which is not yet finished nor linked in anywhere.
 
prpr said:
I went to the trouble of making sure things were stopped in the reverse order to which they were started, which can be important, but that seems to have been 'simplified' out, wrongly IMHO.
Click to expand...
I missed the -r in your version. I will update mine, thanks.

The code to delete the EPG cached data didn't make it either. I can't really see why not as the epg.dat (or epgsavedata) file serves no real purpose, being recreated almost immediately after restart, and leaving it there just accumulates a few stagnant entries which the Humax software seemingly 'forgets' to delete, causing other problems downstream.
Click to expand...
I think that the fast reboot should as far as possible do the same as a normal reboot, only faster, and the EPG data aren't removed during a standard boot.

xyz321 said:
Ecpanding on the above, I seem to have the following script left around which does not have execute permission.
It doesn't seem to be owned by any package but does cause the reboot script to fail with permission denied if the above patch has not been applied.
Click to expand...
The script doesn't fail, it just outputs an error, doesn't it? (and then, just on a fast reboot)
 
How can we tell if the box is fast booting or not please? Mine seems to go through the 'normal' boot procedure, and without getting a stopwatch out to time it, it takes about the same length of time.
 
Trev said:
How can we tell if the box is fast booting or not please? Mine seems to go through the 'normal' boot procedure, and without getting a stopwatch out to time it, it takes about the same length of time.
Click to expand...
Unless you're doing something from the command line, it isn't fast rebooting.
It will eventually be an option in the web interface settings.
 
af123 said:
I think that the fast reboot should as far as possible do the same as a normal reboot, only faster, and the EPG data aren't removed during a standard boot.
Click to expand...
I think the EPG cache should be removed during a standard (WebIf induced) reboot as well. It's the only opportunity to do so in an automated manner and I don't see any downsides to it.
 
Last edited:
af123 said:
The script that does the reboot is at /mod/webif/lib/bin/reboot and this is also what is run from the Jim {system reboot} command which things like rs use.
Click to expand...
I see you've special-cased dropbear not to be killed. This is necessary if you're accessing the prompt through SSH, as killing the daemon stops the script half-way though if you don't. However, you do need to restart the daemon somehow, otherwise it is left non-operational afterwards as its filesystem access to the disk is yanked away beneath it.
A similar situation ought to exist with the webshell daemon, but that hasn't been special-cased.

I guess the script really needs to run asynchronously to the terminal session you're invoking it from so that killing these daemons doesn't stop the script.
 
And also:
xyz321 said:
Ecpanding on the above, I seem to have the following script left around which does not have execute permission.
Code: 
# ls -l /mod/etc/init.d/S00env.sh
-rw-rw-rw- 1 root root 101 Jul  5  2011 /mod/etc/init.d/S00env.sh
...
Click to expand...
The above problem occurred because the code did not accurately unwind /etc/init.d/rcS.mod, which allows for both sourced and executed scripts. Instead of checking for execute permission, it would be more correct to do s/t like this, which executes any script that is meant to be executable and wouldn't need to be stopped if wasn't (since it wouldn't have been started):
Code: 
...
# Stop mod services
# shellcheck.net prefers this ...
for f in $(set -- /mod/etc/init.d/S??*; for f; do echo "$f"; done | sort -r); do
# ... to the current
# for f in `ls -1r /mod/etc/init.d/S??*`; do
      [ -f "$f" ] || continue
      # Don't stop the SSH server
      echo $f | grep -q dropbear && continue
      case "$f" in
          *.sh)
              (
                      trap - INT QUIT TSTP
                      set -- stop
                      . "$f"
              ) ;;
          *) # 
              "$f" stop
              ;;
done
...
 
You must log in or register to reply here.
Back
Top