unRAID Server Release 6.1.9 Available

[opentoe]

New release announcement. Awww. There you go getting me all excited only to be disappointed.

 

Seriously though. I do appreciate the release to address a vulnerability though. Despite (given the absence of your staff from forums) the effort thats going into 6.2 it's nice to see that the produce is being well maintained.

 

Update of both Backup and Main Servers went without issue.

 

Thanks for the updates! What a difference from the V4/5 days. I hope the energy and motivation keeps going with this product. Next available appointment - SHARK TANK.

 

[aptalca]

any alarm clocks reset ? power outage ?

Not home right now, but unlikely. The router gui shows that it's been up for 25 days. And the server is connected to a ups which is pretty reliable.

 

How are you connecting to your phone from the your server at home?

 

EDIT:  If you are allowing direct access to your server, you could be the victim of a practical joker who just restarted your server rather then doing something far more malicious.

 

Haha that would be cruel, but no I'm using openvpn (docker on unraid) and I also have a pptp server on an old router. The server is not directly accesible from the internet

[opentoe]

Uh oh!!! I just had a crash and a server restart. No idea why.

 

I was streaming plex on my phone during my lunch break. All of a sudden, I lost connection. Thinking it was my phone, I was trying to reconnect to the plex server, etc. And a couple of minutes later, I got an e-mail saying a parity check was started.

 

It turns out, my server restarted itself, possibly due to a crash. I have no log entries (wiped with the memory I guess).

 

It is concerning because I just updated to 6.1.9 the night before and now this happens. The last entry in the log was the shutdown during the update to 6.1.9 the night before. And it picks up after the restart today. In between is lost.

 

Unraid terminal shows uptime of 20 minutes, so I'm assuming it was a restart of the server as opposed to the array restarting.

 

Any ideas for further troubleshooting?

 

I am currently running a parity check. My server hadn't had any issues in a really long time. I'm not happy, I wish the logs were saved on a disk so I could see what went wrong.

 

Thanks

 

I always check the PSU first. I have a small Dell power supply tester, which tests the connections but doesn't put a load test on it. I re-seat the controller cards and memory if I have to and while I'm in the case do check all the cables.

Any luck?

 

[aptalca]

By and large any outright resets would be hardware related.  Overheating, dust bunnies, loose cards, gremlins, or having a haunted house.

 

 

What you could do is a tail -f > /boot/log.txt to capture the log prior to a reset

 

That's a great idea. I'll direct that to a file on the cache drive, which is always spinning anyway.

 

Thanks

[aptalca]

Uh oh!!! I just had a crash and a server restart. No idea why.

 

I was streaming plex on my phone during my lunch break. All of a sudden, I lost connection. Thinking it was my phone, I was trying to reconnect to the plex server, etc. And a couple of minutes later, I got an e-mail saying a parity check was started.

 

It turns out, my server restarted itself, possibly due to a crash. I have no log entries (wiped with the memory I guess).

 

It is concerning because I just updated to 6.1.9 the night before and now this happens. The last entry in the log was the shutdown during the update to 6.1.9 the night before. And it picks up after the restart today. In between is lost.

 

Unraid terminal shows uptime of 20 minutes, so I'm assuming it was a restart of the server as opposed to the array restarting.

 

Any ideas for further troubleshooting?

 

I am currently running a parity check. My server hadn't had any issues in a really long time. I'm not happy, I wish the logs were saved on a disk so I could see what went wrong.

 

Thanks

 

I always check the PSU first. I have a small Dell power supply tester, which tests the connections but doesn't put a load test on it. I re-seat the controller cards and memory if I have to and while I'm in the case do check all the cables.

Any luck?

 

I'll do that when I get home. Thanks for the suggestions

[mr-hexen]

By and large any outright resets would be hardware related.  Overheating, dust bunnies, loose cards, gremlins, or having a haunted house.

 

 

What you could do is a tail -f > /boot/log.txt to capture the log prior to a reset

 

That's a great idea. I'll direct that to a file on the cache drive, which is always spinning anyway.

 

Thanks

 

It's such a good idea I've expanded on it and added a Feature Request: https://lime-technology.com/forum/index.php?topic=47335.0

 

[METDeath]

Also experiencing the VM cancel issue.

[CHBMB]

