unRAID Server Release 5.0-rc9 Available


limetech

Recommended Posts

If you use the power down package from unmenu you can shutdown/start cleanly from the command line.

 

It should be a native behavior and not dependent on a plugin.

 

??? Says who.  If you would like that to work you can request it but by what grounds do you have to say that it should be native.  I'm happy with the way that it works atm I am fully aware of the strartup/shutdown requirements if you can't be bother to follow the process or think it's to hard then don't and put up with the parity checks.

 

As far as I can tell Unraid was designed to be managed via the gui and not via commandline.  As such it is not native to be using a command line to restart/shutdown the system.

 

tisk tisk. Who said I am bothered? I have no issues in this area. I would like to know that should I lose the web gui for any reason I can properly shutdown/reboot via commandline though, without having to install anything other than unRAID itself.

 

Sorry I mistook your comment that it should be native as meaning you were bothered that it wasn't??

 

Someone posted that unraid is based on linux and linux is a command line driven operating system and as such it should work.  It is pointed out that unraid is based/built on linux and it is just that, unraid is not "linux" persay but a product built on linux and to assume that it will function as such is incorrect. 

 

Just above this says 99% of people won't use it and thats correct and I think there are better things to work on than this.

Link to comment
  • Replies 76
  • Created
  • Last Reply

Top Posters In This Topic

Just a reminder to those who added a line or two in their config/go scripts to load the (then) newer 3.6.8 SAMBA version in place of the buggy version in rc8a... 

 

Once you upgrade to rc9a, delete the added lines in the config/go script, otherwise you will be several versions BEHIND in the version of SAMBA you are running compared to that in rc9a.  ( it comes with samba-3.6.10 )

 

Joe L.

Link to comment

the workaround is to set 'other' read/execute permissions on directories, which is what the modified 'New Permissions' script does.

 

Thanks for the info on what the new permissions utility is doing. I now understand why the '5.0 security model' is different between RC8a and RC9*, thus requiring the utility to be run!

 

Does changing these permissions on folders cause any problems if we need to rollback to a previous unRAID version?

 

Sent from my Nexus 7 using Tapatalk 2

 

 

Link to comment

Not sure if this is isolated to only my setup, I seem to be getting a hard crash while running the "New Permissions" script. It gets halfway through my 12 disks and there crashes with the following:

 

please see http://pastebin.com/Mju9VvCQ

 

nothing seems to be accessible afterwards, shares, ip...each time an unclean shutdown is detected

 

running rc9a with 4Gb of ram (4Gb of swap) in a VM, esxi 5.1. It seems to be out of mem issue.

Link to comment

Not sure if this is isolated to only my setup, I seem to be getting a hard crash while running the "New Permissions" script. It gets halfway through my 12 disks and there crashes with the following:

 

please see http://pastebin.com/Mju9VvCQ

 

nothing seems to be accessible afterwards, shares, ip...each time an unclean shutdown is detected

 

running rc9a with 4Gb of ram (4Gb of swap) in a VM, esxi 5.1. It seems to be out of mem issue.

 

You are running out of memory and python got sacrificed:

 

Jan 11 10:39:51 Clara-Belle kernel: Out of memory: Kill process 10852 (python) score 4 or sacrifice child
Jan 11 10:39:51 Clara-Belle kernel: Killed process 10852 (python) total-vm:211540kB, anon-rss:31848kB, file-rss:3116kB

Link to comment

Not sure if this is isolated to only my setup, I seem to be getting a hard crash while running the "New Permissions" script. It gets halfway through my 12 disks and there crashes with the following:

 

please see http://pastebin.com/Mju9VvCQ

 

nothing seems to be accessible afterwards, shares, ip...each time an unclean shutdown is detected

 

running rc9a with 4Gb of ram (4Gb of swap) in a VM, esxi 5.1. It seems to be out of mem issue.

 

 

You seem to be running out of memory. Why was python targeted or even running. Do the permission fix thing on a virgin unRAID (no plugins) and freshly booted so that cache is empty.

 

 

