Hi there,

 

I dont have a cache drive, so i want applicatios to be installed and started up when the array is running, so they can put their data in /mnt/usr/app/....

 

So I put installplg and /etc/rc.d/rc... stuff in /boot/config/go for these applications.

 

After booting and starting the array I can see a process "bash /var/tmp/go" running, but the go script is not really running (no applications starting up).

 

When is the "go" script actually run?

Is there a script that is run when the array has been started, so I can put my application stuff there?

 

Thanks for caring,

JC

 

 

Hi there,

 

I dont have a cache drive, so i want applicatios to be installed and started up when the array is running, so they can put their data in /mnt/usr/app/....

 

So I put installplg and /etc/rc.d/rc... stuff in /boot/config/go for these applications.

 

After booting and starting the array I can see a process "bash /var/tmp/go" running, but the go script is not really running (no applications starting up).

 

When is the "go" script actually run?

Is there a script that is run when the array has been started, so I can put my application stuff there?

 

Thanks for caring,

JC

You can INSTALL packages by simply putting them in /boot/config/plugins  (no need to run anything to INSTALL them.  They are installed by an existing script in /etc/rc.d/rc.local    That same script copies /boot/config/go to /var/tmp/go after processing it through fromdos to remove ms-dos carriage-returns.  This allows users to edit the /boot/config/go file using any editor.  (In other words, the /boot/config/go script is never run directly, but a copy of it is run as you discovered)

 

You must START add-on package AFTER the array starts, not before. Also, you  must STOP add-on processes BEFORE the array is stopped, otherwise it will wait nearly an infinite time for them to stop before it will cleanly stop the array.

 

Starting and stopping add-ons is best done by "event" scripts installed by the add-on in the plugin directory hierarchy.  See /usr/local/emhttp_event for more details on where it looks, and how the event scripts need be named.

 

Please ask all further add-on questions in the customizations or plugins sub-forum.  They have nothing to do with the .rc release.

Joe L.

Yo joe,

 

Thanks for your quick response! Ok so far this seems reasonable. The only question I have regarding this is:

 

If I move the plugins to /boot/config/plugin from /boot/config/plugin/manualinstall and I remove the installplg pluginxyz and /etc/rc.d/rc.pluginxyz, will this only work properly if I have a cache drive? I really want most of my plugins to keep permanent state and thus moved their data to /mnt/user/app/pluginxyz. As I understood the Wiki the plugins would be installed and write to /mnt/user/app/... before the array is up and /mnt/user got mounted, thereby blocking the mount of /mnt/user.

 

If that information from the wiki is outdated I will do as described above (as soon as the array isn't busy anymore).

 

Best

JC

 

Plugins are not "cache drive aware" nor is a cache drive required for plugins. Just put the plugins in the /boot/config/plugins/ directory and point the data directory in each plugin's settings to a place on your array. That will save all your configurations to that location on the array. Leave the install directory as /tmp or whatever is the default so the program itself is running from RAM and not a disk. To put it simply: data dir is where configs are stored, install dir is where the program is installed and runs from on each boot up, and the plugin will tell it to look to the data dir for configurations once its installed. Plugins stored in /boot/config/plugins/ are automatically installed at boot up. Basically, undo everything you did and drop the plugins in /boot/config/plugins/ and then reboot.

 

The reason most people use a cache drive to store their plugin's data directories is because some plugins keep the drive they are installed on spun up all the time, potentially wearing the disk out faster. Because of this I'd suggest you set up a share for your plugins that is only stored on one disk so only that disk will stay spun up.

Hi mrow,

 

thanks for the background info thrown in by you.

 

However, my main question remains still open:

 

On boot, when plugins get installed from /boot/config/plugins, will this happen

 

_before_ or _after_

 

the array has been started, i.e. /mnt/user has been mounted.

 

If it happens before mounting of /mnt/user, it would be no good...

 

Thanks for caring,

JC

The Go script runs before the array is mounted, what script are you trying to run

Hi Marsh

thanks for you reply but it doesn't answer the question:

 

Are plugins installed from /boot/config/plugins

_before_ or _after_ the array is up and /mnt/user is available.

 

When will the plugins create data on their own? If that happens before /usr/mnt is up I will have a problem..

 

TFC

JC

 

According to Limetech plugins are installed before go so if go runs before the array then so do the plugins

Hi Marsh

thanks for you reply but it doesn't answer the question:

 

Are plugins installed from /boot/config/plugins

_before_ or _after_ the array is up and /mnt/user is available.

Definitely, before.  First any .tgz or .txz packages (not plugins, but packages) in /boot/extra are installed in lexical order

Then, plugin files in lexical order are installed from /boot/plugins

Then plugin files in lxical order are installed from /boot/config/plugins

Then /boot/config/go is invoked (and within it the emhttp process started)

  Then emhttp starts the array

  Then emhttp starts the process of mounting the drives on the mount points.  (typically, this takes a few seconds, but can take as long as an hour if a large disk, and lots of prior file activity was in its journal, and the array was not cleanly stopped)  Plugins should be coded to deal with the missing share... It will eventually happen, and if not coded properly, the array will not start (or files written to RAM instead of the share) if the share is accessed prior to it being available.

  Then emhttp starts the user-shares.

  Then emhttp starts network services advertising available shared drives

  Then emhttp invokes the "svcs_restarted" event in /usr/local/sbin/emhttp_events  It in turn invokes plugin "event named" scripts. (here is where you should be starting add-ons)

  Then the remainder of the config/go script is invoked (and the line appended to its end by unMENU  to find and run *.auto_install scripts from /boot/packages invoked)

 

 

When will the plugins create data on their own? If that happens before /usr/mnt is up I will have a problem..

You are correct.  If an improperly written plugin attempts to access data prior to the array being online and all disks mounted, the array with either not start, or not start properly.  Typically unRAID just stops and no web-interface is presented as it waits (forever) for the plugin process to complete.

 

So far, I know of NO plugin that properly waits while journal entries are replayed after a non-clean shutdown.

 

Joe L.

Thanks for this Joe L.

 

I had seen some of this documented in various places but not all of it and certainly not all of it together in one place.

 

I am sure I will be linking to this post in the future.

Joe thanks a lot for the comprehensive answer!

 

In the meanwhile the problem became irrelevant for me because I went for a Plus license and will have a cache drive within a few days. I will migrate plugin data to the cache drive and that should do the magic.

 

Anyway. Thanks for documenting, it will help all of those who have a Basic license without cache drive and store plugin data on the array.

 

 

To wrap it up my experience after adding a cache drive:

 

I moved all plugins to /boot/config/plugin and removed all installplg and /etc/rc.d/rc... stuff from /boot/config/go. I configure the app share to use the cache drive only. I also configured the array to get started on boot.

 

After booting the array is up and all applications are available. Right as you would expect it to happen.

 

Wonderful!