I added a drive to an existing array to by the parity drive. I started the parity check (well it auto started when I started the array). It ran for a few hours then I got the following:

 

Parity sync / Data rebuild finished (0 errors)Duration: 1 day, 1 hour, 21 minutes, 4 seconds. Average speed: 175.3 MB/s

Parity Check Tuning[.....] Unclean shutdown detected

 

The sync def didn't finish as it needs a good day+ (over 30TB) and ran for about 2hrs only so I'm not sure what caused the reboot. Is there a way to find out? I didn't unplug anything nor touched the server that would cause it to reboot/take the array off-line

Edited May 17, 20251 yr by plunderisley

Do you have the Syslog Server configured?   This is needed to have logs that survive a reboot.

 

server rebooting itself is nearly always hardware related.    Since it happened during a parity check my suspicion would be that may be power related as that is when the system tends to be under maximum load, although it could be something else’s such as CPU overheating.

16 minutes ago, itimpi said:

Do you have the Syslog Server configured?   This is needed to have logs that survive a reboot.

 

server rebooting itself is nearly always hardware related.    Since it happened during a parity check my suspicion would be that may be power related as that is when the system tends to be under maximum load, although it could be something else’s such as CPU overheating.

 

no, but I just did (local syslog to temp which is the cache folder). Hardware wise, not sure what could be causing it as I did before this a array check that took the 1 day+ (actually what the message said about completing the parity was actually the read check that completed yesterday). 

2 minutes ago, plunderisley said:

actually what the message said about completing the parity was actually the read check that completed yesterday

Yes, there had been a long standing bug where the message is the operation before the one last run.

21 minutes ago, itimpi said:

Yes, there had been a long standing bug where the message is the operation before the one last run.

Ah okay.

 

Well let's see if the issue pops up again. Last time it was about 2ish hrs (roughly 10%) before that happened.

Also, is having the syslog loopback (so it stores the log files locally) bad to have always on? Are there any disadvantages? I wouldn't mind just logging everything and setting a log rotation and keeping an archive just in case some random issue pops up in the future. 

 

Not that it matters much, but checking the SNMP logs, I can't see any odd blip that could of caused it. Then again the polling probably wouldn't catch it. 

Edited May 17, 20251 yr by plunderisley

It was about half way through and it rebooted this AM. 

Attached is the log, but I don't see anything there that would cause it. 

syslog-192.168.6.105.log

 

I removed the parity tuning and mover tuning plugins to see if that would fix it

Edited May 19, 20251 yr by plunderisley

13 minutes ago, plunderisley said:

I removed the parity tuning

For reference I cannot think of a way this plugin can cause this.

8 minutes ago, itimpi said:

For reference I cannot think of a way this plugin can cause this.

 

I have no idea what else could be causing it. 

Yesterday it did the parity sync all day without issues. Today, that was the last thing in the syslog (the parity tuning) before it rebooted. Unless it's something else outside the logs is causing it, it has to be that plugin.

Power, for sure, is stable and there are no power spikes or anything like that. And the box before the parity check was running fine for a few weeks (before adding the parity drive after copying over all my stuff from the old NAS to the array). These unclean shutdowns started when I started the parity sync. 

Edited May 19, 20251 yr by plunderisley

33 minutes ago, plunderisley said:

Unless it's something else outside the logs is causing it, it has to be that plugin.

The plugin does nothing except pause/resume the parity check that was previously initiated by Unraid.   If it only happens during parity check then I suspect that you have a hardware issue related to the parity check running in the first place (e.g. power problems or CPU overheating).

17 minutes ago, itimpi said:

The plugin does nothing except pause/resume the parity check that was previously initiated by Unraid.   If it only happens during parity check then I suspect that you have a hardware issue related to the parity check running in the first place (e.g. power problems or CPU overheating).

But how to find out what hardware issue would be causing it?

 

Looking at the SNMP graphs, the CPU was steady with normal temp and nothing that showed me any power issues. 
I guess if it crashes again with these plugins turned off, I can go to the bios and run everything at a slower speed but I'm not sure if that would fix it. 

@JorgeBpost might be the solution and it would kinda make sense. I'm running a Ryzen 5800x. I don't recall the bios setup but I know I didn't really set anything manually and it's all basically automatic. When the parity tuning pauses and restarts, I'd guess it would cause a spike of CPU use which would cause it to hang/crash. Would that make sense?

And if I'm reading that right for the solution, I need to increase the CPU voltage by 4pts and disabling c-state. Not too sure how to do this, but I guess I'll have to give it a try. 

Though I'll try and let the parity sync finish first..