You can also try dropping the cache before running the script. Even though you have swap, low kernel buffer memory does not get swapped out.

 

 

I had this problem whenever I would do very large rsync backup scripts. I had so many files that unRAID would run out of memory. I changed the script to drop the cache before and after the script. That helped alleviate the issue, but only if I ran these rsync backups or directory finds in a single threaded manner.

 

 

do this to drop the cache.

echo 3 > /proc/sys/vm/drop_caches

 

 

Link to comment

WeeboTech, I neglected to mention that I have sickbeard/sabnzbd as the only plugins which would use python. I just ran the permission script's commands manually. Have not tried dropping the cache.

 

Edit: even after doing it manually, still crashes kernel...will try to drop cache and re-execute the permissions script

Link to comment

Tom - I don't know what you've done.

 

I'm getting peaks of 45-50MB/s writes since this latest update. Previously I'd hit 30MB/s max.

 

Nice work.

 

Wish I could say the same, RC8a I was at 45-50MB writing from one data drive to another (immediately), now it starts at 9mb and slowly climbs up to 24MB (has a parity drive to be clear). So lost half the speed. NO changes to the hardware between RC8a and RC9a (no go tweaks, plugins, etc...) :'(

 

Sample:

 

1) 9-24MB writing from one data drive to another, many 1+GB files

2) 37-42MB writing from one data drive to another, 1 file 6+GB

 

3) 38-53MB writing from client to cache drive, 100 files totaling 500+ MB

4) 71-98MB writing from client to cache drive, 1 file 6+GB

 

So outside of test #1 all others tested well in spec for me. #2 used to be better as well, but acceptable.

 

Link to comment

Tom - I don't know what you've done.

 

I'm getting peaks of 45-50MB/s writes since this latest update. Previously I'd hit 30MB/s max.

 

Nice work.

 

Wish I could say the same, RC8a I was at 45-50MB writing from one data drive to another (immediately), now it starts at 9mb and slowly climbs up to 24MB (has a parity drive to be clear). So lost half the speed. NO changes to the hardware between RC8a and RC9a (no go tweaks, plugins, etc...) :'(

 

Sample:

 

1) 9-24MB writing from one data drive to another, many 1+GB files

2) 37-42MB writing from one data drive to another, 1 file 6+GB

 

3) 38-53MB writing from client to cache drive, 100 files totaling 500+ MB

4) 71-98MB writing from client to cache drive, 1 file 6+GB

 

So outside of test #1 all others tested well in spec for me. #2 used to be better as well, but acceptable.

 

Update to linux kernel 3.4.24 was to address write slowdown discussed here:

http://lime-technology.com/forum/index.php?topic=22675.0

This seems to be CPU specific so perhaps your slowdown is due to the same thing.

Link to comment

WeeboTech, I neglected to mention that I have sickbeard/sabnzbd as the only plugins which would use python. I just ran the permission script's commands manually. Have not tried dropping the cache.

 

Edit: even after doing it manually, still crashes kernel...will try to drop cache and re-execute the permissions script

 

Anything else that is running and accessing lots of files is going to cause issues.

You can try.

 

dropping the cache.

stopping the apps.

stopping the apps and dropping the cache.

booting with no plugins, then dropping the cache and running the permissions program.

If that doesn't work, there's some kind of memory issue with unRAID then.

Link to comment

Not sure if this is isolated to only my setup, I seem to be getting a hard crash while running the "New Permissions" script. It gets halfway through my 12 disks and there crashes with the following:

 

please see http://pastebin.com/Mju9VvCQ

 

nothing seems to be accessible afterwards, shares, ip...each time an unclean shutdown is detected

 

running rc9a with 4Gb of ram (4Gb of swap) in a VM, esxi 5.1. It seems to be out of mem issue.

 

Please move your post or recreate in in the 5.0-rc board:

http://lime-technology.com/forum/index.php?board=42.0

 

Link to comment

I use Crashplan to backup my server.  If I run the permissions slip does it flag the files as modified making crashplan think it needs to re-sync the entire server?

 

