Hi all - I've been running unRAID for a few years now and am really happy with the product.  I recently did some juggling around and rebuilt my array on the existing hardware with nine 2TB drives, running each through three preclears.  I also took the opportunity to update to 5.0.6 as I think I was still running one of the 5.0beta versions.

 

In transferring files to this new array, three times now the server has stopped responding during the copy process, and I'll come home to find the failed copy message in FastCopy, the drive mapping unresponsive in Windows, and the server itself with a blank screen.  Can't ping it or connect via putty etc.  Otherwise it still appears to be running: power is still on, lights on the NIC and the raid card, and my USB stick which also lights up is still getting power.  If I reboot, the array can be restarted and after a parity check is apparently fine.

 

I'm wondering if these are symptoms of a failing USB stick?  Before I go scrounging up spare RAM, changing NICs etc I thought this might be the culprit.

The USB mostly just gets read on boot and gets written when you change some setting. unRAID itself runs completely in RAM after it unpacks itself from the USB stick when it first boots up.

 

Post a syslog.

Be sure to read the first post in this thread:

 

    http://lime-technology.com/forum/index.php?topic=9880.0

 

Particularly the section about 'hanging systems'.

Thanks for pointing me to that thread.  I created the syslog as you suggested across the putty session, and then waited until the parity check was completed.  You can see those last two entries in the log.  I then initiated a file copy this morning, and now that I've returned home about 10 hours later the server has fallen off the network again.  Unfortunately, no new entries were added to the log.

syslog.zip

Thanks for pointing me to that thread.  I created the syslog as you suggested across the putty session, and then waited until the parity check was completed.  You can see those last two entries in the log.  I then initiated a file copy this morning, and now that I've returned home about 10 hours later the server has fallen off the network again.  Unfortunately, no new entries were added to the log.

 

Be sure to read the first post in this thread:

 

    http://lime-technology.com/forum/index.php?topic=9880.0

 

Particularly the section about 'hanging systems'.

 

In cases like this, wouldn't it be better to run the command locally at the server instead of through putty?  If the crash takes out the network right away, you'd never see anything through putty.  And thats the case here.

 

I would hook up a keyboard and monitor to the system and then try running this command:

 

 tail -f -n 100 /var/log/syslog > /boot/syslog.txt

 

You won't see anything happen on the screen at all, but the contents will be continually saved to a file on your flashdrive called syslog.txt

 

There might be some more information getting it this way

 

Barring that, I find it strange that there was no syslog entries between January 10 @17:30 and this morning when you started file copies.  Not even routine spin down messages.

 

If the computer that you're running putty on happens to go to sleep or something, then the putty connection is going to wind up being closed, and any entries after that are lost.

 

Running local is the safest method.

 

NB:  That thread link about capturing the syslog is a bit dated.  I think the instructions here: http://lime-technology.com/wiki/index.php/Troubleshooting#Capturing_your_syslog are more up to date

There was a large time gap as I was hoping the system would fall off the network doing nothing like it did last time, but as it was still running this morning I decided to force the issue by initiating the copy.  As for the spindown, I disabled that option for this RAID array as I thought that's why my first copy might have failed; turns out the spindown had nothing to do with it, but I haven't turned it back on yet.