June 6, 201313 yr Apparently, per the discussion above, it can be eliminated (or at least the likelihood dramatically reduced) by setting "... the oom_score_adj for emhttp to -1000 " ... which can be done with a "one-liner" in the GO script. Being a total non-Linux guy, I have no idea how to do that ... perhaps Joe or Tom (or someone !!) will post the exact line that needs to be added to the GO script I assume it's something like "Set oom_score_adj emhttp -1000", but really have NO idea.
June 6, 201313 yr Tom#1, Is there a reason you did not set the oom_score_adj for emhttp to -1000 in rc13? I saw it is still set to "0", making emhttp as likely a candidate as any to be killed in an OOM situation. Joe L. Didn't see a response to this one...Tom? That's trivial to put into your 'go' script and/or implemented via a plugin, not something necessarily I want to put as a 'hardcoded' policy. I guess I could be talked into it. I am with Joe. It makes no sense to me not to do this globally. What am I missing?
June 6, 201313 yr Tom#1, Is there a reason you did not set the oom_score_adj for emhttp to -1000 in rc13? I saw it is still set to "0", making emhttp as likely a candidate as any to be killed in an OOM situation. Joe L. Didn't see a response to this one...Tom? That's trivial to put into your 'go' script and/or implemented via a plugin, not something necessarily I want to put as a 'hardcoded' policy. I guess I could be talked into it. I am with Joe. It makes no sense to me not to do this globally. What am I missing? I agree it seems like it ought to be there by default ... but since it's not, and since it's "... trivial to put into your 'go' script ...", would SOMEONE who knows what the command is PLEASE simply post the appropriate line to add to the GO script !!?? [i assume it's a simple one-liner]
June 6, 201313 yr Can we have a summary of outstanding issues with version 5? - NFS - Slow write issue on some setups? < fixed? - Slow/non responsive GUI at times - Increased and infinite write issue
June 6, 201313 yr Joe L. poster that one-liner some time ago, I can't remember where, but it is: pgrep -f "/usr/local/sbin/emhttp" | while read PID; do echo -1000 > /proc/$PID/oom_score_adj; done Make sure this one-liner goes after the line that starts emhttp. Thanks !!
June 6, 201313 yr About an hour ago, I set up a test server and sat at the webGui click Stop then Start then Stop then Start ...., and what do you know, it did generate a crash after about 50 clicks. So I'm drinking a home brew and trying to analyze wtf is going on. Hmm... the 'stop array' problem didn't go away for long. I'ts just happened to me again. It appears to me that powering down the server between the stops and starts makes it much more likely to happen, well in my case anyway. Attached is the output from Barzija's keeplogs script. syslog_2013-06-06_11.23.59.txt
June 6, 201313 yr Bug report: Wake on LAN is broken with rc13. NIC is Realtek 8111E (onboard Asus M5A97 EVO) Reverted back to rc12a, WOL works again. Thanks, Dave
June 6, 201313 yr I personally think Tom should add Realtek unsupported hardware list (which mean not tested). Realtek is so much headache to deal with, even ESXi don't recommend Realtek ethernet port.
June 6, 201313 yr Bug report: Wake on LAN is broken with rc13. NIC is Realtek 8111E (onboard Asus M5A97 EVO) Reverted back to rc12a, WOL works again. Thanks, Dave WOL works fine for me I just need to specify i use /sbin/powerdown in a cron job to put down the server every night at 01:00AM and wol boots the server at 10.00 AM it is not that i put the server to sleep... i shut him down since waking up from sleep caused some network issues... NIC driver info (from ethtool -i) driver: r8169 version: 2.3LK-NAPI firmware-version: rtl_nic/rtl8168e-2.fw bus-info: 0000:05:00.0
June 6, 201313 yr Bug report: Wake on LAN is broken with rc13. NIC is Realtek 8111E (onboard Asus M5A97 EVO) Reverted back to rc12a, WOL works again. Thanks, Dave WOL are definitely broken, WOL have been working flawless on previous releases for me. - PCIE x1 Gigabit LAN 10/100/1000 Mb/s - Realtek RTL8111E - Supports Wake-On-LAN - Supports LAN Cable Detection - Supports Energy Efficient Ethernet 802.3az - Supports PXE This need to be solved Apart of this RC13 looks running great, but I like to see the new "cache pool" ;-) //Peter
June 6, 201313 yr It's possible that realtek kernel driver disables wol by default, you may try something like ethtool -s eth0 wol g before power down (and obviously you will need to add it on go file if it works so that it enables it on every boot)
June 6, 201313 yr I have this settings when started up my server ..... so definitely the WOL should have been working like it was on RC12a NIC info (from ethtool) Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Link partner advertised pause frame use: Symmetric Link partner advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: MII PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000033 (51) Link detected: yes
June 6, 201313 yr Joe L. poster that one-liner some time ago, I can't remember where, but it is: pgrep -f "/usr/local/sbin/emhttp" | while read PID; do echo -1000 > /proc/$PID/oom_score_adj; done Make sure this one-liner goes after the line that starts emhttp. Would you recommend putting this in my go file then, can it any harm?
June 6, 201313 yr Joe L. poster that one-liner some time ago, I can't remember where, but it is: pgrep -f "/usr/local/sbin/emhttp" | while read PID; do echo -1000 > /proc/$PID/oom_score_adj; done Make sure this one-liner goes after the line that starts emhttp. Would you recommend putting this in my go file then, can it any harm? It will not do any harm, it may let you cleanly stop the array if you are running out of memory as usually the process IDLE the longest is the one of the first to be killed, and unfortunately, usually that is the emhttp web-server that allows you to control unRAID. Keep in mind, running out of memory is serious, and usually requires a reboot, but with emhttp available you can frequently cleanly stop the array first. Note... the command is DIFFERENT for earlier versions of unRAID. The line above will NOT work in the 4.7 version. Joe L.
June 6, 201313 yr Joe L. poster that one-liner some time ago, I can't remember where, but it is: pgrep -f "/usr/local/sbin/emhttp" | while read PID; do echo -1000 > /proc/$PID/oom_score_adj; done Make sure this one-liner goes after the line that starts emhttp. Would you recommend putting this in my go file then, can it any harm? It will not do any harm, it may let you cleanly stop the array if you are running out of memory as usually the process IDLE the longest is the one of the first to be killed, and unfortunately, usually that is the emhttp web-server that allows you to control unRAID. Keep in mind, running out of memory is serious, and usually requires a reboot, but with emhttp available you can frequently cleanly stop the array first. Note... the command is DIFFERENT for earlier versions of unRAID. The line above will NOT work in the 4.7 version. Joe L. Thanks for the info Joe, I'm running v5.0-rc12a at the moment, i take it i just add to go file where stated and reboot the server for it to take effect?
June 6, 201313 yr I now have a problem with AFP. In short, after a clean reboot, I cannot connect to my unraid server from my imac via AFP. This worked fine in the past. I have found that if I disable AFP and then enable again, it starts working and I can connect. It seems to work until I reboot, where I have to disable and then enable again. I don't have time to grab the syslog right now, but wanted to see if anyone else has this same problem. I didn't see a response to this question. Anyone else having connection issues with AFP? Why do I have to disable and then enable before AFP works?
June 6, 201313 yr i take it i just add to go file where stated and reboot the server for it to take effect? Correct Sent from my SAMSUNG-SGH-I727 using Tapatalk 4 Beta
June 6, 201313 yr i take it i just add to go file where stated and reboot the server for it to take effect? Correct Sent from my SAMSUNG-SGH-I727 using Tapatalk 4 Beta Or, add it to the go file, as instructed, and then ALSO run the exact same command on the command line. (Then there is no need to reboot to have the one in the go file execute)
June 6, 201313 yr Also getting this weird writing to the disk when I first start the array. Restarted the array now and it seems to have stopped. It prevented my disks and hence my server going to sleep all night and day!! I think I'll be going back to rc12a. I wish I'd never have to regress [stock rc13 install]
June 6, 201313 yr Note... the command is DIFFERENT for earlier versions of unRAID. The line above will NOT work in the 4.7 version. Thanks Joe. What's the line for 4.7 ??
June 6, 201313 yr I now have a problem with AFP. In short, after a clean reboot, I cannot connect to my unraid server from my imac via AFP. This worked fine in the past. I have found that if I disable AFP and then enable again, it starts working and I can connect. It seems to work until I reboot, where I have to disable and then enable again. I don't have time to grab the syslog right now, but wanted to see if anyone else has this same problem. I didn't see a response to this question. Anyone else having connection issues with AFP? Why do I have to disable and then enable before AFP works? Speeding_Ant shared something you can try (u probably missed it): http://lime-technology.com/forum/index.php?topic=27720.msg245163#msg245163 Also if you are seeing non-stop read-write to your array upon start up, I don't think you will be able to connect via AFP. Some have stated to stop the array if you see this behavior then re-start, the read-write should not resume, and then you could try to connect via AFP. Let us know.
June 6, 201313 yr I too am seeing issues with server becoming completely unresponsive after stopping the array. So far it's happened 100% (twice) of the times I have stopped the array.
June 6, 201313 yr I am also seeing the system crashing when stopping the array. If I go to the console, then there is a crash report there and the system is completely unresponsive (i.e. Linux itself has crashed). I do not get this problem with 5.0rc12a.
June 6, 201313 yr Just wanted to confirm the suggested NFS fix from the first post is also not working for me. Still getting stale file handle errors.
Archived
This topic is now archived and is closed to further replies.