"SimpleFeatures" Plugin - Version 1.0.11



Recommended Posts

Did you try to unset all conditions except wait for network inactivity?

 

The above would trigger a sleep action after no users are actively using the DB anymore (you may need to experiment with the network interval to find an optimum).

Great idea. Will try it immediately. I had to enter zeros otherwise the default settings are being restored. I guess that this is fine?

Link to comment
  • Replies 2.8k
  • Created
  • Last Reply

Top Posters In This Topic

Did you try to unset all conditions except wait for network inactivity?

 

The above would trigger a sleep action after no users are actively using the DB anymore (you may need to experiment with the network interval to find an optimum).

Great idea. Will try it immediately. I had to enter zeros otherwise the default settings are being restored. I guess that this is fine?

Indeed empty values will restore the defaults. A value of 0 should work though (meaning no delay).

Link to comment

Second Item:  On 'Main', the box for "Write Corrections to parity disk" is checked.  I would prefer that (1) it either be unchecked  or (2) have an option on the settings page to determine the status of the check in the box.  Perhaps, a good place for this second option would be on the 'Settings' page under the 'Simple Features' in the "Confirmation' area. 

 

On the 'Settings' page again on the 'Simple Features' tab, there is the 'Scheduler' for the automatic parity check.  The default choice for 'Write corrections to parity disk' is 'Yes'.  I would prefer that it be 'No'.

 

The reason for wanting these box(s) unchecked is that should NOT be any parity errors found during a parity check.  If there is an error, the user should be given an opportunity to check for the cause and correct it.  Correcting parity before the cause has been determined will cause data loss if the error is in the data array (most likely one of the data disks) and not in the parity array (most likely the parity disk).  Until the user has made that determination, an automatic parity check will simply hide a data array error from the user and give a false sense of security that all is well.

The write to parity disk setting is the default setting of unRAID itself - that is the same setting as used under the stock GUI (though the wording has been changed). It is the intended choice of Limetech to have the behaviour like this.  If you don't want to write to the parity disk then uncheck the box before initiating a manual parity check.

 

I wonder if Limetech has never really thought this through.  When a new user (or even an old one) decides to run a parity CHECK I would think that an action which MIGHT cause even further damage to compromised system is enable by default is not the best possible option.  My feeling is that a default action should always be one that will not cause even more problems.  By turning off correcting parity, one can not accidentally cause more damage to the system by starting what appears to a "CHECK". (It is the fine print that says that parity will be corrected.)  Up to that  point, the causal user will think he is starting a parity check!!!

 

 

For the scheduled parity check you can change the setting and it will be stored for future use.

 

What you say is true and I have done changed the option setup.  However, many times, the new user will simply accept the defaults proposed by the software developers as the best possible option.  It is my understanding that the periodic parity check is intended to detect faults in the entire array structure so that further corrective action can then be taken by the user to identify the problem and correct the root cause. 

 

If others feel as I do, please chime in.  Otherwise, I will defer to the implied wishes of the majority.

 

I do really appreciate the efforts of the people who are providing us with a most useful tool to simplify the use of unRAID.  I find that addition of this tool was a very important factor in my decision to make the recent switch from FreeNAS to unRAID!!!

Link to comment

I believe in version 4.7 it was the default NOT to write to the parity disk.

 

I remember some discussions about the topic, problably a search on the forum can tune you in.

 

Limetech made a decision to change the behavior, I guess this is and always will be debatable...

 

Link to comment

I believe in version 4.7 it was the default NOT to write to the parity disk.

 

I remember some discussions about the topic, problably a search on the forum can tune you in.

 

Limetech made a decision to change the behavior, I guess this is and always will be debatable...

 

After reading your response, I did try to find the discussions on the forum but was unsuccessful.  (The search engine on this forum seems to be quite difficult to use as compared to some other forums.)  I can only assumed that it was beat to death and some type of consensus was reached. 

 

