I was watching a movie and my wife was watching TV when both stopped playing.  I'm on Win10, Kodi, NFS share. She's watching on FireTV, Kodi, (from MythTV), same NFS share.  Now the Unraid GUI and Mythweb are not loading. I cannot view unraid shared folders from Win10 PC. 

  I am able to SSH into the machine and also have a keyboard/monitor connected directly to it. From each I can log in and at least run LS commands. 

 

I had planned on replacing Disk 01 because of SMART warnings. I won't start that until Thur or Fri. Other than that, Unraid has been running for months without any issues.  I haven't made any changes to the configuration in months.

 

thanks

I found this post.  http://lime-technology.com/forum/index.php?topic=39257

 

How long does it take to run the diagnostics from the command line?  more than 10 min?  I typed "diagnostics" the next line "Starting diagnostics collection..." has been on the screen for a while now.

 

I opened another Putty window and logged in again. /boot/logs is still empty.  There is a folder /tower-diagnostics-20161123-700/  this folder has several subfolders that are empty. the /tower-diagnostics-20161123-700/system/ folder has six files in it. "lsof.txt  lspci.txt  lsscsi.txt  memory.txt  ps.txt  vars.txt"  - is this the extent of the diagnostics?  I don't see a zip file.

 

50 minutes now, I still don't see a zip file...

 

in the second instance of putty I typed...

cd /mnt

ls

... now that window is unresponsive.  I am able to open a third window and log in again.

 

Please advise...

 

thanks

Everend

I just typed 'diagnostics' again and logged into another putty instance.  There is now a new folder tower-diagnostics-20161123-0815 in addition to the one earlier. It contains the same folders and files.

 

So my guess at this point is the same thing causes 'ls mnt' to hang is causing 'diagnostics' to hang.

I just found the /var/log/syslog file.  It is too large to attach as txt file, so its zipped.

syslog.zip

since I found the syslog file I decided to try to restart the machine.  I typed 'powerdown' in the putty session. 

 

Broadcast message from root@Tower (pts/4) (Wed Nov 23 10:22:44 2016):

The system is going down for system halt NOW!

 

After 15 minutes I switched over to the console (monitor and keyboard attached to unRAID) and see this on the screen.

 

Broadcast message from root@Tower (pts/4) (Wed Nov 23 10:22:44 2016):

The system is going down for system halt NOW!
INIT: Switching to runlevel: 0
INIT: Sending processes the TERM signal
logout
Running shutdown script /etc/rc.d/rc.0"
Saving system time to the hardware clock (UTC)
Creating system time correction file /etc/adjtime.

 

this screen hasn't changed in 5 minutes.

I waited two hours but the console screen never changed. I opened a new ssh session and typed 'reboot'.  This instantly restarted the machine.  The GUI came back up, everything looked to be in the right place so I started the array.  So far its working correctly.

 

 

 

I waited two hours but the console screen never changed. I opened a new ssh session and typed 'reboot'.  This instantly restarted the machine.  The GUI came back up, everything looked to be in the right place so I started the array.  So far its working correctly.

Probably not a bad idea to collect and post the diagnostics anyway, there could be some indications of issues that would show up there.

Here is the diag file.  Generated several hours after restarting the array.  Please let me know if you see something suspicious.

 

thanks

tower-diagnostics-20161123-1733.zip

A quick look at your diagnostics shows that disk ST3000DM001-1CH166_W1F44P04 has 48 pending sectors, which is never a good thing.

 

The syslog you managed to extract before re-booting shows lots of this:

 

Nov 20 05:00:11 Tower shfs/user: share cache full

 

and this:

 

Nov 21 00:22:24 Tower kernel: JobWorker[28581]: segfault at 4c0 ip 00000000009c0cc7 sp 00002ac438b7e730 error 4 in kodi.bin[400000+1da6000]

 

but I have no idea of the possible cause.

A quick look at your diagnostics shows that disk ST3000DM001-1CH166_W1F44P04 has 48 pending sectors, which is never a good thing.

