-
Notifications
You must be signed in to change notification settings - Fork 14
Troubleshooting Tips
Common problems with plug-ins are:
* Array stuck as starting * Plug-in cannot start * All my information is lost on reboot! * I can run as root, but not as nobody
These problems are often ran into by new users, and are definitely frustrating.
This is usually caused by a plug-in starting before the array can initialize. In order for a plug-in's configuration or data to be persistent through reboots and shutdowns, they must be saved on a disk. This is because by default plug-ins are installed to /usr/local. Since UNraid is ran from ram, during a shutdown or reboot everything in the filesystem is wiped and consequently lost.
In order for data to be persistent, it is recommended to set the data directory for your plug-ins to a disk, either a cache drive(if running Plus or Pro), on the array, or on an auto-mounted drive outside of unraid.
The easiest method is to use the cache drive. This is because the drive is mounted when it is discovered during boot, so is almost always mounted before a plug-in initializes.
When installing to the array, often times the plug-ins initialize before the array can start. Since the array uses Fuse, it starts after the disks are mounted. When this happens, the plug-in creates the path for its data directory, which is usually something like "/mnt/user/apps". When Fuse starts to bring the array online, it tries to create "/mnt/user". Since this already exists, fuse hangs and cannot continue(expecting the directory to be empty).
One way around this is to place your plug-ins that must use the array in a separate folder, and add a few lines to your go file.
For example:#go file #install plug-ins after all other commands run installplg /boot/config/plugins/manualstart/couchpotato.plg installplg /boot/config/plugins/manualstart/sickbeard.plg #start plug-ins since disks_mounted event already fired /etc/rc.d/rc.couchpotato start /etc/rc.d/rc.sickbeard start
This is a little more advanced usage, since the average user will(and should) never know the rc.x commands. They are easily found by invoking the script, reading them from the plugin in a text editor, or asking how to set it up in the forums.
It is also possible to use a disk mounted outside of the array, either by adding commands to the go file, or using the plug-in "SNAP". I will not go into this method as I have never used it and better advice would be given from the SNAP author.
Sometimes, and I try to make sure it happens as little as possible, the plug-in just doesn't start. This is most commonly due to improper permissions. If the plug-in tries to invoke a script that is non-executable, it will fail. Also, if a directory's permissions have been altered for some reason, most times the plug-in will fail. This happens if the user logs in via telnet(as root) and interacts with the directory. This changes the owner to root, and the plug-in might not have access(depending on permissions).
Other times, which happens less, the plug-ins fail to download a file. This is something that needs to be changed in the plug-in architecture and authors cannot do anything about at the present time, but if a file fails to download, I will try to correct the issue if its in my power. Some times this may be a file I host, other times it may be a package hosted by someone else. In a recent case, the URL structure changed, so I had to change the code to fit. If you notice this, please do let me know and I will fix it as soon as possible!
Its horrible, I know, you've finally got everything set up exactly how you like it, its been running great for days! You reboot your server, and when it comes back up....everything is gone!
This happens if your data directory is set to a non-persistent location. Anything in the linux file system is non-persistent when it comes to UNraid. This is because UNraid runs in ram. As previously mentioned, your data directories must be located on a physical disk to survive a reboot. In any of my plug-ins that a data directory is necessary, I have added a message indicating whether or not your data will survive a reboot.
If a message indicates your data will NOT survive a reboot, post on the forum if you are unsure where to put it and either I or another user will be glad to help.
There can be a few reasons for this...
One reason is the plug-in runs on a user-specified port, and the user has chosen a port lower than 1024. Any port below this is reserved for system use and only the root user has access. So, if you try, the plug-in will fail to run unless ran as root!
Another reason(and the most frequent), is a directory the plug-in needs access to is owned by root, and doesn't have permissions allowing other users to access the directory. If this is the case, depending on the directory, you can either take ownership of the directory, or change its permissions. Some directories are best left owned by root. This is for the security of your system. If you are unsure, post to the forums and we will help.
If you are unsure of a problem, here are a few commands that will help:
#copy syslog to flash so you can post to the forums cp /var/log/syslog /boot/syslog.txt #check permissions of a directory, as well as what files are there ls -l /path/to/directory #list all packages that auto install on your system ls /boot/packages/*.auto_install #list all plug-ins that auto install ls /boot/config/plugins/
Those commands will answer some commonly asked questions, you don't have to run them all and post them every time you have a question or a problem, but if you do need them, there they are.