March 26, 200818 yr Ok, I haven't delved into this that much, there may be a script already that is called when starting or stopping the array. I'd like it to automatically call another script, say /boot/custom/startarray and /boot/custom/stoparray. If the script doesn't exist, just keep on going. If it does, then do what's in the script when appropriate, i.e. for the stoparray script you'd want it to run just before you try to stop the array (so you can shutdown any custom programs that would keep the disk active, and thus not able to cleanly unmount). For the startarray script you would want that run after the array has been started (so you can restart any programs that need the array to be started first). In my case, I'm having to link several files and directories to another disk, both to keep the ramdisk from getting too large, and also to not have to keep copying files in and out of the ramdisk. For example, I need to keep asterisk's voicemail, recorded calls, and database between reboots. This causes asterisk to keep files open on one of my data disks, and simply pressing stop in the web config is not enough to actually stop the array. I must stop asterisk manually, then I can stop the array.
March 26, 200818 yr I think this is a great idea. To make it a tiny bit more clear when the scripts will be run, perhaps the names of the files can be: /boot/custom/before_array_stop /boot/custom/after_array_start As you said, if they do not exist, just continue. If they do, execute them as shell scripts. Joe L.
March 26, 200818 yr Add a bit more flexibility with: pre_array_start post_array_start pre_array_stop post_array_stop
March 26, 200818 yr Author Well, let's just go all out and have: pre_array_start_onboot post_array_start_onboot pre_array_start post_array_start pre_array_stop post_array_stop The first two are for when the array first starts on a fresh boot. I need to do things in a certain order, and I just have it all in the go script currently. This way I can have certain things done (or not done) when the array is first started on a fresh boot, then another way when just starting and stopping via the web interface. If the array is brought up before emhttp, then we don't need those first two scripts. Just bring the array up on boot normally, then when it's started or stopped via the web interface call the other scripts. If the array is NOT brought up before emhttp, then we need those first two scripts. Of course, I'd be happy even if the script is run every time the array is started, even on a fresh boot. I'd figure out a way to work around it.
March 26, 200818 yr Well, let's just go all out and have: pre_array_start_onboot post_array_start_onboot pre_array_start post_array_start pre_array_stop post_array_stop pre_array_start_onboot is equivalent to the GO script ? I know we're asking for hooks here. I would like to see a gone script that is called when a shutdown/poweroff is called. Right now I have my startup scripts add an entry to /etc/rc.d/rc.local_shutdown Ideally I think the archtecture should be a set of directories (named by the user). Like in an /etc/rc.d way. Each directory is for a run phase and we can drop what ever scripts we want in each of these directories. For example here is my go script root@unraid:/boot/config# more go #!/bin/bash # Start the Management Utility /usr/local/sbin/emhttp & fromdos < /boot/config/rc.local/rc.local_startup | sh Here is the go startup script that processes all scripts in my rc.local directory. #!/bin/bash logger -trc.local_startup -plocal7.info -is "Initiating Local Custom Startup." for script in /boot/config/rc.local/* do scriptbase=${script##*/} # Strip pathname if [ $scriptbase = "rc.local_startup" ] ;then continue; fi if [ $scriptbase = "rc.local_shutdown" ] ;then continue; fi ( echo "Processing $script" fromdos < $script | sh ) 2>&1 | logger -t$scriptbase -plocal7.info -is done # Setup shutdown script RCFILE=rc.local_shutdown if ! grep /boot/config/rc.local/$RCFILE /etc/rc.d/$RCFILE > /dev/null 2>&1 then echo /boot/config/rc.local/$RCFILE >> /etc/rc.d/$RCFILE fi if [ ! -x /etc/rc.d/$RCFILE ] then chmod u+x /etc/rc.d/$RCFILE fi logger -trc.local_startup -plocal7.info -is "Local Custom Startup Complete." So if we had a series of directories similar to rc.d run levels Then we can have a master script that is called at each run level which then processes all scripts in it's respective directory (or whatever for each statel.. looks like 6 have been defined) /boot/custom/etc/rc.d/unraid0.d /boot/custom/etc/rc.d/unraid1.d /boot/custom/etc/rc.d/unraid2.d ...
March 26, 200818 yr Author pre_array_start_onboot is equivalent to the GO script ? Only if emhttp is what starts the array. If you comment out emhttp in the go script, is the array still started? If so, then something else has started the array for us. If not, then it was emhttp, and no we won't need the *onboot scripts. The *onboot scripts weren't for starting programs when the box first booted, they were to have separate actions happen the very first time the array is started after a boot versus when the array is started subsequent times. An example: In the go script, I have things going on like packages being installed, directories removed, symbolic links made, programs started, etc. Many of these things depend on having the array up (mainly being able to make symbolic links), and need to be done in a certain order. Now, I could just let the programs be started twice (once in the go script, once again when the array is started) and it should still work ok. But I can see where it'd be useful to have a separate script called the first time the array is started vs subsequent starts. Actually, even if emhttp is what starts the array, it might still be useful to have a special script called the very first time the array is started vs subsequent starts. This way I can just dump everything in my go script into this *onboot script instead. Reason why that'd be useful is in case the server doesn't bring up the array right away on the first boot (maybe you have a missing drive). If my stuff is called via the go script, it won't be setup right. If we wait until the array is first brought online, then it'll work fine.
March 26, 200818 yr I believe emhttp is what starts the array. I see the point of the initial first start of the array script. I agree with the need. My added recommendation though is to process a series of scripts in respective directories allowing users to drop scripts/scriptlets in directories without having to modify a script. This way we can just include scripts, they can be downloaded as is, and dropped in place. I have no issue with modifying scripts, but from what I can tell there are many users new to linux in need of a drop in architecture.
March 26, 200818 yr Author I think I see what you're saying now. It's easier for me to visualize it as dropping scripts in directories like this: /boot/custom/firstarraystart /boot/custom/arraystart /boot/custom/arraystop Then you can have different script names to signify whether it should be run before or after the event (i.e. when the array is started or stopped). So to shutdown a program (in my case Asterisk) before the array is stopped, have a script named /boot/custom/arraystop/before_asterisk. So all unRAID has to do is run all scripts named /boot/custom/arraystop/before*. If things need to be in a certain order, then you can just put a number or letter after the before_ part. In my example above, if asterisk must be the first thing shutdown, I'd name the script /boot/custom/arraystop/before_0asterisk.
March 26, 200818 yr Very close, only I would use the 6 levels suggested, Each as it's own directory. There could be a master rc script that investigates it's own name (in shell) or via arg1 and use the appropriate directory, then run all the subsequent scripts. /boot/custom/array.d/start_pre_onboot.d /boot/custom/array.d/start_post_onboot.d /boot/cuistom/array.d/start_pre.d /boot/custom/array.d/start_post.d /boot/custom/array.d/stop_pre.d /boot/custom/array.d/stop_post.d Now depending on the script and level you need You drop a script in the respective directory. For example, Joe L's setra script would get dropped in /boot/custom/array.d/start_pre_onboot.d/S01_setra_hd Asterik mt-daapd, slimserver, etc, etc would be dropped in /boot/custom/array.d/start_post.d/S01_mt-daapd /boot/custom/array.d/start_post.d/S02_slimserver /boot/custom/array.d/start_post.d/S03_asterik Then for shutdown. /boot/custom/array.d/stop_pre.d/K01_mt-daapd /boot/custom/array.d/stop_pre.d/K02_slimserver /boot/custom/array.d/stop_pre.d/K02_asterik (such as a script to archive the boot filesystem somewhere) If people need post stop scripts they go in /boot/custom/array.d/stop_post.d (maybe archive/rsync the boot filesystem off the host somewhere?) Here's something I just rapidly slapped together that could be used to call the appropriate scripts. Note also, that all output is spooled through syslog via logger. root@rgclws ~/sh >cat array_mgmt.sh #!/bin/bash if [ ${DEBUG:=0} -gt 0 ] then set -x -v fi P=${0##*/} # basename of program R=${0%%$P} # dirname of program P=${P%.*} # strip off after last . character O=${P%_*} # Operand D=${P#${O}_} # Data (last param before _ character) ROOT="/boot/custom/array.d" if [ ! -z "${1}" ] then MODE="${1}" else MODE="${P}" fi case "${MODE}" in array_start_pre_onboot ) ;; array_start_post_onboot ) ;; array_start_pre ) ;; array_start_post ) ;; array_stop_pre ) ;; array_stop_post ) ;; * ) ;; esac if [ ! -d ${ROOT}/${MODE}.d ] then echo "$P: runlevel directory ${MODE} not defined, skipping" exit 129 fi logger -t${P} -plocal7.info -is "Initiating Local Custom runlevel: ${MODE}." for script in ${ROOT}/${MODE}.d/* do scriptbase=${script##*/} # Strip pathname ( echo "Processing $script" fromdos < $script | sh ) 2>&1 | logger -t$scriptbase -plocal7.info -is done logger -t${P} -plocal7.info -is "runlevel: ${MODE} complete." root@rgclws ~/sh >./array_mgmt.sh start_pre_onboot array_mgmt[8376]: Initiating Local Custom runlevel: start_pre_onboot. S01-setra.sh[8380]: Processing /boot/custom/array.d/start_pre_onboot.d/S01-setra.sh S02-something.sh[8383]: Processing /boot/custom/array.d/start_pre_onboot.d/S02-something.sh array_mgmt[8385]: runlevel: start_pre_onboot complete.
March 26, 200818 yr Author I think either way would work. Each of my three directories would be able to take two different types of scripts (one to run before the array is started/stopped, and one to run after the array is started/stopped), for a total of six possible combinations. Yours has six directories able to take one type of script, for a total of six possible combinations. So using my example, unRAID's script to start the array would look something like this: #!/bin/bash /boot/custom/arraystart/before_* -- insert whatever unRAID currently does to bring up the array -- /boot/custom/arraystart/after_* Your way accomplishes the same thing like so: #!/bin/bash /boot/cuistom/array.d/start_pre.d/* -- insert whatever unRAID currently does to bring up the array -- /boot/custom/array.d/start_post.d/* Of course I have grossly oversimplified it, but you get the gist. Personally I'd be happy to just have something to automatically run after the array starts, and something else to run before the array stops, but if it's not too much work I'd like to see this full implementation instead.
March 26, 200818 yr It's up to Tom if he wants to implement what we've proposed. I guess we'll see when he responds.
Archived
This topic is now archived and is closed to further replies.