Also experiencing the VM cancel issue.

 

See the defect report here...

[redbeard]

No screenshot needed -

Sorry for the slow response -

The Plugin Update Check screen that shows up when you click the button just says

"plugin: checking dynamix.plg ..."

and never gets anywhere.

 

I was using open dns (via router). Switched to google dns - no difference.

 

The log just says

 

Mar 13 19:15:56 Tower emhttp: cmd: /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin checkall

 

and sits there.

 

However changing the DNS on the server never seems to stick. It defaults back to my router, which is set to opendns or google dns.

 

It did work in the past. I may just manually upgrade to 6.2 when beta is over, and start from there.

 

 

 

You need to post up a screen shot of what you get when click on the "Check for updates' button.  But I suspect that the server is unable to connect to a DNS server.  You can actually assign DNS servers on the 'Settings', 'Network Settings' page.  The 'Help' function will help you get things setup.  (Google provides two DNS servers with an IP addresses of 8.8.8.8  and 8.8.4.4 that you can use if you don't know of any others.)

[Ashe]

I have just noticed when running an extended smart test on array or cache disks that the spindown delay is disabled while the smart test runs.

 

All of my disks are set to use default (which is 15 minutes). Once the test completes, that particular disk is set to never.

 

I expected that once the test is finished, the disk would revert back to its previous setting

[walterg74]

Stupid question: if I'm on 6.1.6, can I update automatically from the server?  Any precautions/caveats?

[Squid]

Should be problem free.  If you're paranoid, you can make a backup of the flash drive first, but in reality it shouldn't be necessary as the upgrade will automatically store the old files within "previous" on the flash drive that you can manually restore to go back.

 

Only caveat is that immediately after upgrading and rebooting is to go to plugins / check for updates, as there will be an update for the webUI available that is pretty much required.

[zoggy]

unrad 6.1.9, home internet connection is down.. made the mistake of clicking 'Apps' in the unraid ui.. pretty much locked up unraid for 5 mins? before it timed out and realize it couldnt update the list of apps/check for updates. this timeout really should be shorten.. and also this scenario shouldnt make unraid crap on itself. i closed the tab and opened a new one trying to get to unraid ui root page.. no response until that lookup timed out.

[Frank1940]

unrad 6.1.9, home internet connection is down.. made the mistake of clicking 'Apps' in the unraid ui.. pretty much locked up unraid for 5 mins? before it timed out and realize it couldnt update the list of apps/check for updates. this timeout really should be shorten.. and also this scenario shouldnt make unraid crap on itself. i closed the tab and opened a new one trying to get to unraid ui root page.. no response until that lookup timed out.

 

You probably need to post this on the CA thread:

 

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

[BRiT]

unrad 6.1.9, home internet connection is down.. made the mistake of clicking 'Apps' in the unraid ui.. pretty much locked up unraid for 5 mins? before it timed out and realize it couldnt update the list of apps/check for updates. this timeout really should be shorten.. and also this scenario shouldnt make unraid crap on itself. i closed the tab and opened a new one trying to get to unraid ui root page.. no response until that lookup timed out.

 

I agree, however emhttp seems to be lacking when compared to real webservers. Even though it might have been CA that triggered it, the root xause of the issue is emhttp and how they handle threading of requests.

[Squid]

unrad 6.1.9, home internet connection is down.. made the mistake of clicking 'Apps' in the unraid ui.. pretty much locked up unraid for 5 mins? before it timed out and realize it couldnt update the list of apps/check for updates. this timeout really should be shorten.. and also this scenario shouldnt make unraid crap on itself. i closed the tab and opened a new one trying to get to unraid ui root page.. no response until that lookup timed out.

 

I agree, however emhttp seems to be lacking when compared to real webservers. Even though it might have been CA that triggered it, the root xause of the issue is emhttp and how they handle threading of requests.

this ^^^^ +1

 

CA does something like 20-30 downloads if the appfeed fails, each one of those has a 30second timeout.

 

But like BRiT says, the root cause here is emhttp and that it can only do one thing at a time.  Try maxing out your internet connection with a d/l program then go to the docker tab and add a new container.  Until that container is installed, emhttp won't let you do anything, and since the bandwidth is so limited, that installation might take a while.

[Spritzup]

