count-zero

Members
  • Posts

    18
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

count-zero's Achievements

Noob

Noob (1/14)

5

Reputation

  1. I'm going to mark this as solved. I've been stable for a week after changing from macvlan to ipvlan and rebooting. Thank you for the help @JorgeB! Appreciate it!
  2. yep, I rebooted after the docker vlan change. stable so far, but the crashes usually took 18 hours or more to happen, so i’ll be monitoring over the next few days. I appreciate your help so far!
  3. Thanks, I've made that change and will monitor my system to see if it's stable.
  4. Gotcha, thanks for the info. I've disabled the update check in FCP and will just come in to check manually from now on. Thanks again!
  5. Okay, so leaving the remote management window closed did not help it from crashing. still crashed. THIS TIME, I have a bunch of kernel errors in the syslog from before the crash. I noticed it start becoming unresponsive around Dec 14 15:00:00, but looking at the logs, the kernel errors started well before that, around Dec 14 00:10:32. I've attached the logs. @JorgeB could you take another look and let me know what you think of these logs? Still suspected hardware issues, or something with Unraid? I haven't been able to leave it in basic NAS mode yet, so that test is still outstanding, but maybe these logs will shed more light on the issue. syslog-192.168.1.2(3).log
  6. Interesting… I do leave the unraid remote management window open often. I will try closing it and see if my system is stable. If still unstable, I will continue with hardware diags, but this did all start after I upgraded to 6.12.x, so I’m interested to see if it’s the same issue.
  7. It just crashed again this morning. again, nothing in the syslog at the time of the crash. When you say hardware issue, do you mean the USB, or my physical hardware (motherboard/etc)? Any diags I can run to test the hardware and see what might be failing? Not sure if unraid has anything like that built in... my motherboard is old enough that it doesn't have built-in diagnostics that I'm aware of...
  8. I misspoke - it sent an email between those times, but that email said everything was green.
  9. Yes. It crashed some time between Dec 9 19:42:03 (I can see I logged in remotely) and Dec 10 12:30:59 (when I rebooted the server). There's simply nothing logged between those times, so I can't tell exactly when it went unresponsive. This is the only crash that has happened since I started the syslog. I've set up external monitoring now, so I should get a better idea of when exactly it crashes, but I don't know how much help that will be if nothing is logged during the crash...
  10. Hi, I recently upgraded to 6.12.6 from 6.10.something, and since then, my server has been consistently becoming unresponsive. Remote access goes dead, the web UI times out, and I get connection refused when trying to SSH. I have a monitor connected to the server, and there's simply no display when this happens, and keyboard inputs do nothing. This has happened now 3 times in the last 5 days or so. The only way to get it out of this state seems to be a hard reboot, which I'm always hesitant to do, because the array seems to still be started when this happens, and the first time I did the hard reboot, I corrupted one of my disks and had to repair the filesystem to get it back into the array. Parity check that ran after the second time it was hard rebooted found ~700 errors across 8TB of parity, so I'm worried about further corruption if this continues to happen. After the second crash, I have configured syslog to dump onto the array, but in looking at the log, there doesn't seem to be anything logged during the problem. I've attached both the diagnostics file and the syslog file that is on the array. syslog-192.168.1.2.log cherry-diagnostics-20231210-1249.zip
  11. Here is my compose file (with some sensitive info redacted) docker-compose.yml
  12. I'm using the Compose.Manager plugin so I can use docker compose stacks instead of individual docker containers as this was how my server was set up prior to migrating to unraid. I am able to update the stack using the 'Update Stack' button, but the Docker tab still says there are updates available to most of my docker containers. If I click 'apply update' on a container, it breaks the stack and that container no longer functions properly (I suspect because it's performing the update outside of the stack). While this isn't a big deal, it is slightly annoying that I get pinged every day for updates that I can't apply. It seems like Compose.Manager and the standard Docker plugin pull updates from different sources. Am I correct in thinking that? Is there any way to either disable the update check for containers in the stack, or to tell the Docker plugin to look at the Compose file for updates? cherry-diagnostics-20231209-0759.zip
  13. Ah, yeah that did it. I set 'Minimum free space' to 1GB. I had tried to do this in the past, but I didn't understand you can't just put 0B in there. When I did that, it just went back to whatever the calculated value was. Thank you for looking at this! I'm now getting syslog files created.
  14. Gotcha, here are the diagnostics. cherry-diagnostics-20231209-0713.zip
  15. I have been experiencing an issue where my unraid server will become unresponsive after I upgraded to 6.12.6. In troubleshooting this, I'm attempting to configure the syslog server to write to a share by following the guide in the FAQ. However, I am seeing this error in the log when I attempt to configure the syslog server: Dec 8 18:55:45 cherry rsyslogd: [origin software="rsyslogd" swVersion="8.2102.0" x-pid="7935" x-info="https://www.rsyslog.com"] start Dec 8 18:55:45 cherry rsyslogd: file '/mnt/user/syslog/syslog-192.168.1.2.log': open error: No space left on device [v8.2102.0 try https://www.rsyslog.com/e/2433 ] There is plenty (1.2TB) free on the array, so I can't see why I'm getting this error. Here is my syslog server config: I'm at a loss for what to do... I've tried changing the split level in the share settings as well as changing the maximum file size in the syslog server settings. I still get the same error.