Mount scripts

[shantanugoel]

Added scripts that are run before a partition is mounted and after a partition is mounted.

pre-mount is useful for many things, the most common use being running e2fsck on a file system automatically before it is mounted

post-mount is useful for things like that can be autorun when a partition is mounted. e.g. running rc.unslung or another process that can start your optware related program installations on boot up. Other scripts like services-start are not useful for this because they are not really in sync with when a partition is exactly mounted. e.g. services-start some times run even before the system actually mounts a partition and makes it available.

I've tested these scripts with the above mentioned scenarios on my system and they are working pretty well in starting up optware and running fsck when needed.

[shantanugoel]

Eric, I went through the code and USB devices seem to be mounted in a separate thread through hotplug. So, we should be able to make a blocking call in this context without stopping the rest of the router processes (e.g. boot). I can create another version of the run_custom_script (e.g. run_custom_script_blocking) that runs the scripts in blocking fashion (e.g. by using eval instead of xstart). This should take care of any issues. This is similar to how oleg's firmware for other asus routers does it as well.

If you think this is a good way to go, then I can implement and test it and propose the changed code.

[RMerl]

Could the scripts be simply added as hotplug rules? That way it would be totally async from the rc process, while be blocking but only for the USB plug event? That's also assuming that hotplug events are triggered even if booting with a USB disk already plugged in.

[shantanugoel]

Adding it to hotplug rules directly would make it lose the context of other things done already by usb hotplug code. e.g. we want to run these scripts only for mass storage while several hotplug events fire when any usb device is added. The usb hotplug code takes care of identifying whether it is a storage device and setting up paths etc. The current place where the scripts are added are also asynch of the all the rest of the rc process and would run only and only if a USB storage device is added and in that hotplug thread context itself. On going through the code, I saw that even Asus (tomato?) has usb storage related pre mount, post mount, pre unmount etc scripts called in the same way (e.g. check for run_nvscript calls in this file but Im not sure whether run_nvscript works fine or not). So, I think the location of the calling scripts should be good but we surely would need a blocking variation of run_custom_script if we chose to add these scripts. Also, would be nice to provide parameters to the script (i.e. which device was added, or what mount point it was mounted to, etc).

[RMerl]

Ok. Go ahead and update your patch with a new run_custom_script_blocking() routine (that relies on eval()), and insert a new post-mount script.

Is there any scenario where you think also having a pre-mount script could be useful?

[shantanugoel]

pre-mount is mainly useful for automatically running fsck on the drives if needed. Since, most people just set the device and forget about them, checking them for errors is forgotten most of the times. And running fsck manually, even if you remember to do it regularly, sometimes proves difficult because once mounted, the device might start to be used by some processes (e.g. media server, transmission and what not) and many times it becomes difficult to trace down which all processes are using it, then unmount it and then run fsck. Pre-mount can also be used for managing custom fstabs (e.g. if you switch between multiple drives. like I currently have 2 different disks that I usually connect. 1 has entware installed and another has optware installed. So, I can alternate between the two automatically by just switching the drives)

[RMerl]

The fsck scenario alone is a good reason to also allow pre-mount (I must be tired, I was somehow thinking fsck is usually run run post-mount :) ). Go ahead then, with both a pre-mount and post-mount script.

Hopefully, we'll get new toys from Asus soon (they already have a beta version with 64 KB nvram out there), as for the time being I prefer to slow down on development here until we can re-base on a newer firmware.

[shantanugoel]

Updated the patch. Apologies for the delay. Had made the changes long back but didn't get time to test until tonight due to work pressures. Have also tested blocking to work (and only for mounting while not blocking rest of the processes) by keeping sleeps in the scripts. The pre-sleep and post sleep messages in syslog are separated by other processes and mounting messages occur only after post-sleep messages confirming that the behavior is as intended.