This started hours before the freeze. I've got a pre-cleared disk ready to go but didn't want to start the process until I had some time to dedicate to watching it (this weekend).

 

The syslog you managed to extract before re-booting shows lots of this:

 

Nov 20 05:00:11 Tower shfs/user: share cache full

 

and this:

 

Nov 21 00:22:24 Tower kernel: JobWorker[28581]: segfault at 4c0 ip 00000000009c0cc7 sp 00002ac438b7e730 error 4 in kodi.bin[400000+1da6000]

 

but I have no idea of the possible cause.

 

So what do these things indicate?  I do have pending upgrades for unRaid and the kodi docker (as well as some other things).  But again I didn't want to do these upgrades when I didn't have time to set aside to address any issues that could arise. 

 

As for 'share cache full' that's odd.  I have a cache pool with plenty of room in it.

 

Cache Devices
Device	Identification	Temp.	Reads	Writes	Errors	FS	Size	Used	Free	View
Cache	Not installed		btrfs	1.50 TB	
990 GB
510 GB
Browse /mnt/cache
Cache 2	ST31000524AS_6VPEJ5WK - 1 TB (sde)	39 C	285,809	699,237	0	
Cache 3	Hitachi_HDS723020ALA640_MK0251YGKKXTRA - 2 TB (sdf)	35 C	47,407	724,327	0	
Total	Pool of two devices	37 C	333,216	1,423,564	0	

The initial hang could have been caused by an attempt to read the unreadable pending sectors. Segfaults are caused by attempts to access memory locations that are forbidden - likely caused by a bug somewhere. To stand any chance of working out the real cause you need an entry in the log that covers the period during which it first happened, but I'm no expert.

 

I would check that there's nothing amiss in the current log and then replace the disk and update everything to the current versions. Once you've replaced the disk you can run a couple of pre-clear passes or run

badblocks

to get those pending sectors re-allocated. Check the SMART status afterwards and decide whether to keep the disk as a spare or dispose of it.

This syslog still has a lot of these as well as some other red items.  So there is 'something amiss in the log, however I don't know if this means don't replace the disk because it will mess up or do replace the disk and it will fix these errors.

 

Nov 21 00:22:24 Tower kernel: JobWorker[28581]: segfault at 4c0 ip 00000000009c0cc7 sp 00002ac438b7e730 error 4 in kodi.bin[400000+1da6000]

 

please advise.

tower-diagnostics-20161124-1915.zip

Try switching off the autostart of that Docker and rebooting. That way you break the problem into two parts. Get the basic NAS function of unRAID working properly by replacing the disk and checking the filesystem on your cache, before tackling the Docker.

 

Incidentally, I don't see a SMART report for your cache SSD and it's still reporting no space so there's a problem there.

 

I don't use Kodi but it might be buggy or corrupt in some way. It might be worth trashing your docker.img and re-downloading the containers, once your cache drive is fixed.

I shut down auto-start as you suggested and booted.  There are still error messages in the syslog.

 

Nov 24 21:48:45 Tower sshd[1471]: Server listening on 0.0.0.0 port 22.
Nov 24 21:49:09 Tower kernel: blk_update_request: I/O error, dev fd0, sector 0
Nov 24 21:49:09 Tower kernel: floppy: error -5 while reading block 0
Nov 24 21:49:10 Tower avahi-daemon[6795]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Nov 24 22:39:28 Tower kernel: blk_update_request: I/O error, dev fd0, sector 0
Nov 24 22:39:28 Tower kernel: floppy: error -5 while reading block 0
Nov 24 22:39:47 Tower kernel: blk_update_request: I/O error, dev fd0, sector 0
Nov 24 22:39:47 Tower kernel: floppy: error -5 while reading block 0

tower-syslog-20161124-2258.zip

Both are benign but you can stop the /dev/fd0 one by telling the BIOS that there's no floppy drive fitted - it's trying to read from it.