Hi itimpi,

 

First of all, thanks for the plugin! Happy user for some time now

Having an issue with the 'High disk temperatures can shutdown server' setting.

I can't seem to disable this. After changing to 'Disabled' and hitting 'Apply', the value changes back to 'Enabled'.

Haven't tried the - uninstall - reinstall fix, since you might need some debug logging I am more than happy to supply.

 

Thanks again

1 hour ago, Rendo said:

Hi itimpi,

 

First of all, thanks for the plugin! Happy user for some time now

Having an issue with the 'High disk temperatures can shutdown server' setting.

I can't seem to disable this. After changing to 'Disabled' and hitting 'Apply', the value changes back to 'Enabled'.

Haven't tried the - uninstall - reinstall fix, since you might need some debug logging I am more than happy to supply.

 

Thanks again

I have been able to reproduce this.   Looking at the underlying configuration file it IS being changed despite the settings page saying it is enabled., so this may be just a display issue.  I will need to work out why this is happening and issue a fix.

 

EDIT:  The value in the GUI is (incorrectly) displaying the setting associated with the "Pause and Resume array operations if disks overheat" setting.  I can confirm, however, that changing the setting and hitting Apply DOES change the stored setting.

 

1 hour ago, itimpi said:

I have been able to reproduce this.   Looking at the underlying configuration file it IS being changed despite the settings page saying it is enabled., so this may be just a display issue.  I will need to work out why this is happening and issue a fix.

 

EDIT:  The value in the GUI is (incorrectly) displaying the setting associated with the "Pause and Resume array operations if disks overheat" setting.  I can confirm, however, that changing the setting and hitting Apply DOES change the stored setting.

 

Ah, great, thanks for the quick follow-up!

I'm dealing with a severe slowdown for parity checks/rebuilds on my media unRAID system. It used to run around 80 - 90 MB/sec until I added some new Exos 16TB drives just over a month ago. Since then my parity check/rebuild speed is around 30 MB/sec. I'm in the process of adding 2 more 16TB drives to replace my old 10TB parity drives that I had re-used for the data array. More details are in the following thread.

 

 

@JorgeB has been helping and so far it may be that my HBA and older motherboard/CPU combo are the limiting factors. In any case, I've also seen that there is an update available for the parity check tuning plugin. Right now I haven't upgraded it as I'm not sure it can be done while a parity rebuild is still in process. I'm not using the increment section of the plugin at this time but I see references to the plugin in my syslog with the current rebuild underway.

 

Can I safely update the plugin if the parity rebuild is paused? Or should I wait for the rebuild to finish? Thanks again for your plugin @itimpi.

 

You can safely update the plugin at any point without problems.    
 

The vast majority of the time the plugin is actually inactive and even if you did the upgrade at the exact instance it was going to attempt a pause or resume the worst that could happen would be for that particular pause/resume to not take effect.

 I just updated the parity check plugin and restarted the server and now I am seeing this message in the logs every 15 minutes:

 

Nov 14 14:13:01 NAS crond[1955]: failed parsing crontab for user root: /6 * * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Nov 14 14:27:11 NAS crond[1955]: failed parsing crontab for user root: /6 * * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null

 

There should be a ‘*’ before the /6 - I must have accidentally made a change that removed it.   A temporary workaround will be to disable the temperature related settings.  I’ll get a fixed version out tomorrow after I can check that nothing else seems to  be wrong.

No worries, sounds good!

When updating:

Warning: Use of undefined constant cfgShutdown - assumed 'cfgShutdown' (this will throw an Error in a future version of PHP) in /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php on line 132

 

Thanks -I will need to look into where I am using a variable of that name - looks like there is a missing leading $ on the name.    Hopefully it is in nothing critical such a debug print statement..   I also wonder why it never got flagged up for me - did you do anything specific to get it?

4 minutes ago, itimpi said:

did you do anything specific to get it?

Hit update on the plugin page.  But my system may be flagging PHP warnings

On 11/18/2020 at 8:16 PM, Squid said:

Hit update on the plugin page.  But my system may be flagging PHP warnings

