I have been running UnRaid 4.5 since January on a custom built PC. It has been running smoothly so far, but last night I noticed the following error appear in the logs:

 

lsof[8314]: segfault at 41383a6f ip 0805b0b7 sp bfe4e2d8 error 6 in lsof[8048000+18000]

rsync[8366] general protection ip:80641d5 sp:bfb437ac error:0 in rsync[8048000+52000]

 

I should probably add that I have UnMenu installed as well as some packages, most notably MySQL. I actually only noticed this error as the MySQL package didn’t automatically install on boot as it has done all year. Clicking install on the packages page installs the MySQL package successfully and it still says it will be installed on every boot, but when I restarted the server the package still needed to be manually installed. It was at this stage that I looked through the syslog and seen these messages marked as errors. I have not seen them before whenever I have looked at the logs.

 

I’m not sure if it’s related, but about a month ago I upgraded the parity drive to a 2TB WD and added the old 1TB Seagate parity drive as a new storage drive. I also have performed a parity check, as I do at the end of every month, and it produced no errors. I can provide more detailed logs or system specs if that would be of help.

 

Thanks in advance for any help or advice.

syslog-2010-11-30.txt

I have been running UnRaid 4.5 since January on a custom built PC. It has been running smoothly so far, but last night I noticed the following error appear in the logs:

 

lsof[8314]: segfault at 41383a6f ip 0805b0b7 sp bfe4e2d8 error 6 in lsof[8048000+18000]

rsync[8366] general protection ip:80641d5 sp:bfb437ac error:0 in rsync[8048000+52000]

 

I should probably add that I have UnMenu installed as well as some packages, most notably MySQL. I actually only noticed this error as the MySQL package didn’t automatically install on boot as it has done all year. Clicking install on the packages page installs the MySQL package successfully and it still says it will be installed on every boot, but when I restarted the server the package still needed to be manually installed. It was at this stage that I looked through the syslog and seen these messages marked as errors. I have not seen them before whenever I have looked at the logs.

 

I’m not sure if it’s related, but about a month ago I upgraded the parity drive to a 2TB WD and added the old 1TB Seagate parity drive as a new storage drive. I also have performed a parity check, as I do at the end of every month, and it produced no errors. I can provide more detailed logs or system specs if that would be of help.

 

Thanks in advance for any help or advice.

 

We have no idea since you did not attach the syslog for analysis.  Odds are you are running out of memory, but it could also be bad memory.  Run a memory test, preferably overnight.  A segmentation fault is cause by a program attempting to access memory it does not own.  It could just as easily be a bug in a specific program. 

 

Joe L.

Thanks for the response. I have attached the syslog now. This might be a stupid question, but how do I run a memory test (Do I run memtest)?

how do I run a memory test (Do I run memtest)?

 

Yes, from the boot menu.  You will reboot the server and select memtest from the list, instead of letting it boot unRAID.  You should let memtest run overnight to make sure everything works.

Thanks for the response. I have attached the syslog now. This might be a stupid question, but how do I run a memory test (Do I run memtest)?

 

Reboot you unraid, then you get a menu with 2 choices:

- Unraid

- memtest86+

 

If you do not make a choice here the system automaticly boots after a couple of seconds in to unraid

 

To do the memtest select the second optionm called memtest86+

Thanks. I guess I will have to dig out a monitor then, as I run the server headless!

Just a quick update. I started a memtest last night and it was 40% completed when I looked at it this morning. There were about 50 million errors reported so far so I’m guessing one or more of the ram sticks is probably gone.

Just a quick update. I started a memtest last night and it was 40% completed when I looked at it this morning. There were about 50 million errors reported so far so I’m guessing one or more of the ram sticks is probably gone.

It would only take 1 reported error to warrant replacing the defective RAM.

 

I'd say you now have 50 million reasons...  

 

Isn't it great when the solutions are so simple.   You might check the RAM timing, voltage, and clock speed settings in the BIOS.  It might be perfectly good RAM but with the parameters in the BIOS set completely wrong for it to operate properly.

The BIOS is supposed to set it for you, but many do not.  Some motherboards do not have the ability to configure the correct settings needed for many RAM strips, especially when the strips need higher voltage than usual.    The settings must be as needed by your SPECIFIC make/model RAM strips. (or, it could be a bad RAM strip.  Process of elimination will tell.)

 

Joe L.

It certainly is nice when the solution is so simple. Removed the offending RAM chip and ran through memtest again. Everything passed this time and there are no errors being produced in the syslog. Thanks everyone for the help.