unrad 6.1.9, home internet connection is down.. made the mistake of clicking 'Apps' in the unraid ui.. pretty much locked up unraid for 5 mins? before it timed out and realize it couldnt update the list of apps/check for updates. this timeout really should be shorten.. and also this scenario shouldnt make unraid crap on itself. i closed the tab and opened a new one trying to get to unraid ui root page.. no response until that lookup timed out.

 

I agree, however emhttp seems to be lacking when compared to real webservers. Even though it might have been CA that triggered it, the root xause of the issue is emhttp and how they handle threading of requests.

 

Hasn't emhttp been a problem since like v4 or v5?  Any reason why it's still being used?

 

~Spritz

[JonathanM]

Hasn't emhttp been a problem since like v4 or v5?  Any reason why it's still being used?

Licensing. I believe it is the single piece of software that enforces which unraid license to apply, and allows the array to be started only when a valid license key is present.

[BRiT]

Hasn't emhttp been a problem since like v4 or v5?  Any reason why it's still being used?

Licensing. I believe it is the single piece of software that enforces which unraid license to apply, and allows the array to be started only when a valid license key is present.

 

That could still be extracted out to a simple module while moving all the UI serving done by normal http daemons.

 

As for why this hasn't been done yet, it's because that part of the system is closed source so the community can not improve it on it's own unless they completely circumvent all aspects of it including the licensing aspects. The community has too much respect for LimeTech and the product to do such a thing.

 

However seeing all these issues which are directly caused by the limitations of emhttp it just might have to be done for the basic UI serving in order to gain stability if LimeTech is unwilling to do so.

[bonienl]

Hasn't emhttp been a problem since like v4 or v5?  Any reason why it's still being used?

Licensing. I believe it is the single piece of software that enforces which unraid license to apply, and allows the array to be started only when a valid license key is present.

 

That could still be extracted out to a simple module while moving all the UI serving done by normal http daemons.

 

As for why this hasn't been done yet, it's because that part of the system is closed source so the community can not improve it on it's own unless they completely circumvent all aspects of it including the licensing aspects. The community has too much respect for LimeTech and the product to do such a thing.

 

However seeing all these issues which are directly caused by the limitations of emhttp it just might have to be done for the basic UI serving in order to gain stability if LimeTech is unwilling to do so.

 

There were talks in the past to look for another web server daemon, I don't think it is unwillingness of LT but rather different priorities. Changing the fundamentals requires a lot of time and testing, something LT has to cherish carefully.

 

[NAS]

There is also the licensing issues. Most replacements would be GPL or similar so not viable.

[BRiT]

There is also the licensing issues. Most replacements would be GPL or similar so not viable.

 

Not completely true. Using a GPL http daemon has no repurcussions on what is hosted or run inside of it. The GPL is not viral across content being served. So the license module would and could still be closed source. You dont need to replace the license model and you could still have it be responsible for that part. There is no requirement on the web ui portions on being GPL but could be open sourced.

[BRiT]

And yes, the time and effort spent in restructuring emhttp into a real http daemon is precious time that currently is needed elsewhere. However, as the ui gets more modern the clear pattern has emerged that more users are having issues with it.

 

In my opinion this change has moved from a nice to have to a must have due to all the multitudes of "unraid nonresponsive" support issuesraised.

[bonienl]

And yes, the time and effort spent in restructuring emhttp into a real http daemon is precious time that currently is needed elsewhere. However, as the ui gets more modern the clear pattern has emerged that more users are having issues with it.

 

In my opinion this change has moved from a nice to have to a must have due to all the multitudes of "unraid nonresponsive" support issuesraised.

 

There is always the possibility to raise a feature request 

 

Hint: the more users can benefit from your feature, the more chance there is of it being accepted!

 

[Squid]

And yes, the time and effort spent in restructuring emhttp into a real http daemon is precious time that currently is needed elsewhere. However, as the ui gets more modern the clear pattern has emerged that more users are having issues with it.

 

In my opinion this change has moved from a nice to have to a must have due to all the multitudes of "unraid nonresponsive" support issuesraised.

 

There is always the possibility to raise a feature request 

 

Hint: the more users can benefit from your feature, the more chance there is of it being accepted!

I think the better question is Who Won't Benefit From It?  IMHO the answer to that is no one.