bonienl

Your explanation is right. A system plugin gets installed before a user plugin. This becomes important when a dependency exists and certain plugins (e.g. Dynamix webGui) need to be installed first to create the correct foundation for other plugins to operate. Other than that there are no differences between both in terms of execution or privileges.

First I like to propose a simplification in the "plugin" installer script and *not* store any -stale- plugins, just forget/ignore older plugin versions. I think that is less confusing for the end-user. Next, I would like to make a feature request to the "plugin" manager which allows plugins to be installed as "system plugin", meaning they get installed in the directory '/boot/plugins' instead of '/boot/config/plugins'. To make this work an additional attribute can be introduced, see example below <?xml version='1.0' standalone='yes'?> <!DOCTYPE PLUGIN [ <!ENTITY name "webGui"> <!ENTITY author "Bergware"> <!ENTITY version "3.0.0"> <!ENTITY category "Core Functionality"> <!ENTITY pluginURL "https://raw.github.com/..."> ]> <PLUGIN name="&name;" author="&author;" version="&version;" category="&category;" pluginURL="&pluginURL;" system="true"> The new attribute 'system' defaults to 'false' but can be set to 'true' to have the plugin installation changed. This requires an update to the "plugin" installer script, for example: // register successful install // absence of "configfile" attribute indicates normal plugin; presence indicates a VM plugin $configfile = plugin("configfile", $plugin_file, $error); if ($configfile === false) { // Bergware change: add user or system plugin selection $system = plugin("system", $plugin_file, $error); $target = $system === false ? "/boot/config/plugins/$plugin" : "/boot/plugins/$plugin"; if ($target != $plugin_file) copy($plugin_file, $target); symlink($target, "/var/log/plugins/$plugin");

With the current large sized hard disks it is almost obligatory to do a pre-clear, having your array unprotected for an extended period of time when adding or changing disks, simply isn't acceptable.

Thanks RobJ for creating this. I have updated the OP. It is also possible to get PERL installed using the system-temp plugin file. People need to edit the PLG file and change the wording "no-install" into "do-install" at the appropriate line, you may want to add this installation possibility.

True, but any array related activities should be started/stopped based on the event system which exists now. Modifying the go file programmably is not very flexible, the better way is to use the plugin system.

It looks like you don't have any modules/probes installed at all, which are required for your hardware. You can run sensors-detect, but this requires installation of the perl package to make it run (see inside the PLG file).

Whatever webGui is chosen, it all comes down whether emhttp stays alive or not ...

I am not using sensors.conf myself, but could it be simply a syntax issue? Did you try using quotes or double-quotes ? The unix style of escaping a space is to proceed it with a slash '\' character, maybe that works ?

When you do the sensors command from a telnet session, do you see the modified names ?

Renaming is done using the sensors.conf file, perhaps you can post what you have tried so far.

For the moment I stick to the lm-sensors approach, but keep this open for future enhancement.

It would be great indeed if past experiences/solutions can be brought in this topic, it will surely make it easier for others in their 'quest'. Thanks

I also like to mention that people who have created their own sensors.conf file, that this file needs to be stored in /boot/config/plugins/dynamix, this way it will be re-installed upon a system reboot. In this case step 10 from the wiki is not needed.

I like to make a separate topic for the Dynamix system temp plugin and not 'pollute' the webGui discussion, after all system temp is an optional plugin which can be added. I would advice people to look first at the wiki. This is a general guide which can be used as well for people having SimpleFeatures or Dynamix installed (thanks RobJ). The main thing to remember is that the correct labels are used by lm-sensors. The system temp script looks for: CPU Temp - This is the processor temperature MB Temp - This is the motherboard temperature Any questions or solutions can be placed in this topic, this way it stays grouped together and may benefit others.

http://www.highcharts.com/ I actually meant the script which you created to do the measurements and turn it into a graph. I see you have made available "diskspeed.sh v1.0" this is what I was looking for. Thanks. Ps. Been using "highcharts" quite extensively for the "Stats" page (both under SimpleFeatures and Dynamix), it is a very nice tool to generate graphs.

It's amazing the improvements you get when you take out older & slower drives I'm putting the finishing touches on a new script that'll benchmark all drives in the UNRAID system (with graph!) so you can identify any bottlenecks. I like your graphing tool, is it available to the public ?

That are very decent speeds you are getting there ...

Yes you do Simply give the name "Music", cache_dirs knows it is under /mnt/user...

It is a common thing for Linux to take most of your memory for caching purposes. This is dynamically released when needed by applications. No need to worry, you have plenty of free memory available.

So what systems are accessing your server? Likely something is trying to retrieve more than just the directory listing...

You have more than enough free memory... It could be that something is trying to read more than just your directory content (windows explorer is notorious in that respect)...

Thanks Bagpuss I will take your modifications for an upcoming version of SF. Not the next version which is about to be released, but expect it to be included afterwards! Very useful additions!

If something in the background causes continues traffic exchange then there will be never a silence (no activity) period, and hence your system won't go to sleep. In that case don't use the TCP inactivity condition or find out what is causing this continuous traffic and change its behaviour.

You really should leave that value to "0.00". Changing it to "some" value means the monitor needs to see *exactly* that amount of bytes in the measured period to stop. This is very unlikely to happen. The intend is to observe no tcp activity, the value 0 means nothing has been exchanged in that period. Btw there is an updated version of the sleep package, it now also contains the bwm-ng program. See "SimpleFeatures".

Cache_dirs is a very valuable extension. Anyone who don't want needless disk spin ups due to directory reading should use this. In fact there is already an add-on as part of SimpleFeatures which gives a graphical interface to the cache_dirs settings. You may want to continue your development for anyone running the stock interface though Below a screenshot.