It might be time for some clean-up, as I now have both /boot/plugins/  and  /boot/config/plugins/

 

Here is what I'm running and where they are located:

 

SimpleFeatures 1.0.5  /boot/plugins/

Plex - PlexMediaServer-0.9.6.9.241-da3068c-unRAID.txz  /boot/extra/

APC - Apcupsd-3.14.10-i468-2atv.plg  /boot/config/plugins/

iStat - istatd-0.5.8-noarch-1.1aj.plg  /boot/config/plugins/

Samba 3.6.8 - samba-3.6.8-i486-1.txz  /boot/custom

 

Go file:

#!/bin/bash

# Start the new Samba

installpkg /boot/custom/samba-3.6.8-i486-1.txz

# Start the Management Utility

/usr/local/sbin/emhttp &

sed -i '/Scheduled Parity Check/d' /var/spool/cron/crontabs/root

sed -i '/cron=\"\"/d' /var/spool/cron/crontabs/root

 

1.  Where is th recommended location for *.txz files?  I'm using "extra" for the Plex and "custom" for the Samba.

2.  Should I put all *.plg files in the /boot/plugins/ directory - or keep the SF files in there and leave the other two plugins in the /boot/config/plugins/

 

My go files is short, so I think it's ok - meaning it only contains what's needed and not missing anything.

 

Thanks!

I've deleted all traces of my prior install.

 

I placed the .plg files in \boot\plugins

 

I restarted...  And then...  Nothing.

 

I installed the plugins by executing the following for each:

 

installplg simpleFeatures.core.webGUI-1.0.5-noarch-1.plg

 

And now simpleFeatures is running for me.

 

It seems that these plg files are not executing properly at startup.  Investigating my syslog I found the following:

 

Sep 29 11:01:03 UNRAID logger: installing plugin: simpleFeatures.active.streams-1.0.5-noarch-1
Sep 29 11:01:03 UNRAID logger:  file /boot/config/plugins/simpleFeatures/simpleFeatures.active.streams-1.0.5-i486-1.tgz: downloading from http://unraid-simplefeatures.googlecode.com/files/simpleFeatures.active.streams-1.0.5-i486-1.tgz ... bad download, deleting
Sep 29 11:01:03 UNRAID logger: installing plugin: simpleFeatures.activity.monitor-1.0.5-noarch-1
Sep 29 11:01:03 UNRAID logger:  file /boot/config/plugins/simpleFeatures/simpleFeatures.activity.monitor-1.0.5-i486-1.tgz: downloading from http://unraid-simplefeatures.googlecode.com/files/simpleFeatures.activity.monitor-1.0.5-i486-1.tgz ... bad download, deleting
Sep 29 11:01:03 UNRAID logger: installing plugin: simpleFeatures.core.webGUI-1.0.5-noarch-1
Sep 29 11:01:03 UNRAID logger:  file /boot/config/plugins/simpleFeatures/simpleFeatures.core.webGUI-1.0.5-i486-1.tgz: downloading from http://unraid-simplefeatures.googlecode.com/files/simpleFeatures.core.webGUI-1.0.5-i486-1.tgz ... bad download, deleting
Sep 29 11:01:03 UNRAID logger: installing plugin: simpleFeatures.disk.health-1.0.5-noarch-1
Sep 29 11:01:03 UNRAID logger:  file /boot/config/plugins/simpleFeatures/simpleFeatures.disk.health-1.0.5-i486-1.tgz: downloading from http://unraid-simplefeatures.googlecode.com/files/simpleFeatures.disk.health-1.0.5-i486-1.tgz ... bad download, deleting
Sep 29 11:01:03 UNRAID logger: installing plugin: simpleFeatures.log.viewer-1.0.5-noarch-1
Sep 29 11:01:03 UNRAID logger:  file /boot/config/plugins/simpleFeatures/simpleFeatures.log.viewer-1.0.5-i486-1.tgz: downloading from http://unraid-simplefeatures.googlecode.com/files/simpleFeatures.log.viewer-1.0.5-i486-1.tgz ... bad download, deleting
Sep 29 11:01:03 UNRAID logger: installing plugin: simpleFeatures.system.info-1.0.5-noarch-1
Sep 29 11:01:03 UNRAID logger:  file /boot/config/plugins/simpleFeatures/simpleFeatures.system.info-1.0.5-i486-1.tgz: downloading from http://unraid-simplefeatures.googlecode.com/files/simpleFeatures.system.info-1.0.5-i486-1.tgz ... bad download, deleting
Sep 29 11:01:03 UNRAID logger: installing plugin: simpleFeatures.system.stats-1.0.5-noarch-1
Sep 29 11:01:03 UNRAID logger:  file /boot/config/plugins/simpleFeatures/simpleFeatures.system.stats-1.0.5-i486-1.tgz: downloading from http://unraid-simplefeatures.googlecode.com/files/simpleFeatures.system.stats-1.0.5-i486-1.tgz ... bad download, deleting
Sep 29 11:01:03 UNRAID logger: installing plugin: *
Sep 29 11:01:03 UNRAID logger: 
Sep 29 11:01:03 UNRAID logger: Warning: simplexml_load_file(): I/O warning : failed to load external entity "/boot/config/plugins/*.plg" in /usr/local/sbin/installplg on line 13
Sep 29 11:01:03 UNRAID logger:  xml parse error

 

