June 5, 20179 yr Putting aside the actual issue that is/has caused my server to hang (GUI,dockers,SMB all down). I have telnet access still. Issued a powerdown (muscle memory from the plugin days) and it responds "The system is going down for system halt NOW" but doesn't actually shut down. Issue poweroff and get the same response "The system is going down for system halt NOW" but nothing happens. Why can't unraid be forced down via cmd line? back when using the plugin if you had telnet access and issues powerdown it always worked. I've rarely had the built in poweroff command work leading to unnecessary hard shutdowns. Why doesn't it work? I have the server in the hung state currently and accessed the log, there's nothing in there indicating why it won't shutdown. I can keep it up for a bit to try other commands but its likely going down hard. I'm just upset that it used to work and now doesn't.
June 12, 20179 yr Author And again. Can't shut the server down with poweroff. No matter how hung the server may have been the powerdown script always powered it off cleanly. Whats wrong with the built in powerdown?
June 12, 20179 yr Here is a link to some older instructions. Won't bring down Dockers or VMs, but worked for me recently to cleanly being down the array. The mdcmd is no longer in /root. I think it is in /usr/local/sbin. Use the find command if that isn't right. If you run it with the argument STATUS, one of the early lines well tell you if the array is STARTED or STOPPED. If there is a question of whether it is already stopped, that is how you can check. If one of the disks won't unmount, it is because a for is open. You'll have to try and close it, but with luck you can bring down the array and avoid an unclean shutdown. The reboot command will do as the name implies, no muss no fuss.
June 12, 20179 yr Author I think that's the problem, it's docker hanging, and personally I think it's a big one. I tried everything to kill docker, nothing worked. And therefore had to hard power down. So if docker or VM get out of control then you are forced to do a hard shutdown. And I swear in 6.2 with power down plugin it didn't have any trouble with that. Or I never had docker hang. Either way it really kills the stability of unRAID. I used it for a long time and way back plugin could cause unraid to lock up and forcing a hard shutdown. With the advent of dockers the whole idea was to isolate these additions to the base unRAID and not allow them to hurt the stability of unRAID. Sure you can argue there is nothing wrong with unRaid and its adding "crap" (plugins, VM, docker) is the cause of the instability, but limetech added those features to improve unRAID's feature set, attract more people and allow way more functionality. Therefore limetech should handle how they effect unraid. If hanging docker can't be killed for some technical reason then I guess we will have to live with that unfortunately but it's really painful to have unraid's stability take a hit for it. Sent from my SM-N900W8 using Tapatalk
June 12, 20179 yr Here is a better version of the shutdown from the command line instructions. I replaced my router, and was unable to connect via Web GUI. This got me through with no parity check. https://wiki.lime-technology.com/Console#To_cleanly_Stop_the_array_from_the_command_line
June 12, 20179 yr Author I've used that before successfully but forgot about it. I'll try it next time. So this will hopefully bring the array offline cleanly and the hard shut down won't cause a parity check. I wonder if this will work with docker/VMs running and possibly writing the the array.Thank you bjp999Sent from my SM-N900W8 using Tapatalk
August 15, 20187 yr Author Well got a hung server again. No trouble accessing via telnet but both powderdown and poweroff don't do anything. I don't see how there should ever be a scenario where one has access to issue commands but none are good enough to cleanly shutdown the array. I of course tried various things, but eventually lost telnet access and had to do a hard shutdown.
August 15, 20187 yr 4 hours ago, bnevets27 said: I don't see how there should ever be a scenario where one has access to issue commands but none are good enough to cleanly shutdown the array. It's mostly caused by some process being hung inside the kernel with process state 'D' which is a non-interruptible wait. It's hard to know if it's caused by a hardware bug, a software bug or some random glitch like a memory bit error or power surge. So you can check with ps if you have any threads hanging in this state. And there just is no way to kill them, which makes Linux unable to unmount and shutdown gracefully.
August 16, 20187 yr Author Thank you pwm. I haven't had anyone explain why this might happen before. Next time I'll try that out. What would be the exact command to run?
Archived
This topic is now archived and is closed to further replies.