I've recently started setting up my unRAID server and first let me say that I'm really very impressed with the whole system.

 

I was first introduced to unRAID by the lead Plex developer Elan, he told me how you guys had encouraged them to create a Slackware port for you, and how he thought the solution was a very elegant solution to the need for massive media storage... I just had to try it out for myself.

 

Clearly I had a desire to install Plex, so that kind of forced me to go for 5.0 beta. I've had no problems with it at all so far, and spent some time reading the forums, the wiki, playing with a development system knocked up from all componets, and a virtual machine system before I finally took the plunge, bought the components and started migrating my media over.

 

I'm not a complete noob when it comes to the command line, and would like as minimal a system as possible. I don't really want to have two web UIs running just so that I can add packages (my understanding of unMENU), so started adding packages to the bzroot image using cpioi as described in this very old post from 2007: http://lime-technology.com/forum/index.php?topic=871.0

 

So far I've done the following modifications to my bzroot, and everything is running perfectly, with no noticeable increase in boot time because no packages are being installed at every single boot.

 

• openssl-0.9.8r-i486-3.txz
  
• openssh-5.8p1-i486-1.txz
  
• screen-4.0.3-i486-1.txz
  
• utemper-1.1.4-i486-1.txz
  

 

I've also made the following modifications to the image which make sure the boot works well, and there are no errors.

 

• Copied /etc/ssh to the new build after generating keys the first time
  
• Added preclear_disk.sh to /bin directory
  
• Commented out the Telnet line in inetd.conf, as I'm now using ssh instead
  
• Added a .screenrc to the /root directory with some minor customisations
  
• created the /var/log/lastlog file to prevent sshd errors in the log
  

 

Now I've got the basics installed and working well, I'd like to start by adding some programs, in particular Plex and Squeezebox Server.

 

I'm able to get both of these applications running well, but found that having programs running on disks in the array, or the cache drive can really play havoc with the unRAID web UI's controls for starting and stopping the array.

 

Most often, if a process is locking an unRAID mount, it will just keep trying to unmount it. Sometimes though, it will just seem to put the web UI into a state where the stop button seems to do nothing at all. Without the array being stopped, the power down button never appears, so I have to shut things down from the command line and reboot. Often this is not a clean reboot, and starts off a several hour re-check of the parity... something I really don't want to have to do.

 

What I'd like to know is...

 

What is the best way to start and stop processes running on an array disk or cache disk?

Is there a way to 'hijack' the start and stop array commands in emhttp, and if so, what should I edit to include scripts to start/stop any applications that I want to run?

With unRAID v5.0, what is the process for creating Plugins, and what is the process for starting and stopping things here?

 

I've seen that there are quite a few new users to unRAID as a result of the Plex announcement, and not a lot of information to help them out once they get here. I know that there is a page on the Wiki and several posts about Plex on unRAID, but even if you follow all of the steps I've found, there isn't any solution to the problems I describe above.

 

Thanks in advance for any help you can give.

 

Neil.

I've never modified the bzroot image, but to install packages, you can just drop the .tar.gz files into an "extra" directory on the root of your flash drive. Also, I have openssh/openssl setup, using private/public key authentication, and just modified the openssh script to copy over the files to the /etc/ssh and /home directories in the "go" script.

 

Just assume it's a better idea to keep the bz* files untouched, as I'd just be afraid of borking something, but it's not a bad idea--didn't know that was possible.

 

In regards to your question, the "HUP" signal passed to "kill" can be used to stop and start a process.

 

http://www.comptechdoc.org/os/linux/usersguide/linux_ugprocesses.html

 

 

Basics of event handling are discussed here:

http://lime-technology.com/forum/index.php?topic=7101.0

 

The triggers are apparently in place in the later 5.0beta series.  We've all been waiting for some stability in package management before proceeding.  The simplest approach is described in that thread with a pair of "find -exec" commands to invoke the start/stop commands of add-ons.

 

Here is an example of one script I was playing with at the time of the "event handling" discussion.

It was based on having an /etc/emhttp/{eventname}.d/ directory structure, and in that directory having individual executable scripts to invoke for that event.   Again, this was a while ago when the thread on event handling was active.

 

So, to use it, invoke the following from the existing event handling script and put your own executable scripts in

/etc/emhttp/started.d/plex.rc

/etc/emhttp/stopping_svcs.d/plex.rc

 

 

My example event handler is in turn invoked from /usr/local/sbin/emhttp_event.  Currently "/usr/local/sbin/emhttp_event" is invoked with the event name as its first argument. Today, all the "event" stub does is to log the fact that it was called to the syslog

 

