Dynamix - V6 Plugins

bonienl

By bonienl
in Plugin Support

Recommended Posts

Recommended

Posted by Zonediver,

Its not broken, just "vice versa" 😉 You can fix this. If the sleep plug-in is active, you can enter all drives (which you want to monitor) under "Monitor disks outside array:" There is something "the other way around" - but it is working 😉👍 It seems the plugin does not recognise the array correctly (last update from 6.2020)      
Recommended by Squid
  • Confused
  • Thanks

3 reactions

Go to this post
DanielCoffey Contributor

DanielCoffey

Posted
Posted

ISSUE : Dynamix S3 Sleep (2016.06.19) not Sleeping when invoked from Array Operation tab.

UNRAID : 6.1.9 Plus

 

I checked my plugins for updates today and saw that the WebGUI, S3 Sleep and System Temperature were all wanting to be updated. After an update, I left the server running and we watched a movie. After we were done, I came back to the WebGUI - Main - Array Operation tab and clicked the Sleep button. The label for the button changed to "Sleeping..." but the server did not enter the sleep state. Fans were still running and the WebGUi still responded

 

The previous version of the plugin certainly worked as I have got used to the fans stopping and hearing the click of the PSU turning off.

 

I stopped, rebooted and restarted the server but there was no change in the behaviour of the sleep button.

 

My system spec in my forum sig is correct.

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

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Popular Posts

bonienl
bonienl

Notice: You must be running unRAID version 6.9 or later to use these plugins The easiest way of installing plugins is thru Community Applications. This is an apps installation manager develope

bonienl
bonienl

It has been some time since I visited the Unraid forums. Due to health issues I had to take a break, and unfortunately this break took way longer than anticipated. But I am back and will sta

bonienl
bonienl

Today has been a productive day   I have updated several Dynamix plugins, mainly bug fixes. Please check your plugins to get the updates.

Posted Images

s.Oliver Contributor

s.Oliver

Posted
Posted

first off, a great thank you to bonienl for these wonderful suite of plug-ins.  :)

 

a few days ago i installed the SSD TRIM plug-in (i somehow managed to ignore it for quite a while, beside running other Dynamix plug-ins  :o) and set it to fire at 8am every day. the very next day i checked the logs of unRAID to look for (maybe) any entries belonging to the plug-in. low and behold i found this one (removed private informations):

 

Jun 23 08:00:02 unRAID sSMTP[20482]: Creating SSL connection to host
Jun 23 08:00:02 unRAID sSMTP[20482]: SSL connection using XXXX
Jun 23 08:00:02 unRAID sSMTP[20482]: Authorization failed (535 5.7.8  https://support.google.com/mail/answer/14257 u64sm2150802wmd.8 - gsmtp)

 

ok, a bit confused (for a moment) – what has caused this? out of nowhere (and never before) something tried to send an email via google. the next second i remembered, ey i got the new plug-in installed – maybe it has any defaults to send reports automatically. checked the "Notification Settings" in unRAID, but they where like i had them set up: no eMail-Notifications, only in browser; no email-account informations in the "SMTP Settings" area.

 

so i went ahead and configured the "SMTP Settings" with my account informations (with different sending/receiving addresses). i verified the setup by using the "Test"-button and immediately received the test-email – all well i thought. and the very next day log-check showed this:

 

08:00:01 unRAID sSMTP[x]: RCPT TO:<[email protected]> (553 5.7.1 <[email protected]>: Sender address rejected: not owned by user email-account)

 

this error says that something (most probably the plug-in, because didn't happen before) tried to use the sender email-address "[email protected]" to send an email to the (correctly) specified "[email protected]"-address. but now, it correctly did try to use the google email-servers, instead it used the specified one. after re-checking all settings and test-sending emails from the "SMTP Settings" tab i came to the conclusion, that (maybe) the plug-in (or any used parts of unRAID for sending emails) has a hard coded sending email-address (root@) and ignores the specified one.

 

now, you could ask, why then not use the [email protected]. because of security concerns. this email-server checks the sending email-address against the provided email-account; and if it can't verify that it is allowed, it denies it, hence the error in the log.

 

 

wrap up: had no log entries up to now which are email related (and nothing configured for it) and just exactly one second after the (since then) newly installed SSD_TRIM plug-in fired, i'm pretty much confident, that it is caused by it. maybe some things play together here (functions of unRAID which are used for sending the actual email, or combinations of Dynamix plug-ins) but i think it can be fixed to work as expected.

 

sorry for the long post, but it (hopefully) helps much better to track down this bug.

 

greets,

oliver

Link to comment
bonienl Veteran

bonienl

Posted
  • Author
Posted

yes, gives this error:

 

root@unRAID:~# /sbin/fstrim -v /mnt/cache
fstrim: /mnt/cache: FITRIM ioctl failed: Operation not supported

 

First thing to check is if your SSD supports trim

 

# hdparm -I /dev/sdX | grep TRIM

      (X = reference to your cache disk)

 

Second question: is your disk directly connected to your motherboard or do you use an adapter?

 

 

 

Link to comment
s.Oliver Contributor

s.Oliver

Posted
Posted

yes, gives this error:

 

root@unRAID:~# /sbin/fstrim -v /mnt/cache
fstrim: /mnt/cache: FITRIM ioctl failed: Operation not supported

 

First thing to check is if your SSD supports trim

 

# hdparm -I /dev/sdX | grep TRIM

      (X = reference to your cache disk)

 

root@unRAID:~# hdparm -I /dev/sdb | grep TRIM
   *	Data Set Management TRIM supported (limit 8 blocks)

 

Second question: is your disk directly connected to your motherboard or do you use an adapter?

 

it is directly connected and does support trim (Samsung Evo 850).

 

thx. for looking into it.  :)

Link to comment
s.Oliver Contributor

s.Oliver

Posted
Posted

It is unclear to me why fstrim fails, but it is the cause of the email (when a cron job fails it results in an email sent).

 

Are you running version 6.2?

 

no, 6.1.9 as per signature.

but why is the cron job then ignoring the settings for smtp? it is using root@ instead of the setup email-address.

 

Link to comment
bonienl Veteran

bonienl

Posted
  • Author
Posted

It is unclear to me why fstrim fails, but it is the cause of the email (when a cron job fails it results in an email sent).

 

Are you running version 6.2?

 

no, 6.1.9 as per signature.

but why is the cron job then ignoring the settings for smtp? it is using root@ instead of the setup email-address.

 

It's normal that email of cron job is sent by root. It is not attached to any user.

 

Link to comment
s.Oliver Contributor

s.Oliver

Posted
Posted

It's normal that email of cron job is sent by root. It is not attached to any user.

 

well, i know usually it is sent by sendmail. i thought, that unRAID uses it's own script or small proggy, which is sending out the email with regard to the settings in the "SMTP Settings". but, it seems we have two different use cases here: 1st for sending out only the specified in "Notification Settings" and 2nd for all system generated output.

 

strange in use case two is, that unRAID is already using all defined parameters of "SMTP Settings", but only replaces the sender address with the "root@"-part. in my opinion it seems to be a small step from here to using the specified "from" sending address.

Link to comment
s.Oliver Contributor

s.Oliver

Posted
Posted

>> bonienl

 

is it maybe because the cache device is using (the defaulted) BTRFS?

 

reading up a bit reveals, that BTRFS should support TRIM, but (might) dependent on used mount options.

maybe the only quick solution is to format the SSD with EXT4?

 

this page might shed some light on my issue:

https://kb.plesk.com/en/122080

 

using the command on the mountpoint of the cache drive "/mnt/cache" shows the exact same output (also for the discard_max_bytes).

 

Link to comment
JorgeB Grand Master

JorgeB

Posted
Posted

 

 

>> bonienl

 

is it maybe because the cache device is using (the defaulted) BTRFS?

 

No, default BTRFS supports TRIM, you usually get that error when the controller doesn't support it, looks like you're virtualizing unRAID, so maybe that's the cause (if you're using the mb controller).

 

 

