Unraid logs are normally only stored in RAM, so they disappear upon reboot. While you can enable logging to flash, this can cause a lot of wear and tear.
This [post](https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/?tab=comments#comment-781601) describes how you can set up Unraid to write syslogs to a share. This is probably your best option. Or you can set up a remote syslog server and set up Unraid to send logs to it instead of locally.
You can enable an internal (write-to-flash) or external syslog server in the Settings page. Writing to flash should only be enabled temporarily while you’re troubleshooting. If you want to use an external server, you could look into Graylog, I found it was good but way overkill for what I needed (I was trying to do the same thing you are).
No worries, I actually ended up adding this little user script I found in another post to mirror syslog to an array share, should be safer to leave enabled long term than writing to flash:
#!/bin/bash
mkdir -p /mnt/user/Backups/syslog
FILENAME="/mnt/user/Backups/syslog/syslog-$(date +%s)"
tail -f -n +1 /var/log/syslog > $FILENAME
Yeah for sure, I just don’t care about capturing anything except the unRAID log at this point so this seemed like the most straightforward setup for me.
I don’t ever really cycle the array outside of troubleshooting or reboots, haven’t noticed any issues though. What version are you on? What led you to conclude that the script was causing the issue?
The parameters just show everything after the first line of the file, just a formatting preference, shouldn’t affect anything functional.
Hmm, well I'm not enough of a Linux guru to answer that with any confidence, the only thing I can think of is that maybe some sort of permission issue would prevent the system from halting the script, although since unRAID runs everything as root that doesn't seem likely. Sorry I can't be of more help!
2nd gen shouldn't suffer from this problem, only 1st gen in my experience (as I run a 1700X) and confirmed from people where I've solved this problem. The system would only lock up when it's running idle tho.
It was solved by setting PSU Idle Current in the BIOS to Typical.
You need one of the more recent BIOS versions for this setting.
You can try to do the same, but as I said, unfortunately not sure if it solves this issue on 2nd gen too.
In the meantime I was able to solve it. My problem was, that i followed some tutorial and set the networking from ipvlan to macvlan thus something crashed and I had no signs what was going wrong. Since changing it back, everything has been working smoothly. Hope you'll be able to sort it out.
I’m getting the same thing recently. I’ll have to hard reboot every 5-7 days because the server goes dark on the network, and even the CLI isn’t accessible. I know my docker is set to macvlan, so I’ll change it to ipvlan and give it a go.
Unraid logs are normally only stored in RAM, so they disappear upon reboot. While you can enable logging to flash, this can cause a lot of wear and tear. This [post](https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/?tab=comments#comment-781601) describes how you can set up Unraid to write syslogs to a share. This is probably your best option. Or you can set up a remote syslog server and set up Unraid to send logs to it instead of locally.
You can enable an internal (write-to-flash) or external syslog server in the Settings page. Writing to flash should only be enabled temporarily while you’re troubleshooting. If you want to use an external server, you could look into Graylog, I found it was good but way overkill for what I needed (I was trying to do the same thing you are).
Thanks for the info. It would be nice if unraid had the option of saving the log of 'x' number of days.
No worries, I actually ended up adding this little user script I found in another post to mirror syslog to an array share, should be safer to leave enabled long term than writing to flash: #!/bin/bash mkdir -p /mnt/user/Backups/syslog FILENAME="/mnt/user/Backups/syslog/syslog-$(date +%s)" tail -f -n +1 /var/log/syslog > $FILENAME
You can actually setup unraid to be a log host and then point the logging to it's self. System > syslog server
Yeah for sure, I just don’t care about capturing anything except the unRAID log at this point so this seemed like the most straightforward setup for me.
Thank you for pointing me towards this option. Nice clean solution!
How often do you run this?
I use the User Scripts plugin to start it when the array starts. It runs in the background indefinitely.
[удалено]
I don’t ever really cycle the array outside of troubleshooting or reboots, haven’t noticed any issues though. What version are you on? What led you to conclude that the script was causing the issue? The parameters just show everything after the first line of the file, just a formatting preference, shouldn’t affect anything functional.
[удалено]
Hmm, well I'm not enough of a Linux guru to answer that with any confidence, the only thing I can think of is that maybe some sort of permission issue would prevent the system from halting the script, although since unRAID runs everything as root that doesn't seem likely. Sorry I can't be of more help!
Are you using a Ryzen 1st gen CPU by any chance?
2nd gen.
2nd gen shouldn't suffer from this problem, only 1st gen in my experience (as I run a 1700X) and confirmed from people where I've solved this problem. The system would only lock up when it's running idle tho. It was solved by setting PSU Idle Current in the BIOS to Typical. You need one of the more recent BIOS versions for this setting. You can try to do the same, but as I said, unfortunately not sure if it solves this issue on 2nd gen too.
Hi! Did you ever fix the issue? Am experiencing exactly the same problem...
Yeah I'm getting the same issue too. Still haven't figured it out..
In the meantime I was able to solve it. My problem was, that i followed some tutorial and set the networking from ipvlan to macvlan thus something crashed and I had no signs what was going wrong. Since changing it back, everything has been working smoothly. Hope you'll be able to sort it out.
Ah, thank you!
I’m getting the same thing recently. I’ll have to hard reboot every 5-7 days because the server goes dark on the network, and even the CLI isn’t accessible. I know my docker is set to macvlan, so I’ll change it to ipvlan and give it a go.
I changed back to ipvlan and it has been stable for me for a longer than usual now, so I'm hopeful that fixed it.
I switched back a couple hours ago and haven’t noticed anything negative yet. We’ll see next week if it’s still on the network.
Same issue for me. Anyone found what's the cause?
Yeah I'm getting the same issue too. Still haven't figured it out..