This test script I was working with does not block on any given event, but invokes the individual events for each add-on giving each time to run before going onward to the next.  Therefore, when stopping services emhttp will be able to loop until all disks are able to be un-mounted and then continue on its own.  There are no additional time delays involved.

 

A potential "event" handling script... To invoke the assorted scripts found in /etc/emhttp/{eventname}.d/*

 

Just to give you some ideas...  (this script is not completely functional)

 

Joe L.

# manage add-on processes via their rc.* style scripts found in the "emhttp/{eventname}.d" sub-directories.
# this function expects one or more arguments.  The first is the "event" (start, stop etc).
# Remaining arguments are optional and will be passed on to {eventname}/* scripts
# It is expected that this script will be invoked by emhttp as its main event handler.
# Only those scripts that are executable will be invoked.
# This script will always return to emhttp.  It may have child processes running in the background when it returns.
# each script is run in lexical sequence for any given event.  If a given script takes longer than $hang_timeout
# to run, the next will be run in parallel.

event_dir=/etc/emhttp
lock_dir=/var/lock
hang_timeout=5
program_name=`basename $0`
echo $program_name $1 | logger -tunRAIDevent.sh

# uncomment the following line if you wish to see the logging output.
#stderr_output="-s"

# the event directory is named by the "event" being processed.
if [ ! -d "${event_dir}"/"${1}".d ]
then
   echo "Sorry, "${event_dir}"/"${1}".d directory does not exist" | logger $stderr_output -t$program_name
   exit 1
fi
rc_num=0
for rc_script in "${event_dir}"/"$1".d/*
do
   # If not a regular file continue
   test ! -f $rc_script && continue
   # If not a execuitable, continue
   test ! -x $rc_script && continue

   let rc_num+=1
   # spawn timing sub-shell.

   # Create a semaphore file for the watchdog "hung process" timer.
   touch "${lock_dir}/unraid_event_rc_timeout${rc_num}.LCK"
   (
     hang_timer=$hang_timeout
     trap 0
     while test -f "${lock_dir}/unraid_event_rc_timeout${rc_num}.LCK"
     do
       sleep 1
       let timer-=1
       if [ $timer -lt 0 ]
       then
         echo "rc event task \"$rc_script\" timed out, continuing..." | logger $stderr_output -t$0
         [ -f "${lock_dir}/unraid_event_rc_timeout${rc_num}.LCK" ] && rm -f "${lock_dir}/unraid_event_rc_timeout${rc_num}.LCK"
         break
       fi
     done
   ) &
   rc_timer_pid=$!
   # Create a semaphore file for the concurrency process.
   touch "${lock_dir}/unraid_event_rc${rc_num}.LCK"
   (
     timer=$timeout
     trap 0
     while test -f "${lock_dir}/unraid_event_rc${rc_num}.LCK"
     do
       sleep 1
       let timer-=1
       if [ $timer -lt 0 ]
       then
         echo "rc event task \"$rc_script\" timed out, continuing..." | logger $stderr_output -t$0
         [ -f "${lock_dir}/unraid_event_rc${rc_num}.LCK" ] && rm -f "${lock_dir}/unraid_event_rc${rc_num}.LCK"
         break
       fi
     done
   ) &
   rc_timer_pid=$!

   # The "event.d/*" script is invoked here in the background.  We'll wait up to $hang_timeout seconds before invoking the
   # next "event.d/*" script.  They can take as long as they like. (although on shutdown they will be terminated eventually)
   # It will be the responsibility of the event/* script to perform the termination task after a suitable delay on shutdown.
   # We need to invoke a sub-shell to "cd" to / so the rc.* script does not keep a disk busy.
   ( shift; cd /; $rc_script $* 2>&1 | logger $stderr_output -t$program_name ) &
   rc_script_pid=$!

   #this will wait for either the event.d/* script to finish OR the timeout interval, whichever comes sooner
   # this way, we never will wait here forever if the event/* script hangs.  The rc_timer will let us continue
   while true
   do
     # If the rc script is completed, break out of this loop
     kill -0 $rc_script_pid 2>/dev/null || break

     sleep 0.1
     # 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 "${lock_dir}/unraid_event_rc${rc_num}.LCK" ] && rm "${lock_dir}/unraid_event_rc${rc_num}.LCK"
done
echo "event.d/* ${1} processing completed" | logger $stderr_output -t$program_name