Now that I have made myself aware of the issue, I am hoping I will remember to always uncheck the box before doing a parity check.  (But I can't tell you how many times I have to uninstall tool bars that were installed into Firefox because I forgot about looking for the checked "Install the Whatisit toolbar in my browser" box when installing one of the common browser updates!    ::)  ) 

Link to comment

I think its another case of bad/awkward wording. I'm in agreement, parity check says to me it will CHECK for errors, not attempt to correct them. On the other hand I would know a Parity Correction would change my parity and attempt to correct errors.

 

Now, we shouldn't hijack the simple features thread with this discussion, :)

Link to comment

After reading your response, I did try to find the discussions on the forum but was unsuccessful.  (The search engine on this forum seems to be quite difficult to use as compared to some other forums.)  I can only assumed that it was beat to death and some type of consensus was reached. 

 

Make sure you are on the home page before you do a search if you want to search forum-wide otherwise the search function will only search the levels below the one you are currently on.

 

e.g. If you used the search function while you had this thread open then it will only search within this thread.

Link to comment

Another massive update from Bergware. He's on a roll! Some fun and useful features on the way. Thanks for all the feedback everyone!

 

Change Log:

1.0rc2:

 

base-webGUI

- updated jquery scripts to latest versions

- revised names of javascript files

- revised names of css files

- added status indicator on scheduler settings page

- added 'default' button to settings pages

- changed css coding in 'template.css'

- removed legacy file deletion from install script

- fixed default value for parity 'write' setting in install script

- fixed PHP 5.3.10 warnings

- fixed misplacement of parity check duration message

 

active-streams

- updated references to css files

- fixed error when hosts.cfg file does not exist

 

cache-dirs

- added status indicator on folder caching settings page

- added automatic quoting of exclude/include folder names

- added 'default' button to settings page

 

disk-health

- revised names of css files

- added setting for background polling (not mentioned earlier under rc1)

- added 'default' button to settings page

 

email-notify

- changed jquery code optimizations

 

s3-sleep

- added status indicator on sleep settings page

- added new field "Custom commands before sleep"

- added new field "Custom commands after wake-up"

- added 'default' button to settings page

- changed sleep(ing) button to stay enabled while sleeping

- changed selected and available WOL options are now dynamically read

 

stats

- revised names of css files

- added series 'cached' to memory graph

- added 'default' button to settings page

- fixed force disks display (in case of missing setting)

 

system-info

- updated references to css files

 

Due to the nature of the changes it is strongly recommended to update all packages to version v1.0rc2 and reboot the system after installation.

 

Link to comment

I just upgraded to unRAID rc2 and to simple features rc2 then rebooted.

 

When testing email config, I got this error

 

Parse error: syntax error, unexpected T_CASE in /usr/local/emhttp/plugins/simpleFeatures/scripts/Commands.php on line 19

 

which is similar to the only other "Parse error" I got in my search, but references a different line number, and says it's due to no users in the config.  I thought I'd read that this had been fixed, and is a different line number, so I'm reporting it.

 

I'll add a user (Other than Root) now, and try again.

 

**It's not letting me add a user.

 

****My bad, I was trying in the wrong place.  I added one, but there is an IP address I don't know listed there.  Should I be concerned about that??

Link to comment

I've upgraded to unraid rc2 and Simple Feature RC2

 

I'm getting hdparm: sending ioctl 2285 errors every minute or so.  A quick search seems to indicate it's email notification related.  When I try to stop Email Notifications from the SF Settings menu, nothing happens.  I click Stop.  The stop button disappears.  I go back to the Email Notifications settings page and it's still running.

 

How can I stop the notifications and/or stop the hdparm: sending ioctl 2285 log messages ?

Link to comment

I just upgraded to unRAID rc2 and to simple features rc2 then rebooted.

 

When testing email config, I got this error

 

Parse error: syntax error, unexpected T_CASE in /usr/local/emhttp/plugins/simpleFeatures/scripts/Commands.php on line 19

 

My bad (sorry): there is a missing ";" at the end of line 18 in the "commands.php" script.

 

@Speeding_ant: perhaps you want to correct  and re-issue the email package?

Link to comment

So I upgraded simple features and the sleep addon to make use of the new pre and post sleep commands. I placed the following into the post sleep command box:

#Restart sickbeard
sleep 60
echo Restarting SickBeard
wget -q --delete-after http://192.168.0.100:8181/api/my_sb_api_#####/?cmd=sb.restart
sleep 5

This did not seem to work. I can see in the SB logs there was no restart command received. How should I use this new feature properly?

 

I found this in th go script now:

/usr/local/sbin/s3_sleep -a -m10 -t5 -eeth0 -h03 -F -p /usr/local/bin/postRun

When I navigate to /usr/local/bin the directory is empty.

 

EDIT:

I may have fixed it. I went back to the sleep options and clicked apply again. Now I have a postRun file with my commands in it. Strange it was not made the first time I clicked apply.

Link to comment

I may have fixed it. I went back to the sleep options and clicked apply again. Now I have a postRun file with my commands in it. Strange it was not made the first time I clicked apply.

Did you notice the state of the process the first time you tried. Was it running or stopped?

Link to comment

I may have fixed it. I went back to the sleep options and clicked apply again. Now I have a postRun file with my commands in it. Strange it was not made the first time I clicked apply.

Did you notice the state of the process the first time you tried. Was it running or stopped?

I'm not sure what process you mean. But this is what I did.

  • Remove old simple features packages from /boot/extra.
  • Place new packages in /boot/extra.
  • Stop unRaid and restart.
  • login to unRaid webGUI (now simple features).
  • go to sleep setting page and confirm all old settings are still set.
  • Enter new post sleep commands, hit apply.
  • A dialog message briefly appeared at the bottom of the screen. It was too fast for me to read it.
  • Stop unRaid and restart.
  • login to unRaid webGUI (simple features).
  • go to sleep settings page and confirm post commands were there. They were there.

 

At this point I assumed it was fine. But then after the next sleep cycle I noticed SB did not get restarted and I began my investigation process. That is when I initially found that /usr/local/bin was empty.

Link to comment

  • Remove old simple features packages from /boot/extra.
  • Place new packages in /boot/extra.
  • Stop unRaid and restart.
  • login to unRaid webGUI (now simple features).
  • go to sleep setting page and confirm all old settings are still set.
  • Enter new post sleep commands, hit apply.
  • A dialog message briefly appeared at the bottom of the screen. It was too fast for me to read it.
  • Stop unRaid and restart.
  • login to unRaid webGUI (simple features).
  • go to sleep settings page and confirm post commands were there. They were there.

The second time you stop unRaid and restart is not necessary, but it made a flaw in the sleep package apparent.

 

The files postRun and preRun are stored in RAM and not automatically rebuild after a restart. Re-applying the sleep settings as you did, made the construction of the file(s).

 

The settings are all stored in a configuration file on the flash memory, I will need to add the logic to reconstruct the pre/post files from there...

Link to comment
  • Squid locked this topic
Guest
This topic is now closed to further replies.