Link to comment
s.Oliver Contributor

s.Oliver

Posted
Posted

 

 

>> bonienl

 

is it maybe because the cache device is using (the defaulted) BTRFS?

 

No, default BTRFS supports TRIM, you usually get that error when the controller doesn't support it, looks like you're virtualizing unRAID, so maybe that's the cause (if you're using the mb controller).

 

you're right, i do virtualize unRAID, in that hardware controllers are passthrough completely to unRAID. all (to me) known/used hardware features (esp. such as sleep function of hdd) do work properly. even all operations, which do change the boot usb-stick – so no tricks used/necessary here. the SSD is on the same controller (SAS3 from MB) as other HDDs.

 

not an TRIM expert here, but my reading showed, that they use the fstrim command on mountpoints of filesystems and not on devices directly. well, i tried that too, but same result.

Link to comment
JorgeB Grand Master

JorgeB

Posted
Posted

 

 

>> bonienl

 

is it maybe because the cache device is using (the defaulted) BTRFS?

 

No, default BTRFS supports TRIM, you usually get that error when the controller doesn't support it, looks like you're virtualizing unRAID, so maybe that's the cause (if you're using the mb controller).

 

you're right, i do virtualize unRAID, in that hardware controllers are passthrough completely to unRAID. all (to me) known/used hardware features (esp. such as sleep function of hdd) do work properly. even all operations, which do change the boot usb-stick – so no tricks used/necessary here. the SSD is on the same controller (SAS3 from MB) as other HDDs.

 

not an TRIM expert here, but my reading showed, that they use the fstrim command on mountpoints of filesystems and not on devices directly. well, i tried that too, but same result.

Is the  SAS3 controller from intel PCH or other, like LSI, some LSI controllers don't support trim, e.g., 9211.

Link to comment
s.Oliver Contributor

s.Oliver

Posted
Posted

 

 

 

the SSD is on the same controller (SAS3 from MB) as other HDDs.

 

Looking at your mb manual this is the problem, SAS3 is onboard LSI, when we say onboard controller we mean the PCH ports, connect the SSD to one of those and trim should work.

 

just wanted to post back, that the SSD is connected to the LSI Logic SAS3008 chip – but you beat me ;)

well, i've choosen the faster SAS3 ports and usually passthrough of 3rd party controllers is easier than the MB-ports. well, i'll probably need to reconsider how to utilize all ports of the board. i've passthrough'ed another LSI Logic SAS2008 pci card to unRAID as well. but it seems then same game for these LSI controllers.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
Go to topic listing