unRAID Server Release 6.0-beta14b-x86_64 Available

[chickensoup]

Upgraded to 6.0b14b today from 5.0.6 - no plugins, addons, dockers etc. just plain old vanilla unRAID.

 

Upgrade went very smoothly but I'm noticing similar issues to other people in relation to disks not reporting their spin-status correctly. Also it seems like some of my disks are spinning up randomly but I'll get more information on this. I rebooted once after the initial reboot before noticing the following:

 

I was getting the following errors..

No sensors found!
Make sure you loaded all the kernel drivers you need.
Try sensors-detect to find out which these are.

 

So I ran sensors-detect and followed all the steps. It detected 'it87' and 'coretemp' (i think) but I wasn't sure what to do with this information. It said to run lm_sensors and a quick search on the forum for this found mostly unanswered threads or stuff relating to 4.7.

 

e.g.

http://lime-technology.com/forum/index.php?topic=38153.msg353392#msg353392

http://lime-technology.com/forum/index.php?topic=36543.msg351929#msg351929

 

I did tryrunning 'modprobe it87' and 'modprobe coretemp' but neither yielded any result (or error). Not really sure where to go from here.

 

Also, what's the poll time on drive temperatures? I did see them update but it seemed to take a long time..

 

Syslog attached.

syslog.txt

[Squid]

Also, what's the poll time on drive temperatures? I did see them update but it seemed to take a long time..

 

regards gui spin status, i've got temps on drives that are showing as grey.

is that right, cos i've not seen it do that before.

Had the same thing, did some playing around and this is what it looks like is happening:

 

poll_attributes runs every 1800 seconds (30 minutes).  Until the next polling period, Dynamix is going to show what ever value is currently sitting in disks.ini (from the last polling period) - If the drive was spun down at that time, when it spins up it will show "*" for a temperature until the next polling period... And vice versa

 

I changed poll_attributes to be 10 seconds, and everything is working the way that we remember with <b14. 

 

You're just going to have to play with poll_attributes and find a value which you like

 

Maybe a refresh button should get put back onto Main that will poll the attributes right away

I've set my timing to be 300 seconds

[Moussa]

I'm still getting these sorts of emails everyday with this beta, is there anything I can do?

 

error: skipping "/var/log/apcupsd.events" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.

error: skipping "/var/log/docker.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.

error: skipping "/var/log/syslog" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.

error: skipping "/var/log/vsftpd.log" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.

error: skipping "/var/log/wtmp" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.

error: skipping "/var/log/btmp" because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation.

 

This is caused by the Dynamix System Stats plugin, update this plugin to the latest version.

 

Thanks for the response bonienl, your work is awesome. But apparently my System Statistics plugin is upto date? I always check for updates every few days. I have version 2015.02.21 and I can see version 2015.02.15 was the one that fixed this issue.

 

You can check the permissions of the folder /var/log (telnet into your system):

 

ls -l /var

drwxr-xr-x 13 root root 580 Mar  8 04:40 log

 

(the write permission should only be for owner)

 

Yea doesn't seem the permissions are right.

 

ls -l /var

drwxrwxrwx 13 root root 520 Mar  4 03:41 log/

 

I can fix them now but what about when the server restarts?

[Frank1940]

regards gui spin status, i've got temps on drives that are showing as grey.

is that right, cos i've not seen it do that before.

Had the same thing, did some playing around and this is what it looks like is happening:

 

poll_attributes runs every 1800 seconds (30 minutes).  Until the next polling period, Dynamix is going to show what ever value is currently sitting in disks.ini (from the last polling period) - If the drive was spun down at that time, when it spins up it will show "*" for a temperature until the next polling period... And vice versa

 

I changed poll_attributes to be 10 seconds, and everything is working the way that we remember with <b14. 

 

You're just going to have to play with poll_attributes and find a value which you like

 

Maybe a refresh button should get put back onto Main that will poll the attributes right away

 

+1 on the refresh button to force the polling to get the current stats.  It is really quite quite confusing with the way the present display is setup.  When I log onto to the GUI, I want to be able to get the current status of the array without having to wait for the next polling to occur.  I understand the reason behind the longer polling interval and I can see where it could improve the speed of certain disk operations.  But when I am using the GUI, I feel that I should have precedence over essentially background disk operations.  If the polling could be forced when the 'Main' page is opened that would probably be an acceptable option.  Perhaps even combining the two (forced polling when the page starts and the refresh button) so that when we manually spinup or spindown a disk while on the page, we can get the updated status immediately by pressing the 'refresh' button. 