I don't relish re-syncing the entire server again.

 

thanks,

dave

 

Yes, it will. But so long as you have dedupe enabled it will just whiz through it.

Link to comment

dedupe?  Isn't that the sound a horse makes when its walking along?  ;D

 

I have it set to auto, I assume that is OK or should I set it to full?

 

thanks,

dave

 

I use Crashplan to backup my server.  If I run the permissions slip does it flag the files as modified making crashplan think it needs to re-sync the entire server?

 

I don't relish re-syncing the entire server again.

 

thanks,

dave

 

Yes, it will. But so long as you have dedupe enabled it will just whiz through it.

Link to comment

Tom - I don't know what you've done.

 

I'm getting peaks of 45-50MB/s writes since this latest update. Previously I'd hit 30MB/s max.

 

Nice work.

 

Wish I could say the same, RC8a I was at 45-50MB writing from one data drive to another (immediately), now it starts at 9mb and slowly climbs up to 24MB (has a parity drive to be clear). So lost half the speed. NO changes to the hardware between RC8a and RC9a (no go tweaks, plugins, etc...) :'(

 

Sample:

 

1) 9-24MB writing from one data drive to another, many 1+GB files

2) 37-42MB writing from one data drive to another, 1 file 6+GB

 

3) 38-53MB writing from client to cache drive, 100 files totaling 500+ MB

4) 71-98MB writing from client to cache drive, 1 file 6+GB

 

So outside of test #1 all others tested well in spec for me. #2 used to be better as well, but acceptable.

 

Update to linux kernel 3.4.24 was to address write slowdown discussed here:

http://lime-technology.com/forum/index.php?topic=22675.0

This seems to be CPU specific so perhaps your slowdown is due to the same thing.

 

