garycase Posted June 6, 2013 Share Posted June 6, 2013 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. Quote Link to comment
NAS Posted June 6, 2013 Share Posted June 6, 2013 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? Quote Link to comment
garycase Posted June 6, 2013 Share Posted June 6, 2013 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] Quote Link to comment
jaybee Posted June 6, 2013 Share Posted June 6, 2013 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 Quote Link to comment
garycase Posted June 6, 2013 Share Posted June 6, 2013 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 !! Quote Link to comment
freekie Posted June 6, 2013 Share Posted June 6, 2013 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 Quote Link to comment
Dave001 Posted June 6, 2013 Share Posted June 6, 2013 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 Quote Link to comment
Ice_Black Posted June 6, 2013 Share Posted June 6, 2013 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. Quote Link to comment
sacretagent Posted June 6, 2013 Share Posted June 6, 2013 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 Quote Link to comment
garycase Posted June 6, 2013 Share Posted June 6, 2013 WOL has nothing to do with what OS is running ! Quote Link to comment
peter_sm Posted June 6, 2013 Share Posted June 6, 2013 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 Quote Link to comment
nars Posted June 6, 2013 Share Posted June 6, 2013 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) Quote Link to comment
peter_sm Posted June 6, 2013 Share Posted June 6, 2013 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 Quote Link to comment
Harpz Posted June 6, 2013 Share Posted June 6, 2013 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? Quote Link to comment
Joe L. Posted June 6, 2013 Share Posted June 6, 2013 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. Quote Link to comment
Harpz Posted June 6, 2013 Share Posted June 6, 2013 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? Quote Link to comment
optiman Posted June 6, 2013 Share Posted June 6, 2013 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? Quote Link to comment
bnevets27 Posted June 6, 2013 Share Posted June 6, 2013 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 Quote Link to comment
Joe L. Posted June 6, 2013 Share Posted June 6, 2013 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) Quote Link to comment
Interstellar Posted June 6, 2013 Share Posted June 6, 2013 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] Quote Link to comment
garycase Posted June 6, 2013 Share Posted June 6, 2013 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 ?? Quote Link to comment
madburg Posted June 6, 2013 Share Posted June 6, 2013 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. Quote Link to comment
pfp Posted June 6, 2013 Share Posted June 6, 2013 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. Quote Link to comment
itimpi Posted June 6, 2013 Share Posted June 6, 2013 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. Quote Link to comment
mrow Posted June 6, 2013 Share Posted June 6, 2013 Just wanted to confirm the suggested NFS fix from the first post is also not working for me. Still getting stale file handle errors. Quote Link to comment
Recommended Posts
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.