[garycase]

+1 on a status Refresh button 

[chickensoup]

+1 to refresh on main + button

[archedraft]

Received an error email last night:

 

Subject:

cron for user root /usr/bin/run-parts /etc/cron.daily 1> /dev/null

 

Body:

gzip: stdout: No space left on device

error: failed to compress log /var/log/libvirt/libvirtd.log.1

 

Any thoughts on what is happening?

[HellDiverUK]

/dev/null is full.  That's impressive.

[xamindar]

Received an error email last night:

 

Subject:

cron for user root /usr/bin/run-parts /etc/cron.daily 1> /dev/null

 

Body:

gzip: stdout: No space left on device

error: failed to compress log /var/log/libvirt/libvirtd.log.1

 

Any thoughts on what is happening?

 

Something ran out of space......Is your flash drive full?

[archedraft]

Nope, 7.7 gb free

[binhex]

Are you running rsync by any chance archedraft? I had a similar issue caused by a bad flag that caused rsync to copy data to the ram drive.

 

Edit did you see this post? http://lime-technology.com/forum/index.php?topic=38643.0

[archedraft]

Received an error email last night:

 

Subject:

cron for user root /usr/bin/run-parts /etc/cron.daily 1> /dev/null

 

Body:

gzip: stdout: No space left on device

error: failed to compress log /var/log/libvirt/libvirtd.log.1

 

Any thoughts on what is happening?

 

Are you running rsync by any chance archedraft? I had a similar issue caused by a bad flag that caused rsync to copy data to the ram drive.

 

Edit did you see this post? http://lime-technology.com/forum/index.php?topic=38643.0

 

Nope, I have never run rsync before.

[jonp]

Nope, 7.7 gb free

 

This is likely the result of a bug in logging which we are aware of and will be resolving.  The bug is that too much is getting logged to libvirtd.log.  If you type this command:

 

v -h /var/log/libvirt/libvirtd.log

 

I would expect a large # in megabytes, filling up tempfs and causing this problem.  See this thread:  http://lime-technology.com/forum/index.php?topic=38643.msg359439#msg359439

[archedraft]

Nope, 7.7 gb free

 

This is likely the result of a bug in logging which we are aware of and will be resolving.  The bug is that too much is getting logged to libvirtd.log.  If you type this command:

 

v -h /var/log/libvirt/libvirtd.log

 

I would expect a large # in megabytes, filling up tempfs and causing this problem.  See this thread:  http://lime-technology.com/forum/index.php?topic=38643.msg359439#msg359439

 

Yup, happy to hear it's a bug.

-rw------- 1 root root 7.5M Mar 10 16:49 /var/log/libvirt/libvirtd.log

 

 

[jonp]

Nope, 7.7 gb free

 

This is likely the result of a bug in logging which we are aware of and will be resolving.  The bug is that too much is getting logged to libvirtd.log.  If you type this command:

 

v -h /var/log/libvirt/libvirtd.log

 

I would expect a large # in megabytes, filling up tempfs and causing this problem.  See this thread:  http://lime-technology.com/forum/index.php?topic=38643.msg359439#msg359439

 

Yup, happy to hear it's a bug.

-rw------- 1 root root 7.5M Mar 10 16:49 /var/log/libvirt/libvirtd.log

 

Yeah, it's not even really a bug as much as a configuration setting tweak.  You can have libvirt spit out ALL data to a log or you can have it only give you errors/warning messages.  Typically you only do the "all" setting when you're debugging or looking for confirmation of things when developing, but for actual usage, you should just output errors/warnings and your log size will remain small.

[archedraft]

Yeah, it's not even really a bug as much as a configuration setting tweak.  You can have libvirt spit out ALL data to a log or you can have it only give you errors/warning messages.  Typically you only do the "all" setting when you're debugging or looking for confirmation of things when developing, but for actual usage, you should just output errors/warnings and your log size will remain small.

 

Oh, yeah then not a bug at all. Sever just doing what it is told 

[BRiT]

Nope, 7.7 gb free

 

This is likely the result of a bug in logging which we are aware of and will be resolving.  The bug is that too much is getting logged to libvirtd.log.  If you type this command:

 

