webgui - "Eject USB Disk" fails

[kernol]

Now - if the webgui unmount actually worked for me - I'd be a happy camper ... but as a noob with the add-ons in my signature - it fails to successfully umount despite my best efforts.

I notice that a webgui "Reboot" succeeds in gracefully umouting the USB - because no errors show up for the USB using amtm supplied disk check. Clearly it does more than the webgui "Eject USB disk" to successfully close all "aps" that might be accessing the USB. However, powering off the router after the webgui failed unmount always results in errors on the USB drive.

I am hoping that the experienced folk in the community can give me some pointers? Does the webgui "Eject USB disk" simply invoke the umount script? - and if so what additional lines should be added to that script to achieve a successful unmount give the services I am currently running??

Many thanks

 

[kernol]

The only content in my unmount script is currently ...

#!/bin/sh

awk '/SwapTotal/ {if($2>0) {system("swapoff /opt/swap")} else print "Swap not mounted"}' /proc/meminfo

Thanks

 

[ColinTaylor]

Have a look in services-stop for processes that should probably be in unmount instead. You'd probably need at least this if you're running entware:

/opt/etc/init.d/rc.unslung stop

 

[thelonelycoder]

Have a look in services-stop for processes that should probably be in unmount instead. You'd probably need at least this if you're running entware:

/opt/etc/init.d/rc.unslung stop

The entware-setup.sh and Diversion place that line in services-stop.
Are you suggesting to move it to unmount?

 

[ColinTaylor]

The entware-setup.sh and Diversion place that line in services-stop.
Are you suggesting to move it to unmount?

That would be my personal preference, but it's difficult to generalise because people have their routers setup in different ways. But I would say that ideally any services that are running from a mounted USB partition ought to be shut down cleanly in the unmount script otherwise the "eject USB" function could hang. Bear in mind that people may also have swap files on mounted filesystems so a swapoff also needs to be done.

I can see that actually trying to code for that could be problematic as there might be multiple partitions being used by different processes. So putting the rc.unslung stop in services-stop is a kind of ugly fail-safe. On reboot the router will first try to unmount the USB partitions and probably fail. It will keep trying for a while before eventually giving up. Then the router will just start killing processes at which point the partition can be unmounted.

I don't use any entware services myself so I can't really comment on the specifics of any particular application.

Please ignore everything I just said. I seem to be having a "brain problem" today . For some reason I was thinking services-stop happened at the end of the shutdown process rather than the beginning.

 

[ColinTaylor]

The entware-setup.sh and Diversion place that line in services-stop.
Are you suggesting to move it to unmount?

That would be my personal preference, but it's difficult to generalise because people have their routers setup in different ways.

But I would say that ideally any services that are running from a mounted USB partition ought to be shut down cleanly in the unmount script otherwise the "eject USB" function could hang. Bear in mind that people may also have swap files on mounted filesystems so a swapoff also needs to be done.

I can see that actually trying to code for that could be problematic as there might be multiple partitions being used by different processes. So putting the rc.unslung stop in services-stop would work when rebooting the router but might not when trying to eject the disk.

I don't use any entware services myself so I can't really comment on the specifics of any particular application.

 

[thelonelycoder]

That would be my personal preference, but it's difficult to generalise because people have their routers setup in different ways.

But I would say that ideally any services that are running from a mounted USB partition ought to be shut down cleanly in the unmount script otherwise the "eject USB" function could hang. Bear in mind that people may also have swap files on mounted filesystems so a swapoff also needs to be done.

I can see that actually trying to code for that could be problematic as there might be multiple partitions being used by different processes. So putting the rc.unslung stop in services-stop would work when rebooting the router but might not when trying to eject the disk.

I don't use any entware services myself so I can't really comment on the specifics of any particular application.

I agree with you, that's why I asked for your opinion. I followed several discussions here that tangent this topic. Last time it came up was for the swap file.
Entware shuts down its own services cleanly with services-stop. While Diversion is installed into the Entware environment, it does not get stopped by it.

Many of the scripts here do not have such an unmount script. Skynet uses a save function in services-stop. I might have to look into it for Diversion when time allows.
OP's WebUI Remove Disk problem is real and I have seen it myself act badly on the mounted disks, corrupting files in the process.

 

[ColinTaylor]

I'd have thought that any general router services (that are not dependent on a USB partition being mounted) should be handled by services-start and a matching services-stop.

Anything that runs from a USB partition ought to be invoked from the post-mount script, with conditional code that identifies one mount point from another. Again, there ought to be a matching unmount script for each process.

Entware is a bit naughty (I could use a different word) here because it first uses services-start to just sit there stupidly hoping that /opt is going to be mounted. Then post-mount is used to actually create /opt at which point services-start continues. Yuck.

