I'm trying to code something that requires the array to be completely started. Would checking mdcmd for mdState= be sufficient? When does this value get changed? I just don't want to invoke any commands while mdState is equal to "STARTED" if there are still things going on. I need to be sure all shares and disks are mounted. Is there any instance where mdState="STARTED" yet there are still disks or shares left to mount?

Don't take my word for it, but, I believe (I can't test it at the moment) if you start the array and stop the array, mdState is still equal to "started".

 

However, I do believe there is a hook you can hook onto for starting/stopping the array, check my threads, Joe explained it in one about stopping sabnzbd upon array shutting down.

The available "clues" are different depending on the version of unRAID.

 

What version of unRAID are you running?

Is there any instance where mdState="STARTED" yet there are still disks or shares left to mount?

Yes, in fact, many instances. 

i am using the 5.0 rc11. here's what i am trying to do, and i don't even know if it will work: i am continually getting those elusive "transport endpoint not connected" errors. before it was a minor issue and i could always get it up and running, although it was troublesome. now it's constant. i am trying to make a plugin similar to anetwait, that will be the first plugin ran and does nothing but sit and wait for everything in the array to start up before all the other plugins are started. hopefully this will solve my issue. i started by looking at the unraid notify addon to see how it accomplishes it and it uses mdcmd so thats where i started looking. anyone have any suggestions on how to go about this?

Possibly you could check for the existence of a specific file on each disk, and only proceed when all disks can be read?

Possibly you could check for the existence of a specific file on each disk, and only proceed when all disks can be read?

 

i thought about that but it's just not the proper way to do it. i probably wouldnt mind so much for my own personal use but i figured this might come in handy for others and if i'm going to share it i'd rather not make it a hack-job.

Don't take my word for it, but, I believe (I can't test it at the moment) if you start the array and stop the array, mdState is still equal to "started".

 

However, I do believe there is a hook you can hook onto for starting/stopping the array, check my threads, Joe explained it in one about stopping sabnzbd upon array shutting down.

 

i checked before you posted it and it does say STOPPED when stopped. i am familiar with the event based actions for plugins. thats a good idea. that might be something worth looking into.

Possibly you could check for the existence of a specific file on each disk, and only proceed when all disks can be read?

 

i thought about that but it's just not the proper way to do it. i probably wouldnt mind so much for my own personal use but i figured this might come in handy for others and if i'm going to share it i'd rather not make it a hack-job.

Something like this might work:

 

unRAID 5.X will look in "event-named" directories under /usr/local/emhttp/plugins/ for an executable script in a "plugin-name/event" directory and invoke it as it starts services after mounting the disks on array start.

 

As an example, you could have a file:

/usr/local/emhttp/plugins/000_first_addon/event/svcs_restarted

Since the add-ons plugins are invoked in lexical order, one starting with 000 would be invoked first.

 

You can put something like this in your "config/go" script to move a copy of your script to that location each time you reboot.

mkdir -p /usr/local/emhttp/plugins/000_first_addon/event/

cp /boot/wait_for_all_disks_mounted /usr/local/emhttp/plugins/000_first_addon/event/svcs_restarted

chmod +x /usr/local/emhttp/plugins/000_first_addon/event/svcs_restarted

 

The actual plugin name (shown in blue above) does not matter other than do not use directory names with spaces.  You do not need to have a plugin with that name, but it is where the event system looks.  Since the events files are invoked in  the lexical order of the "plugin" directory name, use one that comes lexically before all the others.  (The leading 000 should help here)

 

The actual /boot/wait_for_all_disks_mounted file (copied from /boot to the named event file in the plugins hierarchy) would then have as its contents:

loop_count=0
while [ $loop_count -lt 200 ]; 
do 
    let loop_count=$loop_count+1  
    expected_mounts=$( grep -c fsType /var/local/emhttp/disks.ini )
    actual_mounts=$(mount | grep /dev | wc -l )
    if [ "$actual_mounts" -eq "$expected_mounts" ]
    then
        break
    fi
    echo sleeping $loop_count; 
    echo $actual_mounts of $expected_mounts mounted.
    mount
    sleep 2; 
done

It will sleep several seconds each time through the loop waiting until all the disks are mounted.

 

One warning.  If some day a disk does not mount because of corruption, the entire unRAID startup process will pause and loop for 400 seconds before continuing, even though the expected number of disks did not mount.

 

Have fun.  You now have enough info to cause the array to stop working, as it expects EVERY event file to be perfectly coded and invoke properly.  An infinite loop would cause the array to not start, or stop, and even with the higher speed CPU's these days, the infinite loops still take a realllllllllly long tine.

 

I choose event svcs_restarted instead of disks_mounted as it seemed to be better suited for waiting.  You could alternately use disks_mounted, but it might not have the other needed user-share services in place yet.

Some experimentation might be needed.

Joe L.

thanks a ton Joe. i'll give that a go. one question though. how does unraid handle the go script in comparison to plgs? does it do the go script first? simultaneously as plgs?

thanks a ton Joe. i'll give that a go. one question though. how does unraid handle the go script in comparison to plgs? does it do the go script first? simultaneously as plgs?

The answer to that is in the /etc/rc.d directories.  Specifically /etc/rc.d/rc.local  It is invoked when the unRAID server boots after entering "M" multi-user-mode from "S" single-user-mode.

 

rc.S is invoked first

rc.M is invoked next

and near its end, it invokes rc.local

 

rc.local first installs packages located in /boot/extra (in lexical order)

then rc.local installs all the plugins in /boot/plugins (in lexical order)

then rc.local installs all the plugins in /boot/config/plugins (in lexical order)

then the /boot/config/go script is passed through "fromdos" and copied to /var/tmp/go to remove MS-DOS style carriage returns.

finally /var/tmp/go is invoked.

 

In /var/tmp/go,  emhttp is started.  As part of its sequence, "event" scripts are invoked from the plugins directories by

/usr/local/sbin/emhttp_event

It is invoked the $1 being the name of the event.

 

Basically, emhttp loads the "md"  driver for unRAID, affiliates the assigned drives to their respective slots in the array, mounts the drives, starts the network services and finally invokes the "svcs_restarted" event if present in each of the plugin directories as the last thing it does in bringing the array online.  Actually, a whole series of events are invoked in each of the plugins at various times if they exist (most will not do anything for most events and have no script for the event), but two are really useful to us, the one that say the array has started "svcs_restarted" so we can start out add-on processes, and the one that say the array is gong to be stopped (so we can terminate the add-on processes and services before it does.  That event is "stopping_svcs"

 

The whole sequence is performed one step at a time as far as the plugins are concerned, each waiting for the prior to complete.  About the only thing done in parallel is mounting all the drives to their mount points by emhttp.

 

So, to answer your question...

basically... packages in /boot/extra are installed first

plugins in /boot/plugins are installed next

plugins in /boot/config/plugins are installed next

the "go" script is invoked next

the "events" in plugin scripts are invoked (if present during the start up and shut down processes as various events occur... see /usr/local/sbin/emhttp_event for the details)

 

Joe L.