v -h /var/log/libvirt/libvirtd.log

 

I would expect a large # in megabytes, filling up tempfs and causing this problem.  See this thread:  http://lime-technology.com/forum/index.php?topic=38643.msg359439#msg359439

 

Yup, happy to hear it's a bug.

-rw------- 1 root root 7.5M Mar 10 16:49 /var/log/libvirt/libvirtd.log

 

Yeah, it's not even really a bug as much as a configuration setting tweak.  You can have libvirt spit out ALL data to a log or you can have it only give you errors/warning messages.  Typically you only do the "all" setting when you're debugging or looking for confirmation of things when developing, but for actual usage, you should just output errors/warnings and your log size will remain small.

 

So fixed in v6 beta14z ?

[jonp]

Nope, 7.7 gb free

 

This is likely the result of a bug in logging which we are aware of and will be resolving.  The bug is that too much is getting logged to libvirtd.log.  If you type this command:

 

v -h /var/log/libvirt/libvirtd.log

 

I would expect a large # in megabytes, filling up tempfs and causing this problem.  See this thread:  http://lime-technology.com/forum/index.php?topic=38643.msg359439#msg359439

 

Yup, happy to hear it's a bug.

-rw------- 1 root root 7.5M Mar 10 16:49 /var/log/libvirt/libvirtd.log

 

Yeah, it's not even really a bug as much as a configuration setting tweak.  You can have libvirt spit out ALL data to a log or you can have it only give you errors/warning messages.  Typically you only do the "all" setting when you're debugging or looking for confirmation of things when developing, but for actual usage, you should just output errors/warnings and your log size will remain small.

 

So fixed in v6 beta14z ?

 

 

[chickensoup]

LOL Jon, made my day.  Is that the official LT response? :-P

[Capt.Insano]

@jonp

 

Do we know/may I ask if Docker will be updated version 1.5.0 for the unRAID 6 release?

 

Docker 1.5.0 adds the ability to expose port ranges through:

 

EXPOSE [portA]-[portB]

 

in the container Dockerfile

 

and then run containers with the command:

docker run .... -p [portA]-[portB]:[portA]-[portB]

 

Currently this is not possible on current Docker (v1.4.1)

 

Would make my ruTorrent container easier for users!!

[BRiT]

Do we know/may I ask if Docker will be updated version 1.5.0 for the unRAID 6 release?

 

Maybe in beta14z!

[jonp]

@jonp

 

Do we know/may I ask if Docker will be updated version 1.5.0 for the unRAID 6 release?

 

Docker 1.5.0 adds the ability to expose port ranges through:

 

EXPOSE [portA]-[portB]

 

in the container Dockerfile

 

and then run containers with the command:

docker run .... -p [portA]-[portB]:[portA]-[portB]

 

Currently this is not possible on current Docker (v1.4.1)

 

Would make my ruTorrent container easier for users!!

We will be updating to 1.5 before final. Yes.

[Capt.Insano]

We will be updating to 1.5 before final. Yes.

 

Great news!

 

Will DockerMan be updated to allow new port range values?

 

Currently adding portA-portB range into DockerMan "Add Container" dialogue will not allow you proceed, even for Docker 1.4.1 to subsequently fail.

 

Thanks!

[jonp]

We will be updating to 1.5 before final. Yes.

 

Great news!

 

Will DockerMan be updated to allow new port range values?

 

Currently adding portA-portB range into DockerMan "Add Container" dialogue will not allow you proceed, even for Docker 1.4.1 to subsequently fail.

 

Thanks!

I'm sure we will. Premature to discuss specifics but I think 1.5 also provides better resource usage reporting for us as well (like CPU / memory).  I think we are going to update the tool to display those values as well.

[sparklyballs]

We will be updating to 1.5 before final. Yes.

 

Great news!

 

Will DockerMan be updated to allow new port range values?

 

Currently adding portA-portB range into DockerMan "Add Container" dialogue will not allow you proceed, even for Docker 1.4.1 to subsequently fail.

 

Thanks!

I'm sure we will. Premature to discuss specifics but I think 1.5 also provides better resource usage reporting for us as well (like CPU / memory).  I think we are going to update the tool to display those values as well.

 

is that a segway into resource allocation ? cpu pinning etc from dockerman ?