MethodCall Posted January 4, 2018 Share Posted January 4, 2018 (edited) Running unRAID 6.3.5 Originally, I was getting the (fantastically unhelpful) "Execution Failed" message when I would try to start any of my Docker containers after stopping them (at this point they seemed to be autostarting successfully on server startup). Following the prescribed methods, I blew away my Docker image file, re-created it, and then re-created all of my Docker containers. Everything seemed to be fine for a bit then I started to get the "Execution Failed" message again. Now, after restarting the server with no other changes made I cannot access the GUI any longer. When I try to access it, it just clocks indefinitely (no page appears, no login prompt). Docker Containers: Couch Potato (based on some of the stuff in the logs, a likely culprit), Radarr, Sonarr, PMS, MySQL, and SABnzbd. All from linuxserver.io, all set to auto-start except for MySQL. I can still Telnet into the box without any issue and all of my SMB shares appear to be fully accessible. None of the GUIs for any of my Docker applications come up, either, though they do not clock - they fail immediately. The Docker tomfoolery and the GUI nonsense aren't necessarily related but that sure seems unlikely. I know far too little about unRAID, Docker, or Linux to troubleshoot this further. Please help if you can! newbsauce-diagnostics-20180104-1314.zip Edited January 4, 2018 by MethodCall Quote Link to comment
JorgeB Posted January 4, 2018 Share Posted January 4, 2018 Your cache filesystem is completely allocated resulting in ENOSPC errors, see here for how to proceed: https://lime-technology.com/forums/topic/62230-out-of-space-errors-on-cache-drive/?do=findComment&comment=610551 1 Quote Link to comment
MethodCall Posted January 4, 2018 Author Share Posted January 4, 2018 10 minutes ago, johnnie.black said: Your cache filesystem is completely allocated resulting in ENOSPC errors I have *literally* no idea what that means...but I'll dig into that thread, as you suggest. Thank ya, sir. Quote Link to comment
MethodCall Posted January 4, 2018 Author Share Posted January 4, 2018 I did have to nuke some downloads to make space for the process, but I have completed a balance -dusage=75 without an error. To anyone performing this in the future, as that -dusage percentage goes up... so does the time it takes to complete. That last one at 75% took *at least* 20 minutes. Restarting the server now to see if this did the trick. *crosses fingers* Quote Link to comment
MethodCall Posted January 4, 2018 Author Share Posted January 4, 2018 Damn. No joy. GUI is still clocking infinitely. New Diagnostics ZIP attached. newbsauce-diagnostics-20180104-1534.zip Quote Link to comment
JorgeB Posted January 4, 2018 Share Posted January 4, 2018 Forgot to add that you'll need to delete recreate docker image after the balance. 1 Quote Link to comment
JorgeB Posted January 4, 2018 Share Posted January 4, 2018 And make sure to reboot also 1 Quote Link to comment
MethodCall Posted January 4, 2018 Author Share Posted January 4, 2018 1 minute ago, johnnie.black said: Forgot to add that you'll need to delete recreate docker image after the balance. Will deleting it via mc be sufficient? As far as re-creating it, I don't know how to do that outside of the GUI (which I still can't get back to) but if you can gimme the commands, I'll throw 'em at Putty. You think something with Docker is breaking the GUI? 1 minute ago, johnnie.black said: And make sure to reboot also I rebooted the box after the balancing, you want me to reboot after deleting the Docker image, or after deleting and re-creating the Docker image? Quote Link to comment
JorgeB Posted January 4, 2018 Share Posted January 4, 2018 Try this: With mc navigate to and edit /boot/config/docker.cfg and change DOCKER_ENABLE to "no", reboot and if the GUI is working delete and recreate de docker image, if the GUI still doesn't work grab new diags by typing diagnostics on the console. 1 Quote Link to comment
MethodCall Posted January 4, 2018 Author Share Posted January 4, 2018 Edited & saved. Rebooted. Reopened docker.cfg after reboot to confirm that the edit took (it had). GUI is *still* clocking. Good grief, what have I done to my server? New diags attached... newbsauce-diagnostics-20180104-1602.zip Quote Link to comment
JorgeB Posted January 4, 2018 Share Posted January 4, 2018 Diags are the old ones. 1 Quote Link to comment
JorgeB Posted January 4, 2018 Share Posted January 4, 2018 Or you haven't reboot yet 1 Quote Link to comment
MethodCall Posted January 4, 2018 Author Share Posted January 4, 2018 Interesting. (In a bad way.) Tried to shut down the server with powerdown (instead of the powerdown -r's I've been doing all along) to make absolutely sure it restarted. So I physically went over to the server (since I was gonna have to hit the power switch to turn it back on, obviously). It hadn't shut down. Reconnect with Putty...sure enough, still up. Tell it to powerdown again. Nothing. I mean, the CLI is telling me that it's going down, got the broadcast message like usual...but the front of the server's chassis is still a frickin' christmas tree. No actual shut down is taking place. So, I kill it by holding down the power switch. It goes down for real. Hit the switch again to power it up...wait a bit for it to post annnnnnndd.....the GUI is accessible again. I'm questioning whether or not ANY of my previous powerdown -r's ever actually rebooted anything or not, now. Lesson learned...get visual confirmation on shut downs. So.... delete and re-create my docker image, I'm assuming? Quote Link to comment
bonienl Posted January 4, 2018 Share Posted January 4, 2018 The powerdown command is obsolete. With unRAID6 use poweroff - to do a clean shutdown of the server reboot - to do a clean restart of the server 1 Quote Link to comment
JorgeB Posted January 4, 2018 Share Posted January 4, 2018 5 minutes ago, MethodCall said: I'm questioning whether or not ANY of my previous powerdown -r's ever actually rebooted anything or not Not the ones from today, syslog started yesterday. 6 minutes ago, MethodCall said: So.... delete and re-create my docker image, I'm assuming? If all is working maybe not needed, but since it's easy and just in case I still recommend doing it. Quote Link to comment
MethodCall Posted January 4, 2018 Author Share Posted January 4, 2018 Just now, bonienl said: The powerdown command is obsolete. With unRAID6 use poweroff - to do a clean shutdown of the server reboot - to do a clean restart of the server *facepalm* Hey, Lime....maybe an error message inside the CLI would more effectively communicate that....instead of the broadcast message that gives other-than-true feedback to the user. Just a thought. *sigh* Good info, Bonienl. That is *definitely* something I need to know. Appreciate it! Quote Link to comment
MethodCall Posted January 4, 2018 Author Share Posted January 4, 2018 4 minutes ago, johnnie.black said: If all is working maybe not needed, but since it's easy and just in case I still recommend doing it. Yeah, no more assumptions from me. DEFINITELY making sure. 100%. Quote Link to comment
MethodCall Posted January 4, 2018 Author Share Posted January 4, 2018 It seems as though everything is back to normal operation. Man, I can't thank you enough, Johnnie. There is pretty much *zero* chance I would have figured out the problem without ya. If I could sling more upvotes your way, I would...but I have literally hit the daily limit. Top shelf, son. TOP SHELF. Quote Link to comment
JorgeB Posted January 5, 2018 Share Posted January 5, 2018 Good, while on v6.3.5 it's good practice to schedule a weekly balance with -dusage=75 to keep the filesystem allocation under control, this issue it's supposedly fixed on the newer kernel used on v6.4, though still early to say if it's really fixed or not. 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.