One day you'll have to get around to creating the two new xml files (and you can use the <MinVer> tag on them)

 

I know, but the SCSI devices plugin may just be a temporary fix. It is under discussion at the moment.

I consider it my job to harp on people around here 

 

Ok, you forced gently pushed me to add "dynamix date time" as a new entry 

 

One day you'll have to get around to creating the two new xml files (and you can use the <MinVer> tag on them)

 

I know, but the SCSI devices plugin may just be a temporary fix. It is under discussion at the moment.

I consider it my job to harp on people around here 

 

Ok, you forced gently pushed me to add "dynamix date time" as a new entry 

And don't you have the warm, fuzzy feeling knowing that the job has been completed?

One day you'll have to get around to creating the two new xml files (and you can use the <MinVer> tag on them)

 

I know, but the SCSI devices plugin may just be a temporary fix. It is under discussion at the moment.

I consider it my job to harp on people around here 

 

Ok, you forced gently pushed me to add "dynamix date time" as a new entry 

And don't you have the warm, fuzzy feeling knowing that the job has been completed?

 

We are enduring a heat wave here for the past couple of days, I have those "warm" feelings regardless of unRAID...

 

Just noticed that my system log is flooded with this. Any idea what can be done about it?

 

Aug 27 12:22:01 Tower crond[1575]: exit status 127 from user root /usr/local/emhttp/plugins/dyanmix/scripts/monitor &> /dev/null
Aug 27 12:23:01 Tower crond[1575]: exit status 127 from user root /usr/local/emhttp/plugins/dyanmix/scripts/monitor &> /dev/null
Aug 27 12:24:01 Tower crond[1575]: exit status 127 from user root /usr/local/emhttp/plugins/dyanmix/scripts/monitor &> /dev/null
Aug 27 12:25:01 Tower crond[1575]: exit status 127 from user root /usr/local/emhttp/plugins/dyanmix/scripts/monitor &> /dev/null
Aug 27 12:26:01 Tower crond[1575]: exit status 127 from user root /usr/local/emhttp/plugins/dyanmix/scripts/monitor &> /dev/null
Aug 27 12:27:01 Tower crond[1575]: exit status 127 from user root /usr/local/emhttp/plugins/dyanmix/scripts/monitor &> /dev/null
Aug 27 12:28:01 Tower crond[1575]: exit status 127 from user root /usr/local/emhttp/plugins/dyanmix/scripts/monitor &> /dev/null
Aug 27 12:29:01 Tower crond[1575]: exit status 127 from user root /usr/local/emhttp/plugins/dyanmix/scripts/monitor &> /dev/null
Aug 27 12:30:01 Tower crond[1575]: exit status 127 from user root /usr/local/emhttp/plugins/dyanmix/scripts/monitor &> /dev/null

 

This message comes from the monitor script which is part of the base webGUI.

 

Check for unRAID+GUI updates, this error was corrected somewhere along the line (but can't remember when).

 

Rings a bell.  Can't quite remember however.  Have you checked (and installed) all available plugin updates and dynamix webUI updates?

 

Dynamic webGui is listed up to date with version 2016.07.27. All other Dynamic plugins are up to date.

Check if /usr/local/emhttp/plugins/dyanmix/scripts/monitor has execution permission.

 

If needed can be changed by chmod +x /usr/local/emhttp/plugins/dyanmix/scripts/monitor

 

As there was an update for the s3sleep plugin lately, I did it.

Then I noticed, that my server didn't shut down last night and when checking the plugin status it was inactive.

Is it possible to keep/restore the pre-update status of a plugin when the update is complete?

Not sure what happened. All settings - including running state - are retained after a upgrade.

Yesterday another update of s3sleep was available.

I ran the update procedure and forgot to check the status of the service.

The server did not go to sleep last night - checked the s3sleep plugin status and it was stopped. 

New update, same problem.

But this time I remembered to start it manually 

As there was an update for the s3sleep plugin lately, I did it.

Then I noticed, that my server didn't shut down last night and when checking the plugin status it was inactive.

Is it possible to keep/restore the pre-update status of a plugin when the update is complete?

Not sure what happened. All settings - including running state - are retained after a upgrade.

Yesterday another update of s3sleep was available.

I ran the update procedure and forgot to check the status of the service.

The server did not go to sleep last night - checked the s3sleep plugin status and it was stopped. 

New update, same problem.

But this time I remembered to start it manually 

 

I had checked the code before publishing the update and didn't find anything wrong. Can't say why yours doesn't do the auto restart

I had checked the code before publishing the update and didn't find anything wrong. Can't say why yours doesn't do the auto restart

:'(

So what should I do now?

Anything I can do to contribute to bugfixing?

Check if /usr/local/emhttp/plugins/dyanmix/scripts/monitor has execution permission.

 

If needed can be changed by chmod +x /usr/local/emhttp/plugins/dyanmix/scripts/monitor

 

Found the problem in the root file in cron.d

dynamix was misspelled

 

listed path: /usr/local/emhttp/plugins/dyanmix/scripts/monitor

correct path: /usr/local/emhttp/plugins/dynamix/scripts/monitor

 

Any idea if this was fixed for everyone else?

Check if /usr/local/emhttp/plugins/dyanmix/scripts/monitor has execution permission.

 

If needed can be changed by chmod +x /usr/local/emhttp/plugins/dyanmix/scripts/monitor

 

Found the problem in the root file in cron.d

dynamix was misspelled

 

listed path: /usr/local/emhttp/plugins/dyanmix/scripts/monitor

correct path: /usr/local/emhttp/plugins/dynamix/scripts/monitor

 

Any idea if this was fixed for everyone else?

 

Good to hear you figured it out!

 

That spelling mistake was introduced long time ago (one of the early 6.1 beta versions), and corrected since.

 

But to make the correction active one needs to disable / enable system notifications, this will overwrite the file under cron.d

 

Just a question about S3-Sleep:

Is this String

 

hdparm -y $(ls /dev/sd*|grep '[a-z]$') >/dev/null 2>&1 (Custom commands after wake-up)

 

still necessary or can i delete it?

Just a question about S3-Sleep:

Is this String

 

hdparm -y $(ls /dev/sd*|grep '[a-z]$') >/dev/null 2>&1 (Custom commands after wake-up)

 

still necessary or can i delete it?

 

Depends on your hardware. You need to test yourself.

 

Just a question about S3-Sleep:

Is this String

 

hdparm -y $(ls /dev/sd*|grep '[a-z]$') >/dev/null 2>&1 (Custom commands after wake-up)

 

still necessary or can i delete it?

 

Depends on your hardware. You need to test yourself.

 

OkiDoki - then i will test it 

Thanks 

Thanks for your great work, bonienl! Having finally just migrated from 5.0.6, the new unRAID 6.1.9 looks very familiar, thanks to you!

 

2 questions:

1) How do I customize the GUI to get back to the darker interface I had under 5.x?

