The latest Dynamix System information is a bit broken on 6.1.9:

 

It tries to show the P +Q algorithm and mine comes up

( + unknown

 

/var/log/dmesg has this:

raid6: using algorithm sse2x4 gen() 10409 MB/s
raid6: .... xor() 8128 MB/s, rmw enabled

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. 

 

Apologies if this has been asked before, but is there a recommended interval to run SSD Trim?  Would this interval be influenced if I'm running a cache pool of multiple SSDs?

 

Thanks in advance!

The latest Dynamix System information is a bit broken on 6.1.9:

 

It tries to show the P +Q algorithm and mine comes up

( + unknown

 

/var/log/dmesg has this:

raid6: using algorithm sse2x4 gen() 10409 MB/s
raid6: .... xor() 8128 MB/s, rmw enabled

 

Any chance you can share your dmesg file?

 

 

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. 

 

Hmm, it should start after upgrading. Need to look into this.

 

Apologies if this has been asked before, but is there a recommended interval to run SSD Trim?  Would this interval be influenced if I'm running a cache pool of multiple SSDs?

 

Thanks in advance!

 

The interval depends very much on your usage pattern. I have mine set to every week, which isn't putting any unnecessary strain on the SSD, while the interval is short enough to avoid SSD performance degradation.

Apologies if this has been asked before, but is there a recommended interval to run SSD Trim?  Would this interval be influenced if I'm running a cache pool of multiple SSDs?

 

Thanks in advance!

 

The interval depends very much on your usage pattern. I have mine set to every week, which isn't putting any unnecessary strain on the SSD, while the interval is short enough to avoid SSD performance degradation.

 

I believe you can run fstrim as often as you want without putting any strain on the SSD at all. It will only free up pages of cells that are no longer in use. If there are none flagged then it doesn't do anything. I run it once a day. See here.

The latest Dynamix System information is a bit broken on 6.1.9:

 

It tries to show the P +Q algorithm and mine comes up

( + unknown

 

/var/log/dmesg has this:

raid6: using algorithm sse2x4 gen() 10409 MB/s
raid6: .... xor() 8128 MB/s, rmw enabled

 

Any chance you can share your dmesg file?

 

 

Attached.

dmesg.zip

The latest Dynamix System information is a bit broken on 6.1.9:

 

It tries to show the P +Q algorithm and mine comes up

( + unknown

 

/var/log/dmesg has this:

raid6: using algorithm sse2x4 gen() 10409 MB/s
raid6: .... xor() 8128 MB/s, rmw enabled

Any chance you can share your dmesg file?

Attached.

 

The difference is that on unraid 6.2rc4, /var/log/dmesg includes a timestamp at the beginning of each line, like this:

[    0.303779] raid6: using algorithm avx2x4 gen() 28511 MB/s

 

Whereas on 6.1.9, there is no timestamp:

raid6: using algorithm avx2x4 gen() 27792 MB/s

 

It looks like the regexes from lines 105 to 112 of Profiler.php need to treat those bracketed numbers as optional in order for this to work on 6.1.9 and 6.2

Attached.

 

Thanks, I made a correction and used your dmesg file to verify the correct operation.

 

Update is available thru plugins manager.

 

 

 

It looks like the regexes from lines 105 to 112 of Profiler.php need to treat those bracketed numbers as optional in order for this to work on 6.1.9 and 6.2

 

(112 - 105) * 6 = 42 

 

It looks like the regexes from lines 105 to 112 of Profiler.php need to treat those bracketed numbers as optional in order for this to work on 6.1.9 and 6.2

 

(112 - 105) * 6 = 42 

I see what you did there.

It looks like the regexes from lines 105 to 112 of Profiler.php need to treat those bracketed numbers as optional in order for this to work on 6.1.9 and 6.2

 

(112 - 105) * 6 = 42 

 

I have created a new plugin "Dynamix Date Time". This plugin adds a clickable world map to the date and time settings and allows the user to simply click his/her country to select the corresponding time zone.

 

Time zone information reflects the assignments as set per July 2016.

 

See OT for details and installation.

 

You need to run V6.2.0rc4 or later to use this plugin.

Attached.

 

Thanks, I made a correction and used your dmesg file to verify the correct operation.

 

Update is available thru plugins manager.

 

Thanks.

 

I do have a small request regarding the dynamix plugins

whatever build environment you are using to building your packages (the txz files installed by the plugins themselves), there is  slight problem with them that is causing me a bit of grief.

 

root@MediaStore:~# tar tvf /boot/config/plugins/dynamix.schedules/dynamix.schedules.txz
drwxrwxrwx root/root         0 2012-09-28 20:22 ./
drwxrwxrwx 0/0               0 2016-08-20 09:05 usr/
drwxrwxrwx 0/0               0 2016-08-20 09:05 usr/local/
drwxrwxrwx 0/0               0 2016-08-20 09:05 usr/local/emhttp/
drwxrwxrwx 0/0               0 2016-08-20 09:05 usr/local/emhttp/plugins/
drwxrwxrwx 0/0               0 2016-08-20 09:05 usr/local/emhttp/plugins/dynamix.schedules/
-rwxrwxrwx 0/0             122 2016-08-20 09:05 usr/local/emhttp/plugins/dynamix.schedules/default.cfg
drwxrwxrwx 0/0               0 2016-08-20 09:05 usr/local/emhttp/plugins/dynamix.schedules/icons/
-rwxrwxrwx 0/0            3231 2016-08-20 09:05 usr/local/emhttp/plugins/dynamix.schedules/icons/fixedschedules.png
drwxrwxrwx 0/0               0 2016-08-20 09:05 usr/local/emhttp/plugins/dynamix.schedules/images/
-rwxrwxrwx 0/0            3220 2016-08-20 09:05 usr/local/emhttp/plugins/dynamix.schedules/images/dynamix.schedules.png
drwxrwxrwx 0/0               0 2016-08-20 09:05 usr/local/emhttp/plugins/dynamix.schedules/include/
-rwxrwxrwx 0/0            1489 2016-08-20 09:05 usr/local/emhttp/plugins/dynamix.schedules/include/update.schedules.php
-rwxrwxrwx 0/0             198 2016-08-20 09:05 usr/local/emhttp/plugins/dynamix.schedules/README.md
-rwxrwxrwx 0/0            3532 2016-08-20 09:05 usr/local/emhttp/plugins/dynamix.schedules/Schedules.page

 

The permission of the ./ (root) is just wrong - it should be 755 not 777. (this is biggest WTF)

This little oversight is causing SSH to reject my keys as they are considered insecure and just bother me with a password request. (this will cause any of my batch scripts to fail as ssh keys are the only way to do batch commands over ssh)

 

In fact I think only your plugins have the wrong permissions (at least the ones that I use)

 

Keep up the good work!

Those folder and file permissions haven't changed since day 1 when Dynamix plugins were introduced.

 

Many many moons later a complaint observation about those permissions 

 

I'd never noticed before nor encountered any issues, but you are right about them. Consequently I have updated ALL dynamix plugins to create folders and files with the correct permissions.

 

Those updates are available thru the plugin manager.

 

Thanks!

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

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

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

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).

 

This new Date Time plugin is only for v6.2 ?

Why is it mentioned on page 1 that it is working on 6.1 and above? 

This new Date Time plugin is only for v6.2 ?

Why is it mentioned on page 1 that it is working on 6.1 and above? 

 

Updated OT and put a note for those plugins which are unRAID 6.2 only. 

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

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.

 

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