Jump to content

galways

Members
  • Content Count

    30
  • Joined

  • Last visited

Community Reputation

0 Neutral

About galways

  • Rank
    Advanced Member

Converted

  • Gender
    Undisclosed
  1. Thanks for the suggested cause. I've set the UPS to power off after initiating a shutdown in the event it was something else.
  2. This morning I just happened to be next to my server when it suddenly powered down. Concurrently I received the following email notice: /bin/sh: line 1: 4681 Terminated /usr/local/emhttp/plugins/ca.backup/scripts/backup.php &> /dev/null 2>&1 Server powered up OK on restart. It looks like the backup completed fine, the last file creation being 6:55 am. The notification was 6.57 am the same time the server shut down. Am assuming there is a relationship.
  3. You ran out of memory... Possibly you're allocating too much memory to the VMs or one of your docker containers is saving files into RAM -> bad mappings? Reboot and try the diagnostics again. Failing that, Edit the file on your flash drive config/disk.cfg Change the line that says startArray="yes" to be startArray="no" and reboot Diagnostics attached. I changed my two OPENELEC VMs from 4 to 2g. Honestly not sure what they should be but didn't think it would be an issue in that I have 32g on my system. How would I know if something was saving files into RAM? No sure what to look for. Thanks for the help. tower-diagnostics-20160331-1224.zip
  4. Today I experienced a GUI failure in 6.2.0-beta20 that appears to be identical to what I reported happening in 6.2.0-beta19. Specifically my dashboard, main, shares and VM show that the array isn't started. I am not able to download diagnostics as I get a 404 error. Not able to get diagnostics from the command line. Am able to get the system log from tools and the docker tab is fully accessible. All dockers still work, the VM's are still working and I am able to access the shares from windows as well as from MC. This has been happening on my system since using 6.2 and the strange thing seems to be that the duration between fails is at least 4 days. As I asked in beta19, any advice appreciated. March_31_system_log.txt
  5. Having an issue that is only solved by doing a reboot. Two or three times since updating to 6.2 first 18 now 19, the last two failures 4 days apart, my GUI partially gives out. It shows that the array is offline while the docker tab shows up correctly, I can still access the files using windows and the dockers still work. If I try to pull diagnostics from the command line I get: Warning: file_put_contents(): Only 0 of 34 bytes written, possibly out of free disk space in /usr/local/emhttp/plugins/dynamix/scripts/diagnostics on line 81 (repeated several times indicating different line numbers). The diagnostics report is eventually produced but every file is empty. Today I seem to have been lucky enough to pull a diagnostic from the GUI just before the GUI failed which is attached along with a partial system log that I was able to get after the failure from the tools tab which still worked (trying to download resulted in a 404 message). As an aside when I first boot into unraid if using an attached console and keyboard after a few minutes the USB keyboard fails to respond albeit is still getting power, happens regardless of which port I use on the server. Any help in pointing me in the right direction appreciated tower-diagnostics-20160323-0759.zip copy_of_partial_system_log.zip
  6. Having the same issue with the VM tab not showing. Am also using cache drives. Have 2 Openelec VMs. Log showing: Mar 11 16:56:01 Tower emhttp: shcmd (1304): /etc/rc.d/rc.libvirt start |& logger Mar 11 16:56:01 Tower root: no image mounted at /etc/libvirt Mar 11 16:57:01 Tower emhttp: shcmd (1322): /etc/rc.d/rc.libvirt start |& logger
  7. Decided to reboot. Everything started, including cache. Not sure what caused the problems but they must have been strictly GUI related.
  8. I removed the unassigned disk plugin and the GUI started responding again. Then noticed that my dual 240 g cache drives were showing as only a couple of gig in space left as opposed to the 178 g that is typically free. In a few minutes the space was gone and am now back to nothing showing on the GUI and an indication that the array is down. I stopped all dockers and VMs and can still access the shares and data on my disks. On the appdata share which resides on the cache drives I can see some of the folders but no data is being shown. This is all I have relative to logs (copied from screen) Feb 27 12:57:21 Tower shfs/user: shfs_create: assign_disk: appdata/sickbeard/config.ini (28) No space left on device Feb 27 12:57:22 Tower php: /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker 'stop' 'sickbeard' Feb 27 12:57:22 Tower kernel: veth3de27af: renamed from eth0 Feb 27 12:57:22 Tower kernel: docker0: port 1(veth1e17fdc) entered disabled state Feb 27 12:57:22 Tower kernel: docker0: port 1(veth1e17fdc) entered disabled state Feb 27 12:57:22 Tower avahi-daemon[22912]: Withdrawing workstation service for veth3de27af. Feb 27 12:57:22 Tower avahi-daemon[22912]: Withdrawing workstation service for veth1e17fdc. Feb 27 12:57:22 Tower kernel: device veth1e17fdc left promiscuous mode Feb 27 12:57:22 Tower kernel: docker0: port 1(veth1e17fdc) entered disabled state Feb 27 12:57:22 Tower emhttp: get_filesystem_status: statfs: /mnt/user/transcode No such file or directory Feb 27 12:57:25 Tower ntpd[2453]: Deleting interface #4 docker0, 172.17.42.1#123, interface stats: received=0, sent=0, dropped=0, active_time=73 secs Feb 27 12:58:01 Tower crond[2476]: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 27 12:58:01 Tower emhttp: get_filesystem_status: statfs: /mnt/user/transcode No such file or directory Feb 27 12:58:52 Tower kernel: usb 3-2: new low-speed USB device number 4 using xhci_hcd Feb 27 12:58:52 Tower kernel: usb 3-2: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes Feb 27 12:58:52 Tower kernel: usb 3-2: ep 0x82 - rounding interval to 64 microframes, ep desc says 80 microframes Feb 27 12:58:52 Tower kernel: input: HID 04f3:0103 as /devices/pci0000:00/0000:00:1c.4/0000:07:00.0/usb3/3-2/3-2:1.0/0003:04F3:0103.003D/input/input64 Feb 27 12:58:52 Tower kernel: hid-generic 0003:04F3:0103.003D: input,hidraw5: USB HID v1.11 Keyboard [HID 04f3:0103] on usb-0000:07:00.0-2/input0 Feb 27 12:58:52 Tower kernel: input: HID 04f3:0103 as /devices/pci0000:00/0000:00:1c.4/0000:07:00.0/usb3/3-2/3-2:1.1/0003:04F3:0103.003E/input/input65 Feb 27 12:58:52 Tower kernel: hid-generic 0003:04F3:0103.003E: input,hidraw6: USB HID v1.11 Device [HID 04f3:0103] on usb-0000:07:00.0-2/input1 Feb 27 12:59:01 Tower crond[2476]: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 27 12:59:01 Tower emhttp: get_filesystem_status: statfs: /mnt/user/transcode No such file or directory Feb 27 13:00:01 Tower crond[2476]: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Is it possible that both cache drives failed. I know this isn't much info but would appreciate an opinion as to to risk in rebooting if in fact the cache drives are dust. Thanks
  9. Using version 1.6.8 GUI started reporting information incorrectly. Is there a way to reset without rebooting? I believe it is related to the following that is showing up in my log: Feb 27 03:41:29 Tower logger: mover finished Feb 27 04:12:40 Tower kernel: mdcmd (259): spindown 0 Feb 27 04:39:50 Tower kernel: mdcmd (260): spindown 7 Feb 27 05:20:30 Tower shfs/user: shfs_rmdir: rmdir: /mnt/cache/appdata/sabnzbd/Downloads/complete (39) Directory not empty Feb 27 05:20:30 Tower shfs/user: shfs_rmdir: rmdir: /mnt/cache/appdata/sabnzbd/Downloads/complete (39) Directory not empty Feb 27 06:07:01 Tower crond[2476]: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 27 06:08:01 Tower crond[2476]: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null ... ... Feb 27 11:27:01 Tower crond[2476]: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 27 11:28:01 Tower crond[2476]: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null Feb 27 11:28:38 Tower emhttp: cmd: /usr/local/emhttp/plugins/dynamix/scripts/tail_log syslog Feb 27 11:29:01 Tower crond[2476]: exit status 2 from user root /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null I can access the server shares, dockers and VMs without problem. Not able to pull diagnostics as I get a 404 error. Am reluctant to reboot before knowing what went wrong. Screen shots attached, thanks
  10. In the docker under Volume Mapping I have: /config=/mnt/user/appdata/emby /mnt=/mnt In folders in the Emby server I have: Movies=/mnt/user/Movies TV=/mnt/user/TV Music=/mnt/user/Audio Path Substitution is: /mnt/user/Movies smb://Tower/Movies /mnt/user/TV smb://Tower/TV /mnt/user/Audio smb://Tower/Audio
  11. Yes in my emby server both folder and path substitution are setup. Try changing Tower to TOWER in substitution as all caps shows in your logs. Not sure if that makes a difference.
  12. I believe its required for the client Kodi to access the file.
  13. In the server library do you have path substitution set? In my case its: From To /mnt/user/Movies smb://Tower/Movies /mnt/user/TV smb://Tower/TV
  14. Determined errors were being caused by my controller AOC-SAS2LP-MV8 dropping out. I pulled the controller, connected my parity and 8 data drives to the motherboard (no room for dual cache). Parity sync completed with no errors and system is now half way through a parity check without errors. Definitely was the SAS2LP as before pulling it I tried running my array on two SAS2LP's in an attempt to see if the problem was my motherboard ports. Sync ran less then 20 minutes before it came to a crawl indicating 600 plus days to complete.