2) Do you have a recommendation for an easy install for perl for the System Temp plugin?

Thanks for your great work, bonienl! Having finally just migrated from 5.0.6, the new unRAID 6.1.9 looks very familiar, thanks to you!

 

2 questions:

1) How do I customize the GUI to get back to the darker interface I had under 5.x?

Display Settings - Dynamix color theme

2) Do you have a recommendation for an easy install for perl for the System Temp plugin?

NerdPack sticky

Thanks for your great work, bonienl! Having finally just migrated from 5.0.6, the new unRAID 6.1.9 looks very familiar, thanks to you!

 

2 questions:

1) How do I customize the GUI to get back to the darker interface I had under 5.x?

Display Settings - Dynamix color theme

derp - that was about the only setting screen I didn't look at

2) Do you have a recommendation for an easy install for perl for the System Temp plugin?

NerdPack sticky

Thank you! working like a charm!

I'm doing some testing with Oracle F80 flash accelerator as a cache device, and have a question regarding  the Dynamix System Autofan plugin:

 

Is it possible to exclude specific drives from the plugin's calculations?

 

The ssd's attached to the F80's hba have a 74C operating ceiling, and average 50C under load even with 120x38mm delta fan @ 3500rpm.  I would like to leave the plugin default (35-45C) in place for 3.5" HDDs, but the SSD temps on the F80 are maxing out the fans currently.

 

Thanks!

 

 

Are there any volunteers willing to test and review the latest webGUI developments?

 

These are new features not present yet, but may become available in a future release.

 

Main new features are:

 

1. Show disk I/O activity. This was available as a separate plugin dynamix.disk.io (needs to be removed) but now integrated in the GUI, it contains latest code updates

2. Summarized notifications. The notification system has been enhanced and possibility exists to view notifications the traditional way (detailed) or to see notification counters only (summarized), which can be clicked to open unread notifications

 

Besides new features some code adjustments and optimizations are done as well.

 

- Replace deprecated HTML5 tags: <big>, <font>, <center>

- Make all 'require_once' statements consistent with absolute path using $docroot

- Code consistency: replace array functions with PHP preferred 'bracket' notation

- CSS optimization and enhancements

- Load context.js and context.css in DefaultPageLayout and remove them from Dashboard, Docker, VM

 

These developments are in test phase. I've done my best to get this as good as possible and squeezed all known bugs, but it is "use at your own risk".

 

If enough interest I can make a "bleeding edge" package available...

 

 

More than willing to try these out if you are prepared to make the appropriate package.

If enough interest I can make a "bleeding edge" package available...

 

I'm interested.

I'm doing some testing with Oracle F80 flash accelerator as a cache device, and have a question regarding  the Dynamix System Autofan plugin:

 

Is it possible to exclude specific drives from the plugin's calculations?

 

The ssd's attached to the F80's hba have a 74C operating ceiling, and average 50C under load even with 120x38mm delta fan @ 3500rpm.  I would like to leave the plugin default (35-45C) in place for 3.5" HDDs, but the SSD temps on the F80 are maxing out the fans currently.

 

Thanks!

 

AFAIK it's not possible at the moment, I would also like to request this, as anytime I do longer writes to my cache SSD it goes 50C+ making all fans speed up unnecessarily.

Are there any volunteers willing to test and review the latest webGUI developments?

 

If enough interest I can make a "bleeding edge" package available...

 

I can help testing it 

I'd be glad to help test. Still running 6.1.9 though. Is 6.2 required?

Another one to test if needed

Seems the usual suspects are up for it

 

Number of prerequisites before start using the latest and greatest...

 

1. You need to run unRAID v6.2.0-rc5. It will not install with any other version of unRAID

2. If you have installed the plugin dynamix.disk.io, this needs to be uninstalled before using this plugin

3. After installation it is recommended to reboot your server to get everything 'straightened'

 

Install using the plugin manager. URL to copy and paste:

https://raw.githubusercontent.com/bergware/dynamix/master/unRAIDv6/dynamix.bleeding.edge.plg

 

If you want to use the new view mode of notifications then you need to change the setting Notifications display to Summarized (see Settings -> Notification settings)

 

Please let me hear your remarks, recommendations, improvements, problems