This was fixed (( believe) in the most recent plugin update.  I have configured my test server to flag PHP warnings by adding the following lines to my 'go' file:

logger -tgo "enable showing PHP errors/warnings"
echo "display_errors = on" >> /etc/php/php.ini 

so hopefully in the future I will pick it up such an issue before releasing an update.

I am currently working on the code to allow array operations to be restarted (resumed) from where they were as long as:

• the array was shutdown cleanly
• there have been no changes to the disk configuration. 

 I have 2 use cases in mind:

• Restarting after the system has been rebooted
• Restarting after the array has been stopped/started without a reboot

I would be interested in any feedback on how useful users would find each of the use cases; whether there are any special considerations they can think of for either use case; and also whether there any other use cases I should consider.

On 11/28/2020 at 3:05 AM, itimpi said:

 

• Restarting after the system has been rebooted
• Restarting after the array has been stopped/started without a reboot

 

This is exactly what I am looking for!  I can offer nothing more other than encouragement.

8 hours ago, Transmobius said:

This is exactly what I am looking for!  I can offer nothing more other than encouragement.

Just a caution - it will require you to be running a release more recent than 6.9.0 beta 35 to be able to use this option as it requires a feature that Limetech have only just added for this new capability to be available.  It will not work on currently available releases.

Well I'll probably wait for 6.9.1 before upgrading

On 11/28/2020 at 10:05 AM, itimpi said:

• Restarting after the array has been stopped/started without a reboot

 

It appears that this is not a valid Use Case as it is not (currently anyway) possible to Stop the array with an array operation running.  On thinking about it makes some sense as why would you want to stop/restart the array without a reboot if you were not planning to make a change (which would invalidate a restart of the array operation anyway)  However maybe someone can up with a good reason and if so I may look further into if this can be made to work.

 

On 11/28/2020 at 10:05 AM, itimpi said:

Restarting after the system has been rebooted

I have this Use Case up and running on my test server.   I see the main reason to use it as the scenario where a server is not left powered on 24x7.

 

3 hours ago, itimpi said:

It appears that this is not a valid Use Case as it is not (currently anyway) possible to Stop the array with an array operation running. 

How then do you cleanly shut down in your reboot scenario?

 

I always stop my array before shutting down or rebooting, as I've had many instances where I needed to chase down one thing or another keeping something open and mounted, and I'd rather cleanly close things instead of relying on Unraid to not corrupt files when it forces a shutdown.

46 minutes ago, jonathanm said:

How then do you cleanly shut down in your reboot scenario?

You use the Shutdown or Reboot buttons.    This automatically issues a shutdown command for the array (which my plugin can catch).  At the moment Unraid will not let you stop the array if you have an array operation running - you have to first cancel the array operation before the Stop button is active.  I am not sure if this behaviour can easily be changed in any way.   If it can then the plugin will be able to exploit that but at the moment I have not worked how to change this behaviour although I do intend to continue looking at it.

 

It is worth noting that if the Stop button was going to cleanly stop the array then the Reboot/Shutdown buttons would do so as well as they first issue the same command sequence that pressing the Stop button initiates.   Since the restart can only happen if the array shutdown was a tidy one anything that would stop this being the case would also stop the restart of the array operation from happening.

10 minutes ago, itimpi said:

It is worth noting that if the Stop button was going to cleanly stop the array then the Reboot/Shutdown buttons would do so as well as they first issue the same command sequence that pressing the Stop button initiates.   Since the restart can only happen if the array shutdown was a tidy one anything that would stop this being the case would also stop the restart of the array operation from happening.

Exactly. I regularly have to go in and clean things up to get the array to stop using the Stop button. I would much rather see that the stop is not happening in a timely fashion and go hunt down the culprits than allow Unraid to force things.

1 minute ago, jonathanm said:

Exactly. I regularly have to go in and clean things up to get the array to stop using the Stop button. I would much rather see that the stop is not happening in a timely fashion and go hunt down the culprits than allow Unraid to force things.

If you have to do this anyway why not simply do it before using the Stop or Reboot buttons.  I am not sure how this plugin could help you in such a case as one of the pre-conditions of doing the restart of the array operation is that a clean shutdown of the array has happened.

4 minutes ago, itimpi said:

If you have to do this anyway why not simply do it before using the Stop or Reboot buttons.  I am not sure how this plugin could help you in such a case as one of the pre-conditions of doing the restart of the array operation is that a clean shutdown of the array has happened.

That's the thing, I never know what specifically I am going to need to unmount or shut down, sometimes stop works perfectly, other times it hangs on unmounting disks and I have to SSH in and see what's still open that I need to stop. I can't reliably predict when intervention is needed, so I always look for a cleanly stopped array before I initiate shutdown or reboot.

It looks as if the way to ac

On 12/8/2020 at 1:55 PM, jonathanm said:

That's the thing, I never know what specifically I am going to need to unmount or shut down, sometimes stop works perfectly, other times it hangs on unmounting disks and I have to SSH in and see what's still open that I need to stop. I can't reliably predict when intervention is needed, so I always look for a cleanly stopped array before I initiate shutdown or reboot.

It looks as if the way to achieve what you want will be by using Pause (which re-enables the Stop button) before trying the Stop button.   Would this be an acceptable way of operating for you?   I will need to explain this in the Help text associated with the configuration option I have added to enable users to restart array operations.  

 

This raises another question - if a Paused array operation is later restarted should it automatically be put back into a Paused State as part of the restart process?   This would mean the user having to use the Resume button in such a case to continue with completing the operation.    I feel that might be a good idea but welcome feedback but I am not sure.    It could also be made a plugin configuration item depending on the feedback I get.

1 minute ago, itimpi said:

It looks as if the way to achieve what you want will be by using Pause (which re-enables the Stop button) before trying the Stop button.   Would this be an acceptable way of operating for you?   I will need to explain this in the Help text associated with the configuration option I have added to enable users to restart array operations.  

 

This raises another question - if a Paused array operation is later restarted should it automatically be put back into a Paused State as part of the restart process?   This would mean the user having to use the Resume button in such a case to continue with completing the operation.    I feel that might be a good idea but welcome feedback but I am not sure.    It could also be made a plugin configuration item depending on the feedback I get.

That sounds exactly like what I was expecting, pausing and resuming as a separate operation once the array was fully started. Having a paused operation of any sort should disable and hide the check button that would start a new run, instead I would expect a "resume" and "cancel" button to take that space.

 

Keeping the current state of a paused operation would be a logical way of operating, having to fight the timing to get an operation paused again while the array starts seems illogical to me.

 

If the operation is paused automatically for a shutdown or reboot, having it resume automatically feels logical as well, with the caveat that starting in maintenance or safe mode probably should leave the operation paused regardless of shutdown state.

 

I suppose another way of approaching it would be having the start array button always resume, and add a button beside the start button with the option to start the array but not resume.

Thanks for the feedback - will have to see how it pans out when trying to detect the various conditions.

 

I cannot find any easy way to add buttons to the Main tab so am trying to find a way to work within the current behaviour.