April 21, 201016 yr I still prefer Delete Existing Parity Data and Disk Configuration I think it is far less likely (in my opinion) to be pressed in a panic situation when a user is attempting to rebuild a failed disk. Joe L. True, but people may not press it when they are supposed to either. Create Array, Initialize Array, Build New Array
April 21, 201016 yr 'Create the Array' creates no better than Restore button restores. We are not so much creating here than we are destroying (throwing away good parity). Negative nuance to the name is more appropriate for this dangerous button. Are you and purko the same person?
April 21, 201016 yr True, but people may not press it when they are supposed to either. Based on all the people who pressed it when they thought it would "fix" their array or restore data, I'd say anything that even remotely sounds like it builds/creates anything is bad. The few people who really need it, but are afraid to, will ask for guidance or read the manual more closely. At least they do not lose data. Basically, it is only needed is you are performing the "trust" procedure to force a specific array slot to be invalid or when you are removing a data drive from your array and reducing the number of data drives assigned. The only other time is when you really do want to delete the parity and disk configuration. (and calculate it new) Joe L.
April 21, 201016 yr So when removing a drive from the array or intentionally breaking the array protection is it's only use? Well I can see the purpose of removing a drive. But why would destroying the parity drive ever be needed? Both of those can be done by simply removing the parity or data drive from the array. If no other reason for the button then remove it?
April 21, 201016 yr So when removing a drive from the array or intentionally breaking the array protection is it's only use? Well I can see the purpose of removing a drive. But why would destroying the parity drive ever be needed? Both of those can be done by simply removing the parity or data drive from the array. If no other reason for the button then remove it? Just removing the parity disk is not the same as never having one installed. It is equivalent to the parity disk failing. In the same way, simply un-assigning it does not remove it. un-assigning a disk (parity or data) is exactly the same to unRAID as having it fail unless you set a new disk configuration by deleting the existing one and forcing unRAID to create a new one when you next start the array. The new disk configuration will be based on the currently assigned and working disks. There are times when you wish to add several disks with data. It is quicker to just delete the existing configuration and again create a new one when you next start and calculate parity on the new set of assigned disks.
April 21, 201016 yr So when removing a drive from the array or intentionally breaking the array protection is it's only use? Well I can see the purpose of removing a drive. But why would destroying the parity drive ever be needed? Both of those can be done by simply removing the parity or data drive from the array. If no other reason for the button then remove it? Just removing the parity disk is not the same as never having one installed. It is equivalent to the parity disk failing. In the same way, simply un-assigning it does not remove it. un-assigning a disk (parity or data) is exactly the same to unRAID as having it fail unless you set a new disk configuration be deleting the existing one and forcing unRAID to create a new one when you next start the array. The new disk configuration will be based on the currently assigned and working disks. There are times when you wish to add several disks with data. It is quicker to just delete the existing configuration and again create a new one when you next start and calculate parity on the new set of assigned disks. Ok. Perhaps the message should say what it's intended uses are. Like "Choose this ONLY IF you are 1. ... or 2. ... There have been some studies that when someone is speaking (or writing) what they don't want you to do doesn't really work. People have a tendency not to hear or read the "don't" word. FWIW.
April 21, 201016 yr Are you and purko the same person? Huh? Are you a troll queeg? Oh wait we've been through that. Are you the same person who wanted to give me that bsod? I have one to sell you... Real cheap too!
April 21, 201016 yr Are you and purko the same person? Huh? Are you a troll queeg? Oh wait we've been through that. Are you the same person who wanted to give me that bsod? LOL! That was like, "Are you the same person who wanted to give me pubic lice?"
April 21, 201016 yr Are you and purko the same person? Huh? Are you a troll queeg? Oh wait we've been through that. Are you the same person who wanted to give me that bsod? LOL! That was like, "Are you the same person who wanted to give me pubic lice?" Sharing the wealth!
April 21, 201016 yr Ok, ok, I'm paying attention now. My secret wish is that enough of crashplan were installed that it would be simple to get it running on unRAID. I mean, I never was able to get it installed. Too many steps and all that. crashplan shouldnt be that hard to install.. I'll be doing this in the next few days, so I can write up any steps taken.. Until crashplan change their 'headless' install mechanisms or document how to generate the .identity required from the command line or manually then you'll always need to use ssh and portforwarding (or similar) to initially set it up from another machine. I imagine this is the bit most people will fall over at. It's scriptable to an extent but there is still enough manual pain to be gone through that it's probably not worth it. The scriptable bits are the easy parts. There is already a Crashplan installation etc thread, please add to that if you come up with improvements.
April 21, 201016 yr Author 'Create the Array' creates no better than Restore button restores. We are not so much creating here than we are destroying (throwing away good parity). Negative nuance to the name is more appropriate for this dangerous button. Right. The 'Restore' button does not create anything. It deletes/throws away the current parity data, then schedules a new parity sync for when the array is next started. So essentially the new parity is calculated when you press the 'Start' button (this is backed up by the text that displays next to the 'Start' button in this scenario - "Start the array and initiate a Parity-Sync" or something like that). Looking at it that way, the 'Restore' button breaks the array, and the 'Start' button creates a new array based on the current disks. In my year+ of unRAID use, I have only used the 'Restore' button once, when removing a small drive that I did not want to replace. This is not a terribly common task in the unRAID environment. If LimeTech insists on keeping the button's name as it is, I would at least request that they tuck the button away on some other page, not on the main page right next to commonly used buttons, like 'Start'. Same goes for the 'Format' button - if you won't change it, at least move it off the Main page.
May 16, 201016 yr We should also add this to the list: * Distinct syslog entries for the following two events: -- The array has started. (post_array_start) -- The array is going for a stop. (pre_array_stop) And/or: * Upon the above mentioned events, call the following script (if such exists) with start or stop argument respectively: /etc/rc.d/rc.custom start /etc/rc.d/rc.custom stop Or, (best): * Invoke each (if any) rc.* script found in the /etc/rc.d/unraid.d/ directory with a start or stop argument. Some discussion on that took place here: http://lime-technology.com/forum/index.php?topic=5686.msg53271#msg53271
May 16, 201016 yr First, thanks to Rajahal for taking the time to summarize what the "community" views as important features to be implemented. I want to address the first three items: Rename 'Restore' button. Even you guys can't figure out the right wording for this - so I got rid of it entirely in 4.5.4, replacing with a command called 'initconfig'. In those rare instances where a user needs to do this operation, the instructions will be to type 'initconfig' at the console or telnet session. But unlike users, we use this button all the time as part of the procedure to prep a server for shipment. This is because servers are tested with drives & once ready to ship, we need to 'Restore' the configuration to it's initial state so that when the customer boots up, it doesn't show a bunch of wrong/missing disks. Probably in the future we can re-address this and perhaps make a plugin for 5.0 called 'Expert Operations' where some of these more esoteric functions can be gathered together. Remove global Format button. Don't see the reason for this in the absence of bugs. I can see putting a Format button on individual Disk pages if/when other file system types are implemented, e.g., ext3/4 or ntfs3g, in order to have different disks have different file systems. But until that's implemented, no need. Also, when someone builds a server with say 15 brand new hard drives, there's a big time advantage with formatting in parallel. Powerdown. This already works, both as a command, and as a result of pushing the chassis power button. For other items on the list... well the approach with 5.0 is to build a 'framework' that implements core functionality, a gui plugin system, and an event registration system. The idea being to let some of you talented folks write plugins to accomplish some of this stuff. Finally - I want to ask one favor of you all... please don't post stuff that modifies the executable, or goes over the top with descriptions like "Destroy"... I understand the sentiment, but in my mind it's not helpful.
May 16, 201016 yr First, thanks to Rajahal for taking the time to summarize what the "community" views as important features to be implemented. I want to address the first three items: Rename 'Restore' button. Even you guys can't figure out the right wording for this - so I got rid of it entirely in 4.5.4, replacing with a command called 'initconfig'. In those rare instances where a user needs to do this operation, the instructions will be to type 'initconfig' at the console or telnet session. But unlike users, we use this button all the time as part of the procedure to prep a server for shipment. This is because servers are tested with drives & once ready to ship, we need to 'Restore' the configuration to it's initial state so that when the customer boots up, it doesn't show a bunch of wrong/missing disks. Probably in the future we can re-address this and perhaps make a plugin for 5.0 called 'Expert Operations' where some of these more esoteric functions can be gathered together. This works for me Remove global Format button. Don't see the reason for this in the absence of bugs. I can see putting a Format button on individual Disk pages if/when other file system types are implemented, e.g., ext3/4 or ntfs3g, in order to have different disks have different file systems. But until that's implemented, no need. Also, when someone builds a server with say 15 brand new hard drives, there's a big time advantage with formatting in parallel. I still think the addition of an "You are about to format the following disks: /dev/sdb, /dev/sdg, etc... Are you sure?" is a great suggestion. It would not be too difficult, even if only in javascript in the browser as a confirm button. It would let you format in parallel, and save your butt if there were ever another situation where disks were identified as unformatted incorrectly. (It has happened twice already. When it happened to me three years ago I was upgrading a disk. It it had been a failed disk it would have been a real nightmare.) You cannot predict "bugs" that creep in. What if udev changes? (Wait, that already happened ) Powerdown. This already works, both as a command, and as a result of pushing the chassis power button. It works only if emhttp has not crashed or was not killed by the kernel out-of-memory process. Experience has been that it is one of the first identified as a way to free up some memory. I think there is still a need for an independent method to cleanly stop and powerdown the array. (One that does not rely on wget localhost...) It should have a "--killall" option, to kill whatever is keeping a disk from being un-mounted. Today, if a disk is busy, pressing the powerdown button will eventually crash the server, once the syslog fills and uses all available ram. --killall should not be the default, but it should be available. We are constantly seeing people who are unable to stop their server because something has their server "busy" It could even be the "mover" script... it is not necessarily an add-on. For other items on the list... well the approach with 5.0 is to build a 'framework' that implements core functionality, a gui plugin system, and an event registration system. The idea being to let some of you talented folks write plugins to accomplish some of this stuff. Finally - I want to ask one favor of you all... please don't post stuff that modifies the executable, or goes over the top with descriptions like "Destroy"... I understand the sentiment, but in my mind it's not helpful. Pretty sure you are referring to "emhttp" here. I agree it is extreme, especially since the user did it with "sed" I was a bit surprised at that approach too. Perhaps, at some time in the future, you'll consider a separate file to hold the "strings" used for buttons and text on the interface. It would allow international users to have their own language files. I'll bet it would be a huge win for everybody. Those who did not like "Restore" would change it in the language.xml file (or whatever you decide) and not affect anything in the emhttp executable. Foreign users would likely even submit their translations as languagename.xml. You could choose/link to the desired one in the management interface. Thank you for the removal of the "Restore" button. ;D ;D ;D ;D ;D One quick question? Would you use the new "initconfig" command in the "trust-my-parity" process in the same way you would have the "restore" button? (We'll need to update the wiki now that the button is removed) Joe L.
May 16, 201016 yr We should also add this to the list: * Distinct syslog entries for the following two events: -- The array has started. (post_array_start) -- The array is going for a stop. (pre_array_stop) And/or: * Upon the above mentioned events, call the following script (if such exists) with start or stop argument respectively: /etc/rc.d/rc.custom start /etc/rc.d/rc.custom stop Or, (best): * Invoke each (if any) rc.* script found in the /etc/rc.d/unraid.d/ directory with a start or stop argument. Some discussion on that took place here: http://lime-technology.com/forum/index.php?topic=5686.msg53271#msg53271 I would strongly argue for /etc/rc.d/rc.custom start /etc/rc.d/rc.custom stop And strongly argue against Or, (best): * Invoke each (if any) rc.* script found in the /etc/rc.d/unraid.d/ directory with a start or stop argument. The reason is simple. we can easily modify behavior of the /etc/rc./rc.custom driving script for any future needs. It will evolve, there is no way we'll get it perfect for all time. We lose control if emhttp just processes unraid.d/* and have no way to add features, checks, sequencing, etc.
May 16, 201016 yr I would strongly argue for /etc/rc.d/rc.custom start /etc/rc.d/rc.custom stop I'm in this camp. Keep it simple for emhttp. At the shell level we can modify rc.custom to process the unraid.d directory. My current need is the ability for emhttp to run a script after the array is started and run a script before the array is stopped. Everything else can be handled externally.
May 16, 201016 yr Powerdown. This already works, both as a command, and as a result of pushing the chassis power button. It works only if emhttp has not crashed or was not killed by the kernel out-of-memory process. Experience has been that it is one of the first identified as a way to free up some memory. I thought the above points need to be stated again. It also ties in with the points below, that there also needs to be a means to shutdown the server safely when additional tasks are using the unRAID drives. I think there is still a need for an independent method to cleanly stop and powerdown the array. (One that does not rely on wget localhost...) It should have a "--killall" option, to kill whatever is keeping a disk from being un-mounted. Today, if a disk is busy, pressing the powerdown button will eventually crash the server, once the syslog fills and uses all available ram. --killall should not be the default, but it should be available. We are constantly seeing people who are unable to stop their server because something has their server "busy" It could even be the "mover" script... it is not necessarily an add-on. Perhaps, at some time in the future, you'll consider a separate file to hold the "strings" used for buttons and text on the interface. It would allow international users to have their own language files. I'll bet it would be a huge win for everybody. Those who did not like "Restore" would change it in the language.xml file (or whatever you decide) and not affect anything in the emhttp executable. Foreign users would likely even submit their translations as languagename.xml. You could choose/link to the desired one in the management interface. This is an excellent suggestions. It's been entirely way too long since I've dealt with C, but in C#/Java we use external resource bundles to accomplish this. It's really nothing but some libraries wrapped around string arrays stored in external files. Way back in the day when I was dealing with embedded hardware markets, we read in the strings from an external file into our 'BFA' variable then utilized them with BFA[DISPLAY_EDIT_BUTTON]. I would strongly argue for /etc/rc.d/rc.custom start /etc/rc.d/rc.custom stop I'm also in this camp. The more logic that is externalized and customizable the better for the users.
May 16, 201016 yr I would strongly argue for /etc/rc.d/rc.custom start /etc/rc.d/rc.custom stop And strongly argue against Or, (best): * Invoke each (if any) rc.* script found in the /etc/rc.d/unraid.d/ directory with a start or stop argument. The reason is simple. we can easily modify behavior of the /etc/rc./rc.custom driving script for any future needs. Who did you have in mind by 'we'? We as unRAID users, or we as makers of new addon packages? Every new addon package will be fighting to make some sort of modification to that single '/etc/rc./rc.custom' file. Much cleaner way is, when I give you a new addon package, its installer script can (if it needs to) put a single start/stop script in the '/etc/rc.d/unraid.d/' directory, and that's all. The addon isn't touching anything on your system. There's my '/etc/rc.d/unraid.d/rc.mynewaddoncontrol' -- start it or stop it as you wish by passing it a start/stop argument, can't get any simpler than that. And that could be the default behaviour of a stock '/etc/rc.d/rc.custom' script: invoke whatever scripts are found in '/etc/rc.d/unraid.d/'.
May 16, 201016 yr I would strongly argue for /etc/rc.d/rc.custom start /etc/rc.d/rc.custom stop And strongly argue against Or, (best): * Invoke each (if any) rc.* script found in the /etc/rc.d/unraid.d/ directory with a start or stop argument. The reason is simple. we can easily modify behavior of the /etc/rc./rc.custom driving script for any future needs. Who did you have in mind by 'we'? We as unRAID users, or we as makers of new addon packages? Every new addon package will be fighting to make some sort of modification to that single '/etc/rc./rc.custom' file. Much cleaner way is, when I give you a new addon package, its installer script can (if it needs to) put a single start/stop script in the '/etc/rc.d/unraid.d/' directory, and that's all. The addon isn't touching anything on your system. There's my '/etc/rc.d/unraid.d/rc.mynewaddoncontrol' -- start it or stop it as you wish by passing it a start/stop argument, can't get any simpler than that. The method you described is EXACTLY how I envision it. Each add-on has its OWN /etc/rc.d/unraid.d/rc.add-on-name script. The main loop/control logic to invoke those in turn can reside in /etc/rc.d/rc.custom rc.custom when invoked with a "start" argument can iterate through /etc/rc.d/unraid.d/rc.* an invoke each in turn. So, by we, I think he means just few very experienced developers. I think /etc/rc.d/rc.custom will be modified by very few. Once we get the basic structure in place, it will not need changing. The individual /etc/rc.d/unraid.d/rc.* scripts will be modified by the add-on developers for their needs. Each will be required to support a "start" and "stop" argument at a minimum. That will allow the clean start and stop of add-on packages. Those scripts will change a lot over time. Joe L.
May 16, 201016 yr I see Joe L posted while I was in process of typing up pretty much exactly what he said, we're using the best of both worlds. The approach I envisioned was that /etc/rc.d/rc.custom would have the control logic to iterate through the /etc/rc.d/unraid.d/rc.* scripts. Once the control logic is in place and worked out, not many people will ever modify it at all. This also allows for package creators to modify their individual /etc/rc.d/unraid.d/rc.* scripts to their hearts content without conflicts or negative effects to the other addon packages.
May 16, 201016 yr I would strongly argue for /etc/rc.d/rc.custom start /etc/rc.d/rc.custom stop And strongly argue against Or, (best): * Invoke each (if any) rc.* script found in the /etc/rc.d/unraid.d/ directory with a start or stop argument. The reason is simple. we can easily modify behavior of the /etc/rc./rc.custom driving script for any future needs. Who did you have in mind by 'we'? We as unRAID users, or we as makers of new addon packages? Every new addon package will be fighting to make some sort of modification to that single '/etc/rc./rc.custom' file. Much cleaner way is, when I give you a new addon package, its installer script can (if it needs to) put a single start/stop script in the '/etc/rc.d/unraid.d/' directory, and that's all. The addon isn't touching anything on your system. There's my '/etc/rc.d/unraid.d/rc.mynewaddoncontrol' -- start it or stop it as you wish by passing it a start/stop argument, can't get any simpler than that. The method you described is EXACTLY how I envision it. Each add-on has its OWN /etc/rc.d/unraid.d/rc.add-on-name script. The main loop/control logic to invoke those in turn can reside in /etc/rc.d/rc.custom rc.custom when invoked with a "start" argument can iterate through /etc/rc.d/unraid.d/rc.* an invoke each in turn. So, we are saying exactly the same thing! What then were you strongly arguing against? If you "envision" that you will be the one providing/modifying the '/etc/rc.d/rc.custom' script, that's not good enough. I want emhttp to be calling a stock (bare minimum) '/etc/rc.d/rc.custom' script which does just that.
May 16, 201016 yr The approach I envisioned was that /etc/rc.d/rc.custom would have the control logic to iterate through the /etc/rc.d/unraid.d/rc.* scripts. Once the control logic is in place and worked out, not many people will ever modify it at all. This also allows for package creators to modify their individual /etc/rc.d/unraid.d/rc.* scripts to their hearts content without conflicts or negative effects to the other addon packages. EEEEXACTLY!
May 17, 201016 yr So, we are saying exactly the same thing! Yes... What then were you strongly arguing against?I was strongly arguing against emhttp invoking directly each of the scripts it finds in /etc/rc.d/unraid.d. If it did, we would not be able to control the order in which actions occur or potentially perform actions common to all. That is what you initially said was your "best" choice:Or, (best): * Invoke each (if any) rc.* script found in the /etc/rc.d/unraid.d/ directory with a start or stop argument. If you "envision" that you will be the one providing/modifying the '/etc/rc.d/rc.custom' script, that's not good enough. I expect I'll be involved in its creation, but I'm sure there will be many who will contribute. It should be the best of all the ideas, taking into account all the needs. You are certainly welcome to participate. I know I don't know it all. I had written a prototype version that I've had running on my sever for many weeks now. I wrote it to run the rc.add-on scripts serially, but to continue with the next in parallel after 30 seconds. This was after one member thought we should not overtax the CPU with all in parallel. I've since adjusted the timer to up to 10 seconds of exclusive time. I think a compromise will eventually be the answer, with a limit on the number of concurrent tasks. That would be a simple change to what I initially wrote. As I said, no matter what we do, it will evolve. It may be that a config file can limit the number of concurrent tasks. I had posted my initial script, but nobody ... and I mean nobody offered any feedback. I want emhttp to be calling a stock (bare minimum) '/etc/rc.d/rc.custom' script which does just that. We will all discuss what a "bare minimum" script must do.... and what is must NOT do. It should invoke all the rc.* scripts in /etc/rc.d/unraid.d It should only invoke valid /etc/rc.d/unraid.d/rc.* scripts. It should not prevent the server itself from either starting or stopping. It should not get hung up on any single rc.* script... In other words, it must always return, even if a rc.* script hangs waiting for an event that never occurs. A script that does all that is here. It is a starting point. It can be put into place if you have the two triggers we are requesting. (pre-stop-array, and post-start-array) I have those two triggers on my server, provided by yet another script I wrote. I learned what was needed, and what worked, and what failed. Currently it is starting and stopping cache_dirs, spinup_when_accessed.sh, and enabling and disabling my extra swap-file. (I have three rc.* scripts in /etc/rc.d/unraid.d) I am happy to share my work as a starting point. It follows. Here is a fully a functional rc.custom. Does it have everything we need? Who knows??? but you are welcome to use it as a starting point for your contributions. I know you have a lot of lunix knowledge... How's your scripting skills? # Invoke /etc/rc.d/unraid.d/rc.* scripts to start and stop processes. # # To be invoked (some day) by emhttp as rc.custom "start" after starting the unRAID array # and as rc.custom "stop" prior to stopping the array. # # May 2010, Joe L. program_name="rc.custom" # each script gets this as much as this exclusive time, then it is run in parallel with the next. # There is no minimum time allotted to a script. If they all finish in a single second, that is perfectly fine too. timeout=10 #stderr_output="-s" stderr_output="" function addon_processes() { # start or stop add-on processes via their rc.* scripts. # this function expects one argument, either "start" or "stop" case $1 in start) txt="Starting" etxt="Started" ;; stop ) txt="Stopping" etxt="Stopped" ;; esac echo "`date` $txt ADD-ON processes" | logger $stderr_output -t$program_name if [ -d /etc/rc.d/unraid.d ] then rc_num=0 for rc_script in /etc/rc.d/unraid.d/rc.* do let rc_num+=1 # make sure the unraid.d script has the "start" or "stop" keyword somewhere in it. grep "\W*${1}\W" $rc_script >/dev/null 2>&1 if [ "$?" = "0" ] then if [ -x $rc_script ] then # spawn timing sub-shell. parent_pid=$$ echo "$txt $rc_script timer parent PID = $parent_pid" | logger $stderr_output -t$program_name # Create a semaphore file for the sleep process so we can terminate it early if needed. touch /var/lock/unraid_addon_rc${rc_num}.LCK ( timer=$timeout while test -f /var/lock/unraid_addon_rc${rc_num}.LCK do sleep 1 let timer-=1 if [ $timer -lt 0 ] then echo "timed out $parent_pid continuing..." | logger $stderr_output -t$0 [ -f /var/lock/unraid_addon_rc${rc_num}.LCK ] && rm -f /var/lock/unraid_addon_rc${rc_num}.LCK break fi done ) & rc_timer_pid=$! echo "$etxt $rc_script timer PID = $rc_timer_pid" | logger $stderr_output -t$program_name echo "$txt $rc_script ${1}" | logger $stderr_output -t$program_name # The rc.* script is invoked here in the background. We'll wait up to 30 seconds before invoking the # next rc.* script. They can take as long as they like. (although on shutdown they will be terminated eventually) ( cd /; $rc_script ${1} 2>&1 | logger $stderr_output -t$program_name ) & rc_script_pid=$! echo "$etxt $rc_script ${1}, PID = $rc_script_pid" | logger $stderr_output -t$program_name #this will wait for either the rc.* script to finish OR the timeout interval, whichever comes sooner # this way, we never will wait here forever if the rc.* script hangs. The rc_timer will let us continue while true do sleep 1 # If the rc script is completed, break out of this loop kill -0 $rc_script_pid 2>/dev/null || break # If the timer shell still exists, continue in this loop kill -0 $rc_timer_pid 2>/dev/null && continue # to get here the rc process must still be running and the timer shell has timed out. # go on to the invoke next rc.* script. Leave the prior rc.* running in the background. break; done # if the rc.* process finishes first, kill the timing subshell by removing the semaphore lockfile [ -f /var/lock/unraid_addon_rc${rc_num}.LCK ] && rm /var/lock/unraid_addon_rc${rc_num}.LCK else echo "warning: $rc_script \"${1}\" skipped. it is not execuitable." | logger $stderr_output -t$program_name fi else echo "warning: $rc_script \"${1}\" skipped. It does not contain a \"$1\" keyword." | logger $stderr_output -t$program_name fi done echo "rc ${1} processing completed" | logger $stderr_output -t$program_name else echo "Sorry, /etc/rc.d/unraid.d directory does not exist" | logger $stderr_output -t$program_name fi } case $1 in start) addon_processes "start" ;; stop) addon_processes "stop" ;; *) echo "Invalid Option: " $1 ;; esac exit
May 17, 201016 yr unRAID should only execute one script for up/down... just like the go script. If you want to execute every script in some directory, then you can call a script that does that from the single unRAID up/down script.
May 17, 201016 yr unRAID should only execute one script for up/down... just like the go script. If you want to execute every script in some directory, then you can call a script that does that from the single unRAID up/down script. And that is exactly how the script in my prior post works. It could be that single script emhttp calls. Again, it is a working starting point. I've been using a version of it for weeks. Feedback and ideas are welcome. Joe L.
Archived
This topic is now archived and is closed to further replies.