I am not sure if I follow you Tom, the update to this newer linux version should address write slowdown not increase them right? (don't believe I am facing the problem the guys on that post are facing). I have a Xeon X3470, not the Xeon E-Series the guys are posting on that thread.

I have 6GB of ram as what I found to be the sweet spot (for me with no plugins/add-ons). I don't have issues as I have seen with 4GB (when mover has a lot of data to move) or more than 6GB  of memory (seen issues when clearing a drive, etc.) with my HW setup.

I don't have 1MB write to the array. And no dropped frames. Network is solid.

 

I did notice one person stating when the disk is almost full or almost full, affected their speeds. So I when back to check and the source Data drive had only 40GB left on it, the destination Data drive had almost 200GB available (from which I conducted Test #1).

 

So I just tried a similar copy (less files, about (28) 600MB-1GB in size) from a source & destination drive that both had over 100GB free and the results where better:

 

Disk13->Disk14 =  started at 9MB and leveled off to 37MB (so thats better than 9-24MB)

(Same files back) Disk14->Disk13 = Started in the mid 40MB leveled off at 37MB (again 37MB better than 24MB)

 

Buy no means do I feel this is a bad release (so far best yet), and my disk space maybe affecting it a bit and in combination with a newer kernel is why I get what I get, but don't see these numbers as a failure. I am in need of adding some more 3/4TB drives to open up some much needed space. But stopped all HW purchases to this unRAID build at the moment until I know it goes final (truly, not just a label  ;D), working as designed and I feel I can trust it and have support for it. I agree with any and all changes no matter how large they are to get 5.0 to Final (my 2 cents).

 

I am sorry to hear that you wont be updating AFP and it components until after 5.0 final. This is a pain point for me, as my separate PLEX Server and Clients are not happy with unRAID via AFP... hope you reconsider.

 

 

 

Link to comment

6: Despite points raised above, we still have no native ability to cleanly shut down the server from the command line. This seems odd to me that this would not be fixed to be native rather than via add ons, especially in light of issues with webgui's hanging and becoming unavailable.

The 'powerdown' script has been around forever.  I don't consider further functionality high priority since other methods exist for now.  But I agree this point is debatable, though 99% of users would never need it.

 

Not sure how to take this Tom, as far as I know you have insisted on no third party add-ons (which usually cause most problems), less preclear_script by JoeL. which you formally commended in a post. I don't believe I/We should have to install unMENU in order to just install the 'powerdown' script, there by no longer a stock install.

ex. If I wanted to check ReiserFS on a disk, I don't have a button in the WebGUI to do so, right? Why not? I have to learn the command(s) which I have to execute in a commandline terminal... You have added the option to enter the array into maintenance mode but not the ability to check ReiserFS per disk or all disks via the WebGui... So when I hear this bouncing around its confusing, should it all be commandline or all WebGUI? Hope you see my point. So (don't get offended) is someone to lazy to add exactly (no reason to reinvent the wheel, or any additional/further funtionality) what the powerdown script does directly into unRAID; or... some other reason? It cant be time, cause we've been waiting a longgggg time  :o

 

 

Link to comment

@tom

 

The 'powerdown' script has been around forever.  I don't consider further functionality high priority since other methods exist for now.  But I agree this point is debatable, though 99% of users would never need it.

 

Well you are in charge.  I understand your position, and you understand mine.  I don't necessary agree with you but there it is.  You feel that this is additional functionality as unraid is meant to be controlled through the web interface.  Microsoft windows is meant to be controlled through the Graphic User Interface, but it unmounts the file systems cleanly through the CLI.  Yours does not.  That is a bug in my books.

 

With a project such as this, you can never please everyone.  You do the best you can with what you have.  You have your priorities.  I just wanted to make sure you were aware of it.  It appears you are very aware of this issue. 

 

Thanks for all your work!

 

--Sideband Samurai

Link to comment

Does changing these permissions on folders cause any problems if we need to rollback to a previous unRAID version?

 

I rolled back to v4.7 after running permissions script on rc8a and experiencing the SAMBA issue, no access / file problems for me.

 

Waiting for rc9 to settle down before upgrading again.

 

Ost.

Link to comment

@madburg

 

If I wanted to check ReiserFS on a disk, I don't have a button in the WebGUI to do so, right? Why not?

 

I can see you are not a programmer.  The reason this has not been done is because your feature request requires extensive updates to Unraid which also means lots of extra time.  We don't know what Tom is doing between fixes, so let me explain what might happen.  First the WebGUI has to be updated.  Possibly a whole new page built just for checking the file system, scripts have to be written to support the web page.  This includes capturing the output of what the file system check is telling you.  Then the whole thing has to be tested.  Bugs have to be fixed, and those bug fixes have to be tested.  I can see Tom's point, there are bigger fish to fry than making a webgui for checking the disks.

 

Mac OS is a good example of a mix between GUI and command line.  Most functionality is provided from the GUI interface.  The rest is provided by the command line.  especially functions you don't want "normal" uneducated users to get at.  I understand it can be frustrating that no graphic interface exists for checking the disks.  Even the Linux community as a whole has never written one.

 

So (don't get offended) is someone to lazy to add exactly (no reason to reinvent the wheel, or any additional/further funtionality) what the powerdown script does directly into unRAID; or... some other reason? It cant be time, cause we've been waiting a longgggg time

 

Well I agree, but again Tom could be doing other things which makes this a low priority.

 

I don't think Joel's script is supported by Tom, still supported by Joel himself, he just includes it as part of the package.  The linux community is a lot like that.  Linus Turvalds team provide the kernel, the rest of the community provides the rest.  Which is called a distribution.  Together it all just works, or sometimes it doesn't ;D

 

--Sideband Samurai

Link to comment

@Ostrich

 

I rolled back to v4.7 after running permissions script on rc8a and experiencing the SAMBA issue, no access / file problems for me.

 

Waiting for rc9 to settle down before upgrading again.

 

Ost.

 

I have been running RC8a for several months now with out any issues.  I actually used a new USB key to make sure I had a way of going back if necessary, and performed the upgrade.  Everything came through like a champ.  What issues are you having?  Maybe you should try again, making sure you are not running any plugins and follow the directions in the release notes.

 

--Sideband Samurai

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.