I am receiving the same error as joeshmoe1...  "bad download, deleting".  The last two lines of may give a clue.  It seems the download is failing, but ONLY at startup, and then the install can not complete.

To clarify one thing, the *.plg files need to be placed in: /boot/config/plugins

To clarify one thing, the *.plg files need to be placed in: /boot/config/plugins

 

I had them working in /boot/config/plugins and moved them to /boot/plugins and they also work perfectly there as well.

I prefer /boot/plugins because it is on the same level (folders) as /boot/custom and /boot/packages and /boot/extra.

 

 

Below the design specifications as given by Limetech:

 

General plugin file locations:

  /boot/plugins/              # directory for system plugins (updated with new releases)

  /boot/config/plugins/        # directory for user plugins

  /boot/packages/              # downloaded slackware packages

 

Putting the SimpleFeatures *.plg files in /boot/plugins will not work, settings won't be saved and after a reboot files are not found.

 

 

Putting the SimpleFeatures *.plg files in /boot/plugins will not work, settings won't be saved and after a reboot files are not found.

 

as stated above, my *.plg files are in /boot/plugins/ and work just fine...after a reboot, all settings are there, saved just fine.  Email Notifiy and Parity check are the main settings I'm checking.

 

What settings are not saved for you?

 

Apologies everyone. Bonienl is correct, please save plugins inside the /boot/config/plugins folder.

Apologies everyone. Bonienl is correct, please save plugins inside the /boot/config/plugins folder.

 

Ok, I can move mine, but why do they work in the /boot/plugins/ folder?  Is this a housekeeping suggestion, as mine are working fine where they are??

Correct, there is a technical reason why they shouldn't work in /boot/plugins. The installer looks in those directories at different times during the boot process, but it'll install them all the same.

Ok, thanks.  I'll move mine to /boot/config/plugins/ and reboot...

 

Update:  worked just fine, all my stuff loaded without any issues.  All my settings are still there too. 

 

 

Putting the SimpleFeatures *.plg files in /boot/plugins will not work, settings won't be saved and after a reboot files are not found.

 

as stated above, my *.plg files are in /boot/plugins/ and work just fine...after a reboot, all settings are there, saved just fine.  Email Notifiy and Parity check are the main settings I'm checking.

 

What settings are not saved for you?

 

All settings of SimpleFeatures are copied to "/boot/config/plugins/simpleFeatures/simpleFeatures.cfg"

 

If the above directory+file does not exist then saving the settings will fail, and get lost upon a reboot.

 

It is true though that SF can work when placed in "/boot/plugins" but it is not designed for that and 100% correct operation can't be guaranteed.

 

 

Does SF use the /boot/config/email/ folder at all for the email notifications?  OR was that left over from my old unmenu email notification stuff?  If left over, then I should be able to delete the folder and files within.  The files in there are ssmtp_config.conf, ssmtp_revaliases.conf, and unraid_notify.cfg

 

My SF email notification is working fine.

 

