I tried installing a plugin while running rc3 (and other previous versions), and when the plugin tries to download an install files needed for SABnzbd, the monitor connected to the unRAID box spits out some errors, and information that would be useful to my tracking down the problem.

 

However, it's only displayed on this monitor.  I cannot find any file containing these messages so i can see all the issues, and try to fix.  I could take pictures with my camera, and type out the messages, but it's error prone, and time consuming, and surely unnecessary.  Not to mention, I can't see all the messages, since they've scrolled off the screen.

 

I've inquired about how to find the logs in the plugin post, but no responses yet.

 

http://lime-technology.com/forum/index.php?topic=19654.msg178760#msg178760

 

Where might I find the logs?

 

syslog.zip

I tried installing a plugin while running rc3 (and other previous versions), and when the plugin tries to download an install files needed for SABnzbd, the monitor connected to the unRAID box spits out some errors, and information that would be useful to my tracking down the problem.

 

However, it's only displayed on this monitor.  I cannot find any file containing these messages so i can see all the issues, and try to fix.  I could take pictures with my camera, and type out the messages, but it's error prone, and time consuming, and surely unnecessary.  Not to mention, I can't see all the messages, since they've scrolled off the screen.

 

I've inquired about how to find the logs in the plugin post, but no responses yet.

 

http://lime-technology.com/forum/index.php?topic=19654.msg178760#msg178760

 

Where might I find the logs?

 

The most important log is the one you attached, the syslog.  There is a little more info in a dmesg listing.  At a console prompt, type:  dmesg >/boot/dmesg.txt  (I think), which should save the dmesg listing to your flash drive.  And you can see some of what scrolled off the screen by using the Sh-PgUp and Sh-PgDn keys.  The most important though is the syslog.

 

Looking at your syslog, you are having serious bad sector problems with your Cache drive (SAMSUNG HD103UJ S13PJDWS337885), and they are slowing disk and mover operations way down.  See my signature for the Troubleshooting link, for instructions for obtaining a SMART report, then running the long SMART test on your Cache drive, plus another SMART report after the test.

Thanks for the advice.  I ran the SMART report (well, I started it, then re-read your post, stopped it at 10%, then ran the report), and it seems like the old drive has seen better days.

 

It's an old drive, and could be replaced.  I'm just finishing up a weekly parity check, then will run the full SMART report, and post up results.

 

As for the dmesg >/boot/dmesg.txt suggestion; it worked, in that it created that report, but none of the information about the installation of the plugins was in that one.

 

I was able to get my immediate need resolved by walking between rooms to read the messages, but one day I'm going to spend some time trying to write/amend some plugins, and will need easier access to these logs ('cause I expect to make lots of mistakes ), so I'm hoping someone can tell me how to find or create them.

 

thanks again.

Looks ominous.  I suppose I'll have to check on it's warranty status, and find the mfg test for it.

 

thanks for mentioning it.

 

still looking for those logs

smart.txt

No need for the mfg. test...almost dead-

 

ID# ATTRIBUTE_NAME          FLAG    VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE

187 Reported_Uncorrect      0x0032  100  100  000    Old_age  Always      -      1396

188 Command_Timeout        0x0032  100  100  000    Old_age  Always      -      0

190 Airflow_Temperature_Cel 0x0022  072  054  000    Old_age  Always      -      28 (Min/Max 24/30)

194 Temperature_Celsius    0x0022  071  054  000    Old_age  Always      -      29 (Min/Max 23/32)

195 Hardware_ECC_Recovered  0x001a  100  100  000    Old_age  Always      -      7396134

196 Reallocated_Event_Count 0x0032  099  099  000    Old_age  Always      -      51

197 Current_Pending_Sector  0x0012  100  099  000    Old_age  Always      -      10

198 Offline_Uncorrectable  0x0030  100  100  000    Old_age  Offline      -      1

This drive is not really that bad.  It does have a few sector issues, but apart from that looks very good still.  I suppose I look at problems like this from my own perspective, which is of someone that is a lot poorer than most unRAID users, so I have always been willing to live with small issues.  Modern drives come with several thousand spare sectors, to use in place of any that begin to go bad.  I sometimes wish I could have some of the drives that other users so quickly trash, over what looks to me to be a minor blip in its stats.

 

Concerning Justin's drive, yes, Reallocated_Event_Count is 51, but he has not yet had a single sector reallocated!  Normally, that count coincides with the number of sectors reallocated, so I'm not sure what this particular SMART programmer is counting.  The uncorrectable sectors are not necessarily physically bad sectors, they may only be scrambled by a power spike or power outage during a write.  Once the sector is rewritten and tested, if the sector proves to be fine, then it is no longer counted as bad (or as a Current_Pending_Sector).  Because of what I saw in the syslog, I suspect you do have some truly bad sectors, but no more than 10, if that many.

 

What I would recommend is to unassign your Cache drive, then Preclear it at least twice.  I would expect the first pass to force the drive to remap some or all 10 of those Current_Pending_Sectors, replacing them with good sectors, and clearing Current_Pending_Sector.  Then the second pass should prove whether there are any more.  If no numbers change on the second pass, you can put it back online.

JustinChase, most plugins do not write to syslog. I think later on once plug-ins are more robust and out of their infancy, there will be more tools in place to make this easier, but for now every aspect of the plug-in would have to be directed to the logger in order to be written to the syslog.

 

With that out of the way, the easiest way to get the errors is to do everything through telnet. You can open two instances, have one running the command

tail -f /var/log/syslog

That will let you immediately see when something is written to the syslog(again, won't be extremely helpful with plug-ins, but something of interest might pop up, so just in case)

 

Next, manually install plug-ins your working on or having problems with from telnet, for example:

installplg /boot/config/plugins/mytestplugin.plg

 

You'll see most errors dealing with the specific installation of the plug-in from that, such as errors creating files, downloading files, or copying/deleting anything.

 

Now most plug-ins make use of a rc.d script for certain functions. For example, sabnzbd uses a rc script for installation, writing config, enabling or disabling the plug-in, and update checks. If it is one of these areas your having an issue with, you can invoke that script as well to see errors with it.

 

If you start sabnzbd from the webgui, it may hang, but no errors will be printed letting you know WHY its hanging. Now if you want to know what errors it has, you could do this:

/etc/rc.d/rc.sabnzbd start

 

If there is an error starting sabnzbd, be it a typo or error in the script, or issues accessing a certain file or directory, the error will be printed on the screen. You can copy/paste this where you need it from there.