July 17, 20205 yr unRAID 6.8.3. Few weeks back, I posted back about the random hangs. At the time, it seemed like my sole Win10 VM was the cause. Disabling the VM from running (not on boot, turned off when not in use) seemed to have helped, but the hangs still appear. Had my unRAID machine on for nearly 3 days, then it just went unresponsive about three minutes ago. Heat definitely isn't the cause, as it's still early in the morning, and the previous two days haven't been all that warm. I've re-enabled local syslog server, writing to system, and mirroring to flash. Where on flash, can I look at the log file for any clues on crashes? These random hangs are bugging me to no end!
July 17, 20205 yr Community Expert 2 hours ago, stashtv said: I've re-enabled local syslog server, writing to system, and mirroring to flash. Where on flash, can I look at the log file for any clues on crashes? https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/?tab=comments#comment-781601
July 17, 20205 yr Author Is the USB filesystem mounted on boot? I've had this enabled, but I don't see a logs/ folder anywhere that is mounted, and I've scanned anything obvious that is mounted with 'mount'.
July 17, 20205 yr Community Expert Here is the full path to it using SSH or the GUI terminal. IF you share/export the Flash Device ( Main >>> Boot Device ---> click on Flash >>> SMB Security Settings ), you can access it via Windows Explorer. ls -al /boot/logs Edited July 17, 20205 yr by Frank1940
July 17, 20205 yr Author Thank you! Now I await another crash. Could be today, could be Monday. Let the dice roll begin!
July 18, 20205 yr Author Crashed last night, powered it off, and here are the last lines in the log file before the crash and this mornings boot: Jul 14 18:29:09 Greyskull sshd[22310]: Accepted none for root from 192.168.11.190 port 61165 ssh2 Jul 14 19:27:14 Greyskull kernel: br0: port 2(vnet0) entered disabled state Jul 14 19:27:14 Greyskull kernel: device vnet0 left promiscuous mode Jul 14 19:27:14 Greyskull kernel: br0: port 2(vnet0) entered disabled state Jul 14 19:54:32 Greyskull ool www[32632]: /usr/local/emhttp/plugins/dynamix/scripts/rsyslog_config Jul 17 07:09:02 Greyskull rsyslogd: [origin software="rsyslogd" swVersion="8.1908.0" x-pid="6723" x-info="https:// www.rsyslog.com"] start Jul 17 07:11:50 Greyskull ntpd[1688]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized Jul 17 09:06:38 Greyskull kernel: vethe248dbe: renamed from eth0 Jul 17 09:06:53 Greyskull kernel: br0: port 2(vnet0) entered blocking state Jul 17 09:06:53 Greyskull kernel: br0: port 2(vnet0) entered disabled state Jul 17 09:06:53 Greyskull kernel: device vnet0 entered promiscuous mode Jul 17 09:06:53 Greyskull kernel: br0: port 2(vnet0) entered blocking state Jul 17 09:06:53 Greyskull kernel: br0: port 2(vnet0) entered forwarding state Jul 17 16:29:19 Greyskull kernel: md: sync done. time=33743sec Jul 17 16:29:19 Greyskull kernel: md: recovery thread: exit status: 0 Jul 18 06:25:23 Greyskull kernel: microcode: microcode updated early to revision 0x21, date = 2019-02-13 Jul 18 06:25:23 Greyskull kernel: Linux version 4.19.107-Unraid (root@Develop) (gcc version 9.2.0 (GCC)) #1 SMP Th u Mar 5 13:55:57 PST 2020 Jul 18 06:25:23 Greyskull kernel: Command line: BOOT_IMAGE=/bzimage initrd=/bzroot Jul 18 06:25:23 Greyskull kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' Jul 18 06:25:23 Greyskull kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' Jul 18 06:25:23 Greyskull kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' Jul 18 06:25:23 Greyskull kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 Jul 18 06:25:23 Greyskull kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard ' format. Jul 18 06:25:23 Greyskull kernel: BIOS-provided physical RAM map: The system went from booting, completing parity check (yay), then nothing ... and it's dead.
July 19, 20205 yr Community Expert Unfortunately there's nothing in the log that gives a clue about the crash, it could be a hardware issue.
Archived
This topic is now archived and is closed to further replies.