Also, while trying to clean things up a bit (see the plugins I'm using in my Sig), I noticed the following in my /boot/packages/  folder (see attached picture)

 

Given I do run the APC and iStat plugins, I assume the plugin files are downloading the other stuff into my packages folder, like Powerdown, zlib, and cxxlibs.  Or, those could be left over from my old setup (which my friend helped me setup).  Bottom line, is any of that stuff old and can be safely deleted?

The folder "/boot/config/email/" can be safely removed, it is not used anymore in SF-1.0.5

 

SF-1.0.5 does not install anything in "/boot/packages". Unused files in this folder you can remove too.

 

 

Use the new APC UPSD plugin. The previous plugin caused strange behaviour with syslog.

 

Hm. What do you mean by "new"? The latest version seems to be 3.4.10 from 2011.

 

I didn't see an answer to this, is there a new version?

Use the new APC UPSD plugin. The previous plugin caused strange behaviour with syslog.

 

Hm. What do you mean by "new"? The latest version seems to be 3.4.10 from 2011.

 

I didn't see an answer to this, is there a new version?

 

It appears the new version has some issues, so unfortunately not right now.

Okay, no problem.  the version linked to seems to be working fine for me, I was just curious.

 

I just wiped all the stuff from the old version, using bonienl's instructions a couple pages back, then copied all the new plugin files to the /boot/config/plugins folder, then ran each of them manually (installplg...), and they all reported successful installations, and simplefeatures seems to be working fine. 

 

However, when I try to turn on dir caching, it keeps reverting to disabled.  I can't seem to turn it on.  i did not reboot unRAID, since it's being used currently.  I'm also still running 5.0-rc6-r8168-test2.

 

Any ideas why I can't get cache dir to work?  do I need to upgrade or reboot, or did the plugin not install correctly maybe?

Below the design specifications as given by Limetech:

 

General plugin file locations:

  /boot/plugins/              # directory for system plugins (updated with new releases)

  /boot/config/plugins/        # directory for user plugins

  /boot/packages/              # downloaded slackware packages

 

Putting the SimpleFeatures *.plg files in /boot/plugins will not work, settings won't be saved and after a reboot files are not found.

 

Can you define a "system plugin" 

 

So obviously SF is not a system plugin, what about APCUPSD? Screen? OpenSSH?

Just so folks know...

 

UnRaid has had a race condition problem with the plugin feature.  I do not personally think its fixed yet and that is what I believe some of us are running into and why we have run the installer manually.  If the network has not yet finished initialization by the time the install runs the installs fail.  That's why it works when you run it manually (i.e. by then everything is up).

 

I have a Supermicro board and I use DHCP to hand out addresses (even "static" ones) - it's just easier that way, and I think this slows my network initialization enough that the plugin installer always fails on boot. 

 

Hope this helps someone.

UnRaid has had a race condition problem with the plugin feature.  I do not personally think its fixed yet and that is what I believe some of us are running into and why we have run the installer manually.  If the network has not yet finished initialization by the time the install runs the installs fail.  That's why it works when you run it manually (i.e. by then everything is up).

 

This is what I saw as well.  Installed all the new packages, rebooted and most failed because the Server hadnt finished setting up the network.  I then ran them all manually and it worked fine.

 

I'm not sure what will happen at the next reboot.

I still hold the opinion that unraid should wait until the OS is completely loaded and array is online before installing plug-ins... It would fix a lot of these race issues. Some of the things plug-ins need to do when running/installing is very dependant on certain things being initialized already, and every system starts quicker/slower than another. I have two identical systems that run the exact same things(openelec) and both initialize differently.

*Deleted - Wrong thread

I still hold the opinion that unraid should wait until the OS is completely loaded and array is online before installing plug-ins... It would fix a lot of these race issues. Some of the things plug-ins need to do when running/installing is very dependant on certain things being initialized already, and every system starts quicker/slower than another. I have two identical systems that run the exact same things(openelec) and both initialize differently.

So the thing to do would be to write a meta- plug-in that handles the timing and event notification, and can issue start and stop commands. Wait, that's what we've been asking Tom to provide for a couple years now. Given the history of things, I'd say it might be a good idea to go ahead and write one up that we can use while we wait.

Below the design specifications as given by Limetech:

 

General plugin file locations:

  /boot/plugins/              # directory for system plugins (updated with new releases)

  /boot/config/plugins/        # directory for user plugins

  /boot/packages/              # downloaded slackware packages

 

Putting the SimpleFeatures *.plg files in /boot/plugins will not work, settings won't be saved and after a reboot files are not found.

 

Can you define a "system plugin" 

 

So obviously SF is not a system plugin, what about APCUPSD? Screen? OpenSSH?

 

Limetech has provided the "Squeeze Box" plugin which serves as a guide line for designing other plugins. In here the recommendation is given to use "/boot/config/plugins", hence most newer plugins use this location.

 

"/boot/plugins" seems more reserved for system extensions, though it is arguable that SF is such an extension and should be placed there!

 

It is feasible to do, if this is the general consensus...

 

I still hold the opinion that unraid should wait until the OS is completely loaded and array is online before installing plug-ins... It would fix a lot of these race issues. Some of the things plug-ins need to do when running/installing is very dependant on certain things being initialized already, and every system starts quicker/slower than another. I have two identical systems that run the exact same things(openelec) and both initialize differently.

So the thing to do would be to write a meta- plug-in that handles the timing and event notification, and can issue start and stop commands. Wait, that's what we've been asking Tom to provide for a couple years now. Given the history of things, I'd say it might be a good idea to go ahead and write one up that we can use while we wait.

 

It is possible to add timing control in the *.plg file which checks network readiness...

Question from one who is not a operating system programer-- Does the new version of SF (1.0.5) download the actual software and install it everytime that the system starts or reboots?

 

I like to control when my system updates and I don't really want to have a 'just released' software update installed on my running system just because it was shutdown for some reason (perhaps beyond my control). (Plus, I have a test bed to experiment on anyway.)  I won't want to end up in the situation that apparently has surfaced on this version of SF. 

 

As a end user, I would like to have any plug-in system scheme to give the user the option of if-and-when to update.  (I have turned off all of the auto-updates on my Windows machines for just this reason!)