January 21, 201115 yr I am pretty new to unraid. However, I've been doing unix and scripting for a long time. I have mostly used the default GUI, but there are a lot of nice things in unMenu. My issue is this. I am running the latest unmenu with the updates Joe put in on the 17th. In the "Array Management" menu, the first option is Stop Array "Stop the unRAID array. Note: you must use the Lime-Technology supplied unRAID management web-page to Start the array." When I click this.. oh something stops alright. My link to the machine goes away. When I use the console to get in, I look at the nic and it's good. But the entire routing table is gone. I literally have to readd the routing table by hand to get it back (or reboot). Anyone else see this? I must admit I have made a lot of my own modifications.. but in a custom dir. I just have the go script call my own executable which loads my own stuff. I commented it out so it would run unmenu clean.. and it does the same thing. I guess it's possible unmenu got corrupted somehow, but I don't see how. I'll try a reload of it in a bit. Want to see if anyone else has the same issue.
January 21, 201115 yr I am pretty new to unraid. However, I've been doing unix and scripting for a long time. I have mostly used the default GUI, but there are a lot of nice things in unMenu. My issue is this. I am running the latest unmenu with the updates Joe put in on the 17th. In the "Array Management" menu, the first option is Stop Array "Stop the unRAID array. Note: you must use the Lime-Technology supplied unRAID management web-page to Start the array." When I click this.. oh something stops alright. My link to the machine goes away. When I use the console to get in, I look at the nic and it's good. But the entire routing table is gone. I literally have to readd the routing table by hand to get it back (or reboot). Anyone else see this? I must admit I have made a lot of my own modifications.. but in a custom dir. I just have the go script call my own executable which loads my own stuff. I commented it out so it would run unmenu clean.. and it does the same thing. I guess it's possible unmenu got corrupted somehow, but I don't see how. I'll try a reload of it in a bit. Want to see if anyone else has the same issue. The "Stop server" button basically spins up all the disks syncs them stops SAMBA kills shfs (the user share file system) unmounts all the disks, killing any process holding them busy. stops the unRAID array moves /etc/samba/smb-shares.conf to /etc/samba/smb-shares.old_conf re-starts SAMBA If your "network management" was initiated by you when you were "cd'd to a disk, it might easily get killed before the disk gets un-mounted. The goal of that button is to allow you to safely stop the server when the unRAID console has stopped responding. unMENU has not explicitly done anything to the routing table. (on the other hand, I never cared about it, as I do not hand load it) Joe L.
January 21, 201115 yr Author The thing is I'm not CD'd anywhere. I boot the machine, it runs the uu from the go script. I open a window to 8080 and hit that button and boom. I hear a few beeps. and can no longer connect to it. I don't mean unmenu is gone, I mean look at the box and emhttp is gone too. (process is no longer tied to port 80) I can generally debug stuff, but awk.. is kinda an unforgiving language I am reloading a vanilla build on my usb stick and will see if I have any different results. Maybe it's something that got messed up when I copied my files from one usb to another. I just wondered if anyone else had seen this.
January 21, 201115 yr Author I'm not sure exactly what is going on: New unwrapped flash drive. Installed: Unraid AIO 4.6 (current release). New install, I copied over is my config dir. (has static IP, root password, disks, and shares set in it) No one is accessing ANYTHING. Fresh install of unmenu to /boot/unmenu via these instructions: https://code.google.com/p/unraid-unmenu/ Start unmenu /boot/unmenu/uu cd to home (cd) root@Tower:~# ifconfig -a eth0 Link encap:Ethernet HWaddr 00:30:48:b1:c4:3f inet addr:192.168.1.90 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2796 errors:0 dropped:0 overruns:0 frame:0 TX packets:2634 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1646731 (1.5 MiB) TX bytes:269996 (263.6 KiB) Interrupt:26 Base address:0xe000 root@Tower:~# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo default 192.168.1.1 0.0.0.0 UG 1 0 0 eth0 root@Tower:~# Open a window to //tower. Everything looks good. Disks are up, spinning, parity good, array all green. Add :8080 to the end. Looks all good. Change to Array management and I click that button: root@Tower:~# Connection closed by foreign host. Went to the console, and dumped the route table into the /boot dir to paste in: root@Tower:/boot# cat outfile Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface loopback * 255.0.0.0 U 0 0 0 lo I note, emhttp is GONE, dead. So I no longer can control the array, at all except by logging into the console and issuing cli commands. Something fishy is going on.
February 23, 201115 yr I am seeing very similar (if not the same) behaviour. When I hit stop array in unRAID, it seems to retry forever. So I tried to use stop array in unmenu instead. It seems to kill unmenu, AND unRAID, AND telnet AND ssh. I can still ping the box. I am running /boot/unmenu/uu from my go script. I have installed a few extra packages. SABnzbd and Sick Beard are running on /mnt/cache, and the rest are air video, bwm-ng, ds_store_cleanup, istat, mail/ssmtp, unraid status alerts by email, monthly parity check, modified mover script, openssh, pci utils, power down on over temp, clean power down, screen, vim, and the cache dirs script. Of those, I guess only SABnzbd, Sick Beard and maybe iStat would be using the array? I don't see why killing any of those would kill unmenu, or the unraid interface, or telnet and ssh. Edit: I also tried to hit the physical power button to shut down clean, but nothing happens. If I hold it down 4 seconds, it shuts down immediately (not clean). ACPI or whatever it is called is enabled in the BIOS.
February 23, 201115 yr Author Yep, its borked. I tried it on a whole new setup. From scratch. Nothing we can do until a fix gets in. emhttp isn't up so the whole thing is just trashed. I recommend just not hitting that button Instead if you need to shut it down by some method, I just use the climenu.
February 23, 201115 yr You're under a misunderstanding that the unMENU's Stop button solves all your problems. It does not. What it does do is KILL all processes holding disks busy. If one of those is emhttp, well, it was just doing what it was supposed to do. YOU are responsible for terminating any ADD-ONs before attempting to stop the array. If you cannot stop the array using the normal unMENU "Stop" button, then the unMENU button is just to give you a change to stop the array sanely. It does not guarantee connectivity afterwards. It will attempt to kill processes holding disks busy, and then un-mount the disks, and finally stop the unRAID array. If you find a better method... cool. It should get easier once the 5.0 series is stable and we can reliably tie into its events. Joe L.
February 23, 201115 yr You're under a misunderstanding that the unMENU's Stop button solves all your problems. It does not. What it does do is KILL all processes holding disks busy. If one of those is emhttp, well, it was just doing what it was supposed to do. YOU are responsible for terminating any ADD-ONs before attempting to stop the array. If you cannot stop the array using the normal unMENU "Stop" button, then the unMENU button is just to give you a change to stop the array sanely. It does not guarantee connectivity afterwards. It will attempt to kill processes holding disks busy, and then un-mount the disks, and finally stop the unRAID array. If you find a better method... cool. It should get easier once the 5.0 series is stable and we can reliably tie into its events. Joe L. I understand what the unmenu stop array button is supposed to do - kill processes to stop the array. I don't understand why the unraid web interface, the unmenu interface, telnet and ssh would all be using the array and thus, be killed. If I had an open ssh connection and I /mnt/cache was my cwd, would my ssh connection be terminated, or the whole ssh daemon? For telnet, I don't even use it. When I install Sick Beard (and SABnzbd) it does do cd /mnt/cache/.sickbeard before starting the application at the end of the installation script. Does that mean that after installing for the first time, Sick Beard is running under the unmenu process, and therefore the unmenu process is now linked to an open file on the array? I assume that this wouldn't be the case after rebooting, because the *.auto_install scripts are called by /boot/config/go (not by the unmenu process)? As for the unraid web interface, could this be killed because emhttp is started by the same process that starts unmenu from /boot/config/go? Could it be that because unmenu starts Sick Beard during installation, then unmenu AND the script that called unmenu (which also called emhttp) is linked to an open file on the array, along with anything else started by /boot/config/go, and everything is killed? So the answer would be to manually stop anything that uses the array and is started by /boot/config/go, before pressing stop array from unmenu? If so, perhaps there should be two go scripts - one to start essential connectivity services (emhttp) and one to start addons, so that the essential services are not linked to open files on the array by various addons? Also, last night when I used the stop array button in unmenu and found that everything was killed, it seems that the array WASN'T stopped. Like I said, I couldn't connect to reboot the machine cleanly. I tried the power button, but it only shut off the machine (uncleanly) after 4 seconds. When it came back up, a parity check was triggered. If unmenu stop array had stopped the array (as well as killing telnet, ssh, etc), then a cold reboot should not have resulted in a parity check? Perhaps since unmenu stop array is supposed to kill processes and then stop the array, when one of the processes was unmenu itself, it was unable to stop the array? Perhaps unmenu could kill all processes EXCEPT for its own process or its parent process in a loop, which should eventually result unlinking the unmenu process from the array without killing unmenu? E.g. Sick Beard does shut down cleanly when it receives a kill signal. If unmenu killed Sick Beard before killing itself or its parent process, then unmenu and its parent process would no longer be linked to an open file on the array? I'm not very familiar with linux specifics, though, so I am only speculating. Please correct me if I am wrong. Cheers.
February 24, 201115 yr You're under a misunderstanding that the unMENU's Stop button solves all your problems. It does not. What it does do is KILL all processes holding disks busy. If one of those is emhttp, well, it was just doing what it was supposed to do. YOU are responsible for terminating any ADD-ONs before attempting to stop the array. If you cannot stop the array using the normal unMENU "Stop" button, then the unMENU button is just to give you a change to stop the array sanely. It does not guarantee connectivity afterwards. It will attempt to kill processes holding disks busy, and then un-mount the disks, and finally stop the unRAID array. If you find a better method... cool. It should get easier once the 5.0 series is stable and we can reliably tie into its events. Joe L. I understand what the unmenu stop array button is supposed to do - kill processes to stop the array. I don't understand why the unraid web interface, the unmenu interface, telnet and ssh would all be using the array and thus, be killed. If I had an open ssh connection and I /mnt/cache was my cwd, would my ssh connection be terminated, or the whole ssh daemon? At least the process whose cwd is on the cache drive. I do not know if the ssh daemon changes directory. Never looked. For telnet, I don't even use it. When I install Sick Beard (and SABnzbd) it does do cd /mnt/cache/.sickbeard before starting the application at the end of the installation script. Does that mean that after installing for the first time, Sick Beard is running under the unmenu process, and therefore the unmenu process is now linked to an open file on the array? sickbeard would be killed, as its cwd is the cache drive. It is a child process of unMENU at that time unless YOU dis-associated it somehow. (Using "at" is one method, or "'dosown %%" another.) I assume that this wouldn't be the case after rebooting, because the *.auto_install scripts are called by /boot/config/go (not by the unmenu process)? As for the unraid web interface, could this be killed because emhttp is started by the same process that starts unmenu from /boot/config/go? Could it be that because unmenu starts Sick Beard during installation, then unmenu AND the script that called unmenu (which also called emhttp) is linked to an open file on the array, along with anything else started by /boot/config/go, and everything is killed? I never experimented to see. typically a parent will not terminate UNLESS the entire process group is terminated, and I do not terminate process groups. unMENI simply sends a kill -TERM pid to each of the process IDs listed in the output of fuser -cu /dev/md* So the answer would be to manually stop anything that uses the array and is started by /boot/config/go, before pressing stop array from unmenu? If so, perhaps there should be two go scripts - one to start essential connectivity services (emhttp) and one to start addons, so that the essential services are not linked to open files on the array by various addons? You've now described one of the major reasons the "event" system is being developed in unRAID 5.0. It will allow, on a "pre-array-stop" event, yo to stop your add-ons. Also, last night when I used the stop array button in unmenu and found that everything was killed, it seems that the array WASN'T stopped. Like I said, I couldn't connect to reboot the machine cleanly. I tried the power button, but it only shut off the machine (uncleanly) after 4 seconds. When it came back up, a parity check was triggered. If unmenu stop array had stopped the array (as well as killing telnet, ssh, etc), then a cold reboot should not have resulted in a parity check? Perhaps since unmenu stop array is supposed to kill processes and then stop the array, when one of the processes was unmenu itself, it was unable to stop the array? Perhaps unmenu could kill all processes EXCEPT for its own process or its parent process in a loop, which should eventually result unlinking the unmenu process from the array without killing unmenu? E.g. Sick Beard does shut down cleanly when it receives a kill signal. If unmenu killed Sick Beard before killing itself or its parent process, then unmenu and its parent process would no longer be linked to an open file on the array? I'm not very familiar with linux specifics, though, so I am only speculating. Please correct me if I am wrong. All the commands used in the "stop" button sequence are in 08-unmenu-array_mgmt.awk It is not magic. Joe L.
February 24, 201115 yr So it seems that terminating a child process of unmenu (e.g. Sick Beard) should not also terminate the parent. I'm not sure how then the unraid web interface could ever be associated with an open file on the array, since it is started by /boot/config/go and it doesn't itself open files on the array (I assume, otherwise stop from the unraid web interface would never work)? Cheers.
March 5, 201115 yr Looks like this might have been a bug in 5.0b4? The 5.0b5 change log says: webGui: fixed issue where killing background process was killing entire webGui (emhttp)
March 7, 201115 yr Author I dunno, crashes in 4.6, crashes in 4.7. Might be fixed now as I'm sure stuff gets backported. Doesn't really matter to me. The point is Joe says thats an "Emergency" option. It's not the same as the emhttp "stop" Which frankly, is good enough for me. I know not to use it!
March 9, 201115 yr I dunno, crashes in 4.6, crashes in 4.7. Might be fixed now as I'm sure stuff gets backported. Doesn't really matter to me. The point is Joe says thats an "Emergency" option. It's not the same as the emhttp "stop" Which frankly, is good enough for me. I know not to use it! So for us noobs, what does this mean? Always stop the array through unRAID main instead of anywhere else?
March 9, 201115 yr So for us noobs, what does this mean? Always stop the array through unRAID main instead of anywhere else? Try unRAID first. If you're in a hurry (running on battery power) or unRAID is waiting for processes to terminate or open files to close forever in a loop, then use unMENU to stop the array.
March 9, 201115 yr So for us noobs, what does this mean? Always stop the array through unRAID main instead of anywhere else? Try unRAID first. If you're in a hurry (running on battery power) or unRAID is waiting for processes to terminate or open files to close forever in a loop, then use unMENU to stop the array. Great, that was short and to the point So without making it too complicated, what is the difference in how the two differ? From what I read, unMENU kills all the processes linked to the array, then stops it. Does unRAID main's stop array not do that? kanth also mentioned using climenu, what's that? Also.. what are the implications of killing the routing table? Thanks.
March 9, 201115 yr From what I read, unMENU kills all the processes linked to the array, then stops it. Does unRAID main's stop array not do that? unMENU does not terminate processes keeping disks busy. It will wait almost forever for the disks to be not busy. It does not want to interrupt a process that might corrupt a file being written. The only reason unRAID will wait "almost forever" is the attempt to un-mount disks will repeat every few seconds, waiting for the disk to not be busy. Those attempts are logged in the system log. Eventually (might take days if you have a lot of RAM), the system log will use all available free RAM and the server will start to kill off processes that have been idle the longest in an attempt to free some memory. Eventually a critical process will be killed off and the server will be un-accessible. At that point you'll just have to kill power as it probably will not respond otherwise. Joe L.
March 9, 201115 yr Author So for us noobs, what does this mean? Always stop the array through unRAID main instead of anywhere else? Try unRAID first. If you're in a hurry (running on battery power) or unRAID is waiting for processes to terminate or open files to close forever in a loop, then use unMENU to stop the array. Great, that was short and to the point So without making it too complicated, what is the difference in how the two differ? From what I read, unMENU kills all the processes linked to the array, then stops it. Does unRAID main's stop array not do that? kanth also mentioned using climenu, what's that? Also.. what are the implications of killing the routing table? Thanks. When I started this topic. I had not noticed that emHttp was killed as well. What I did note is I could no longer reach my box. If you type "route" on your console, it returns a table, which basically explains how your linux box figures out that anything designated for a range of ip address is supposed to go out a set interface. Generally it looks kinda like this: route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo default 192.168.1.1 0.0.0.0 UG 1 0 0 eth0 And thus its saying to use eth0 as the default route, and use it for anything in the class C network. If its for local loopback, then internalize it. Clear as mud I expect. But basically.. its the GPS for the system. Without it.. your system doesn't know what to do when you tell it to go somewhere or receive something. So, for some reason. I cannot explain. Because it does not make sense atm... when you click that button in unmenu. After your machine dies and if you type route. All that data.. _is gone_. What did it do and ramifications? Well right now.. nothing. You see.. emHttp is gone too. And since there is not a proper, or good way to restart emHttp... you might as well reboot! I am an AIX administrator. I live in a UNIX environment for a living. I have looked over Joe's code although my AWK is child's play in comparison to his stuff. I have taken the script he runs and thrown each line separately at the machine. Nothing that his code does separately causes this to happen. I have a very difficult time understanding what is going on because AWK is a very complex language compared to what would normally be used for a large project. It is what he had to work with and I don't fault him for it. I admire him, and what he built. But my debugging ability to figure this out is somewhat limited. Add to this that emhttp.. even if it is supposed to be ripped down, should not be calling rc.net1 and rc.net2 which are responsible for this routing table. I can not find _ANY_ reason why that thing would go away. Burn the world down around it if you want.. it should stand. When I posed this query originally. I was under the impression that those buttons were just like.. "replacements" for the ones in the normal unraid menu. So Stop Unraid server was like stop the array in the other menu. It just replicated the same process. The answer is clearly. NO. It is an emergency stop for when ALL else fails. Thus, maybe the only change I would make is like our "Restore" button. DON'T use that screen. ;P Don't hit that button. The CLIMENU is another tool Joe wrote. Frankly as a tool for dealing with unraid once its gotten whacky. _I_ like it better. The reason is, most times.. whatever has whacked my box.. I can reach the console. If its been whacked somehow and unraid is still up (like a network snafu) I can't reach the unraid menu, and can't reach unmenu, but I can reach that console. I think Joe's code is here: http://lime-technology.com/wiki/index.php?title=Manage_from_Telnet However, I'd read the whole thread here: http://lime-technology.com/forum/index.php?topic=153.0 As I think ncurses isn't in the 4.6 and 4.7 releases so he has you change his tputs to something else. (I just installed ncurses).. but then I think I fixed it later. I also put in the restart code for some things at the end. So read the whole thread and modify your script accordingly. Then after that.. you have a nice, console, emergency script.
March 9, 201115 yr Have you tried the powerdown package by Weebotech. It will cleanly stop the array and shutdown the server. Has worked for me when I've had issues shutting down or just needed to do it fast. All you have to do is hit ctrl-alt-del on the server.
April 8, 201115 yr I have this problem after I installed a cache drive. The cache drive gets stuck at Unmounting... All of the symptoms such as the web interface and ssh connection being killed is happening. I have to use a keyboard that is physically attached to the machine to do a clean shutdown, but this still causes the server to check for parity when I boot up. Since this is a supported package in unRAID 4.7 Pro (which I paid money for), I expect this to be figured out, rather than saying 'it is your responsibility to terminate packages'. I've been Googling this issue for hours and have yet to find a good solution. Please provide a step-by-step solution (not plain language) to this issue or a link to the post where this specific issue has been resolved. Thanks.
April 8, 201115 yr Ok, so this seems to work fine if I disable the swap file on /mnt/cache. I figured something this simple would be supported with the cache package. I've added on line 272 of /boot/umenu/08-unmenu-array_mgmt.awk: system("swapoff -a -v"); It works fine now. Thanks for the previous posts that allowed me to piece together this solution.
April 8, 201115 yr Ok, so this seems to work fine if I disable the swap file on /mnt/cache. I figured something this simple would be supported with the cache package. I've added on line 272 of /boot/umenu/08-unmenu-array_mgmt.awk: system("swapoff -a -v"); It works fine now. Thanks for the previous posts that allowed me to piece together this solution. Sorry to say this, but you added the swap file and it is most definately NOT part of what unRAID supports. In addition, if you used the unMENU package to install the swap file the package manager has this notice: Note: You will need to disable swap on /mnt/cache before attempting to stop the unRAID array, otherwise /mnt/cache will be busy and unable to be un-mounted, and the array will not stop. To disable swap, type "swapoff -a -v" at the command prompt, or use the button on the user-scripts page if present. Therefore, the swap file you added is NOT a supported package AND it is YOUR responsibility to stop add-ons since unRAID is coded not not terminate your processes to minimize any potential for data corruption. In the 5.0 series there will eventually be hooks to have the unRAID server invoke scripts to stop user add-ons. They are one of the main reasons for the re-write, the others being a re-vamp of the security to be able to better support NFS and AFP, and a re-write of the user-interface to allow better integration of user add-ons. Joe L.
April 8, 201115 yr I have this problem after I installed a cache drive. The cache drive gets stuck at Unmounting... All of the symptoms such as the web interface and ssh connection being killed is happening. I have to use a keyboard that is physically attached to the machine to do a clean shutdown, but this still causes the server to check for parity when I boot up. Since this is a supported package in unRAID 4.7 Pro (which I paid money for), I expect this to be figured out, rather than saying 'it is your responsibility to terminate packages'. I've been Googling this issue for hours and have yet to find a good solution. Please provide a step-by-step solution (not plain language) to this issue or a link to the post where this specific issue has been resolved. Thanks. NONE of these packages are supported by unRAID, LimeTech, or anyone working for the company. unMenu, along with everything in the Customization sub-forum are addon's created by users of the system and therefore come without warranty and no guaranty that stuff will not break. You need to handle all shutdown and stopping of any addon's you have installed.
April 8, 201115 yr I have this problem after I installed a cache drive. The cache drive gets stuck at Unmounting... All of the symptoms such as the web interface and ssh connection being killed is happening. I have to use a keyboard that is physically attached to the machine to do a clean shutdown, but this still causes the server to check for parity when I boot up. Since this is a supported package in unRAID 4.7 Pro (which I paid money for), I expect this to be figured out, rather than saying 'it is your responsibility to terminate packages'. I've been Googling this issue for hours and have yet to find a good solution. Please provide a step-by-step solution (not plain language) to this issue or a link to the post where this specific issue has been resolved. Thanks. Welcome to the unRAID community forums. Please realize everyone here except the user "LimeTech" is a volunteer with no connection to the LimeTech company. This includes the moderators. The base unRAID product contains the core of the system. It maintains parity, provides the tools to create and manage the array, rebuilds failed disks, etc. The base unRAID GUI (usually //tower) is a part of the product. unmenu is a community project, with participating from many people. There is no product support for unmenu, which includes the package manager, the unmenu GUI, the myMain plugin, etc. Community members often are willing to help users with problems, but there is no guarantee of any kind. Hope you are able to solve your current challenge. Joe L. is likely the best one to help.
April 8, 201115 yr I've added on line 272 of /boot/umenu/08-unmenu-array_mgmt.awk: system("swapoff -a -v"); There should be a button on the "User-Scripts" page to disable swap whenever a swapfile is enabled. Your idea of an added line in the array management page is a good one. I'll add it when I get a bit of free time too. Joe L.
April 8, 201115 yr Thanks for your replies. I didn't realize that this forum wasn't officially supported by Lime Tech and I appreciate all of the work you're putting into it. I wasn't very happy with the product that I purchased at the time because I thought that the problems were due to the cache drive, which is a feature of the Pro version. Some advice as a professional UI designer: People don't read warnings unless they have some 'DANGER' iconography around them, with a light red background and bright right text. It has to take us out of that mode of 'hunting for the button that lets me install'. Thanks again, you guys are awesome.
Archived
This topic is now archived and is closed to further replies.