What's new

Are unmount, services-stop run at reboot?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

So using @Fitz Mutch bind mount script I modify it a little to this:
Code:
#!/bin/sh
CMD=$(basename $0)
SELF="/jffs/scripts/rc"

run_unmount () {
  for DIR in /tmp/mnt/sd*; do
  /jffs/scripts/unmount $DIR
  umount $DIR && logger "unmount $DIR" || logger "unable to unmount $DIR"
  done
}

case $CMD in
  rc)
    ATTACHED=0
    mount | grep -q /sbin/rc && ATTACHED=1
    case $1 in
      attach)
      if [ $ATTACHED -eq 0 ]; then
        mount -o bind $SELF /sbin/rc && logger "rc attached"
      else
        logger "rc already attached"
      fi
      ;;
      detach)
      if [ $ATTACHED -eq 1 ]; then
        umount /sbin/rc && logger "rc detached"
      else
        logger "rc already not attached"
      fi
      ;;
      *)
      logger "rc bad option"
      ;;
    esac
    CMDLEVEL=0
    ;;
    reboot|halt)
    run_unmount
    CMDLEVEL=1
    ;;
  service)
    if [ "$1" == "reboot" ]; then
      run_unmount
      CMDLEVEL=1
    else
      CMDLEVEL=2
    fi
    ;;
  *)
    CMDLEVEL=2
    ;;
esac

if [ $CMDLEVEL -gt 0 ]; then
  (
  sleep 1
  /bin/umount /sbin/rc
  "/sbin/$CMD" "$@"
  [ $CMDLEVEL -eq 2 ] && mount -o bind $SELF /sbin/rc
  )&
fi

with my unmount script being:
Code:
#!/bin/sh

[ -f /opt/etc/init.d/rc.unslung ] && /opt/etc/init.d/rc.unslung stop
fuser -csk $1
rm -f /mnt/usb
sleep 1

I then attach rc in init-start by async polling for ntp updated event.

It works fine from commandline by either calling "reboot" or "service reboot" but does not work correctly from the webui reboot button. Looking at the log I see a difference with how notify_rc reboot is called:
- Calling "service reboot" has it print: rc_service: service 1140:notify_rc reboot
- Using reboot button in webui has it print: rc_service: httpds 1137:notify_rc reboot
IOW webui running inside httpds is actually calling rc directly somehow. I guess this would need firmware modification after all. From the evidences I gathered I believe Fitz Mutch's method to replace reboot/halt binary with script won't work either.
 
... Mutch's method to replace reboot/halt binary with script won't work either.
Consider that we might need a system-shutdown user script in Asuswrt-Merlin, that runs before the router attempts shutdown or reboot. I tried hooking into the "nvram set rc_service=reboot", but that's internal too (search "notify_rc_internal"). So, in the spirit of posting scripts that don't work, here's another one:

/jffs/scripts/nvram
Code:
#!/bin/sh
CMD=$(/usr/bin/basename $0)
PROGRAM=nvram
SELF="/jffs/scripts/${PROGRAM}"
TARGET="/usr/sbin/${PROGRAM}"
CMDLEVEL=0

case $CMD in
  "${PROGRAM}" )
    ATTACHED=0
    /bin/mount | /bin/grep -q $TARGET && ATTACHED=1
    case $1 in
      "attach" )
        if [ $ATTACHED -eq 0 ]; then
          /bin/mount -o bind $SELF $TARGET
        else
          /bin/echo "Already attached."
          exit 1
        fi
        ;;
      "detach" )
        if [ $ATTACHED -eq 1 ]; then
          /bin/umount $TARGET
        else
          /bin/echo "Not attached."
          exit 1
        fi
        ;;
      "set" )
        NAME="${2%=*}"
        VALUE="${2#*=}"
        if [ "$NAME" == "rc_servicezzzzz" ] && [ "$VALUE" == "rebootzzzz" ]; then
          /bin/echo "TODO: script your system-shutdown here"
          CMDLEVEL=1
        else
          # all other set variables
          /bin/echo "$(/bin/date "+%Y-%m-%d %H:%M:%S")  NVRAM  SET  $NAME = $VALUE" >> /opt/tmp/intercepts.txt
          CMDLEVEL=2
        fi
        ;;
      * )
        # all other nvram commands
        /bin/echo "$(/bin/date "+%Y-%m-%d %H:%M:%S")  NVRAM  $1  $2" >> /opt/tmp/intercepts.txt
        CMDLEVEL=2
        ;;
    esac
    ;;
  * )
    # all other aliases
    /bin/echo "$(/bin/date "+%Y-%m-%d %H:%M:%S")  NVRAM  $CMD" >> /opt/tmp/intercepts.txt
    CMDLEVEL=2
    ;;
esac

if [ $CMDLEVEL -gt 0 ]; then
  # now delegate to the base implementation
  (
    #/bin/sleep 1
    /bin/umount $TARGET
    $0 $@
    [ $CMDLEVEL -eq 2 ] && /bin/mount -o bind $SELF $TARGET
  )&
fi
 
Last edited:
I don't think you are going to be able to work around this without a code change. I think it may be relatively simple.....the services-stop script execution is losing the race with the mainline code which unmounts the usb before the script is actually run.

I did a quick change to add a return code to run_custom_script, and if services-stop is found and started, adds a 10 sec delay in mainline (gives the usb drive time to spin up if it has spun down, then to finish running the script). If anyone wants to try it, let me know what router and I'll generate a test build.
 
After my last post I don't think simply scripting and hooking are gonna cut it, either. Still I don't think your solution will fix it, @john9527.

The problem is as I said in one of my previous posts where I said that the usb kernel subsystem for the xhci controller is brought down even before unmount custom script is called. This is further confirmed in my previous post as if I remove the umount command in my run_unmount function, the partition is still dirtied after reboot. I have stopped using services-stop after @RMerlin posted about the shutdown/reboot sequence.

In any case, practical test is still important. I'm on RT-AC56U with 380.62_1, so if you can generate a test build for this router. I will gladly test it.
 
FWIW, @john9527 manages to fix the root cause with the xhci controller handling during reboot through our PMs so we don't need to fiddle with services-stop or weird bind mount scripts that don't work anymore. I am just wondering now that is this fix ready with 380.63 @john9527 and @RMerlin? I really hope that it does, dirty COW and all :D.
 
FWIW, @john9527 manages to fix the root cause with the xhci controller handling during reboot through our PMs so we don't need to fiddle with services-stop or weird bind mount scripts that don't work anymore. I am just wondering now that is this fix ready with 380.63 @john9527 and @RMerlin? I really hope that it does, dirty COW and all :D.

It won't be in 380.63 because development is too far advanced for adding that kind of change at this time, which would require another round of beta test.
 
I'm curious, was this fixed in an official build? I'm on 380.64_1 and no longer see USB storage errors on shutdown, and drives are no longer marked dirty coming back on boot. But I'm also never explicitly seeing services-stop run in the log. I would expect to see the base firmware reporting something like "custom script: Running /jffs/scripts/services-stop", plus I have an explicit logger call in my services-stop file that never shows up. I only have the standard entware 'rc.unslung stop' and 'swapoff /opt/swap' in that file.
 
I'm pretty sure the reason you don't see the tracks of services-stop is that by the time it's run syslogd is already shutdown.
 
Thanks, John. I suspected that to be the case, similar to I don't see tracks of init-start script either, as it's apparently too early in the boot process. Perhaps that should be included in the Wiki describing those particular custom scripts? I don't mind doing that, just don't want to step on toes being a noob here.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top