So to "eject" a USB disk we first need to shutdown all processes that currently have files open on it. A simplistic approach might be to just move the entware shutdown script into unmount (as in post #3), and assume that any non-entware processes also have their shutdown scripts in there. But we still have to be a bit careful because unlike a normal shutdown/reboot, with an unmount the router stays up so we need to "undo" any changes our scripts may have made. By that I mean if, for example, we had changed syslog to put its output on the USB drive we now need to change it back to /tmp. Unlike the shutdown scenario we don't just want to kill syslog completely.

Sorry, just thinking aloud really...

 

[thelonelycoder]

Entware is a bit naughty (I could use a different word) here because it first uses services-start to just sit there stupidly hoping that /opt is going to be mounted. Then post-mount is used to actually create /opt at which point services-start continues. Yuck.

Diversion all starts it in post-mount by sourcing post-mount.div, which starts all in one file:

#!/bin/sh
#bof

# Diversion is free to use under the GNU General Public License version 3 (GPL-3.0)
# https://opensource.org/licenses/GPL-3.0

# Proudly coded by thelonelycoder
# Copyright (C) 2018 thelonelycoder - All Rights Reserved
# https://www.snbforums.com/members/thelonelycoder.25480/
# https://diversion.ch

# Script Version 4.0.6

# set environment PATH to system binaries
export PATH=/sbin:/bin:/usr/sbin:/usr/bin:$PATH

OF="$(find $1/entware*/bin/opkg 2> /dev/null)"

if [ "$OF" ]; then
    ln -nsf "$(echo "$OF" | sed 's~/bin/opkg~~g')" /tmp/opt
    /opt/etc/init.d/rc.unslung start $0
    logger -t Diversion "started Entware services, from $0"
    service restart_dnsmasq
    diversion ash_history
fi
#eof

By that I mean if, for example, we had changed syslog to put its output on the USB drive we now need to change it back to /tmp. Unlike the shutdown scenario we don't just want to kill syslog completely.

I have the same scenario which seems nearly impossible. Diversion relies on Dnsmasq. To offload the logfile writing I would have to restart Dnsmasq but ignoring dnsmasq.conf.add (if found) and dnsmasq.postconf or else the files content would be added to the dnsmasq.conf again.

As for now, I keep following whatever discussion I see and hope for a good solution from someone else.

 

[ColinTaylor]

Diversion all starts it in post-mount by sourcing post-mount.div, which starts all in one file:

That's much better. Presumably you have to detect and remove/disable the entware stuff in services-start during the Diversion installation?

 

[thelonelycoder]

That's much better. Presumably you have to detect and remove/disable the entware stuff in services-start during the Diversion installation?

Yes, it removes all lines the standard Entware installer scripts add and those that AB-Solution used to create.
The problem is when later on old code gets added by hand or the entware-setup.sh is called. It messes everything up again.
My post-mount script is not relying on device labels or names, which is a great help. I have checks built into the installer to ensure there's only one folder named "entware*" on the mounted partitions while installing Diversion. It renames non-active Entware folders during the process.

 

[kernol]

Thanks ColinTaylor and thelonelycoder for interesting discussion - ... so I conclude no ready solution as yet - and my problem not unique but presumably rather wide spread for all who use Diversion / Entware etc.

I live in South Africa - where we have periodic [sometimes frequent] "black-outs" - meaning loss of electricity supply.
These occur through deliberate "load-shedding" by the monopolistic government owned electricity supply company [Eskom - usually when it "runs out of coal"?!?!!] and/or through local municipal authorities lack of maintenance causing failures.

So ... what I am trying to achieve firstly - is a graceful shutdown of services associated with the USB so that when the power dies completely [and the router along with it] - no harm is caused to my custom installation. My UPS knows when there is a loss of mains supply - and uses scripts via SSH to shutdown home PC's etc.

I plan to build a script to be initiated by the UPS to unmount my Router's USB drive - so if the power-out extends beyond the UPS's battery capabilities - no harm done.

Any help would be sincerely appreciated.
Best for 2019.

 

[ColinTaylor]

So ... what I am trying to achieve firstly - is a graceful shutdown of services associated with the USB so that when the power dies completely [and the router along with it] - no harm is caused to my custom installation. My UPS knows when there is a loss of mains supply - and uses scripts via SSH to shutdown home PC's etc.

If your objective is to shutdown the router during the UPS' grace period, rather than just unmounting the USB drive then there was a similar discussion here. (In summary: use the halt command)

 

[kernol]

If your objective is to shutdown the router during the UPS' grace period, rather than just unmounting the USB drive then there was a similar discussion here. (In summary: use the halt command)

Thanks Colin - however that thread ended in trouble when USB drives attached. I am approaching the problem one step at a time.

My USB will not umount safely - whether I use Webgui or command line. It fails either way.

So my first priority remains to umount the USB. Once that is good to go ... I will move on to any other steps required.

 

[ColinTaylor]

Thanks Colin - however that thread ended in trouble when USB drives attached. I am approaching the problem one step at a time.

My USB will not umount safely - whether I use Webgui or command line. It fails either way.

So my first priority remains to umount the USB. Once that is good to go ... I will move on to any other steps required.

My reading of that other thread was that shutdown was working fine. He then reported a problem with the WiFi not coming back on after the power-on. Some suggestions were subsequently made but the OP never responded to them (so maybe it was a one-off).

Regarding your "one step at a time" approach; normally I would agree with that, but you are talking about two completely different scenarios. As previously discussed, trying to fix the "Eject USB" option in the GUI is probably not achievable. But shutting down the router via the halt command should work and cleanly unmount the USB drive in the process.

 

[kernol]

Gotcha - Thanx.

I was hoping that someone knew what the Webgui was doing on reboot as distinct from Webgui Eject Disk - so I could perhaps trace the steps to identify what steps were integral to closing services relative to USB yet leaving the router running.

Clearly no one has achieved that - so best I accept that when I want to remove the USB safely I can't and must just live with corrupted USB drive every time.

I will look at the alternative of "halt" and may have to use that - Power off and remove USB. Better ... but still a tad amazed that no one has a solution to simple graceful umount.

 

[ColinTaylor]

I was hoping that someone knew what the Webgui was doing on reboot as distinct from Webgui Eject Disk - so I could perhaps trace the steps to identify what steps were integral to closing services relative to USB yet leaving the router running.

I think we already know the difference. With a reboot the router is just killing processes until there are none left and then syncing the filesystems. With the Eject USB option it is stopping the USB-based services that it knows about and then unmounting the disk.

Clearly no one has achieved that - so best I accept that when I want to remove the USB safely I can't and must just live with corrupted USB drive every time.

As previously discussed Asus' "Eject USB" code doesn't (and can't) know anything about unofficially installed software. It is really the responsibility of the creators of such software to make sure they are compatible with the Eject USB option.

I will look at the alternative of "halt" and may have to use that - Power off and remove USB. Better ... but still a tad amazed that no one has a solution to simple graceful umount.

As per the discussion with thelonelycoder, that is impossible because we don't know what processes should be killed and what processes need to be reconfigured (or how to do that) and restarted. You could write a script that just killed all the processes using the USB drive (similar to what reboot does), but where you're using software like Diversion you would be left with a non-functioning network.

 

[martinr]

I think we already know the difference. With a reboot the router is just killing processes until there are none left and then syncing the filesystems. With the Eject USB option it is stopping the USB-based services that it knows about and then unmounting the disk.

As previously discussed Asus' "Eject USB" code doesn't (and can't) know anything about unofficially installed software. It is really the responsibility of the creators of such software to make sure they are compatible with the Eject USB option.

As per the discussion with thelonelycoder, that is impossible because we don't know what processes should be killed and what processes need to be reconfigured (or how to do that) and restarted. You could write a script that just killed all the processes using the USB drive (similar to what reboot does), but where you're using software like Diversion you would be left with a non-functioning network.

Having read through your recent discussion, it makes me wonder what problems might result when powering down by switching off/unplugging. (I run Diversion, Skynet and Pixelserv, with the associated USB stick in the back of the router.)
Last week I had a glitch which would not clear with reboots from the GUI, but which did clear with a power-down and 20 second wait before powering up again.

With a USB drive plugged in and running such software, should we send a halt command before manually powering down, to prevent problems? (And add a small UPS to the router to prevent problems from short-term mains outages, too, eg https://www.amazon.co.uk/dp/B0187PWCLO/?tag=smallncom-21 after ensuring voltage, current, polarity and connectors all match, of course)

 

[thelonelycoder]

Having read through your recent discussion, it makes me wonder what problems might result when powering down by switching off/unplugging. (I run Diversion, Skynet and Pixelserv, with the associated USB stick in the back of the router.)
Last week I had a glitch which would not clear with reboots from the GUI, but which did clear with a power-down and 20 second wait before powering up again.

With a USB drive plugged in and running such software, should we send a halt command before manually powering down, to prevent problems? (And add a small UPS to the router to prevent problems from short-term mains outages, too, eg https://www.amazon.co.uk/dp/B0187PWCLO/?tag=smallncom-21 after ensuring voltage, current, polarity and connectors all match, of course)

The discussed file problems or corruptions are depending on more variables than just the basic router/USB device.

I regularly cut power to my test router several times a day, with a switchable power strip. I never have file corruption on the device attached to it. I would know immediately, I develop Diversion on it. Never once have I had problems with that router/device combo.
Maybe I'm just lucky.

 

[martinr]

..
Maybe I'm just lucky.

I doubt it. Like the golfer, in reply to his opponent’s claims that every shot he made was a lucky one, said: “funny thing is, the more I practice, the luckier I get.”