TerraMaster Forum

Hello, I am experiencing intermittent complete network outages on my TerraMaster F4-424 NAS running TOS 6.0.794, where the device becomes fully unreachable and requires a hard reboot to recover, and after extensive debugging I have identified the root cause as a kernel RCU stall triggered by the default logrotate configuration interacting with a bug in kernel 6.1.120+ #52.

Hardware: TerraMaster F4-424
TOS version: TOS 6.0.794
Kernel: 6.1.120+ #52 SMP PREEMPT_DYNAMIC (built Thu Nov 27 09:25:39 CST 2025)
CPU: Intel N95
RAM: 8GB

PROBLEM DESCRIPTION:

The NAS becomes completely unreachable on the network intermittently, requiring a hard reboot to recover. During the outage, LAN LEDs remain active but the device does not respond to ping, SSH, or web interface. HDDs also stop spinning during the event.

Analysis of kern.log and syslog from the debug log reveals that the system experienced a kernel RCU stall triggered by the daily logrotate process.

Timeline of the event on April 5, 2026:
- 04:00:21 - logrotate started, first RCU stall detected
- 04:00 to 10:59 - continuous RCU stall warnings every ~60 seconds, same PID (1068593, logrotate)
- 10:59 - last log entry, kernel too frozen to write further
- 11:02 - network monitor script last entry
- 16:09 - external monitoring alert: NAS unreachable

The kernel was in a degraded state for approximately 7 hours before logging stopped, and approximately 12 hours total before the device became completely unreachable.

EVIDENCE FROM KERN.LOG:

Apr 5 04:00:21 TNAS kernel: [458783.118729] rcu: INFO: rcu_preempt self-detected stall on CPU
Apr 5 04:00:21 TNAS kernel: [458783.118750] CPU: 1 PID: 1068593 Comm: logrotate Tainted: G O 6.1.120+ #52
Apr 5 04:00:21 TNAS kernel: [458783.118754] RIP: 0010:filemap_fault+0x5e4/0x900

Apr 5 04:01:24 TNAS kernel: [458846.121728] rcu: INFO: rcu_preempt self-detected stall on CPU
Apr 5 04:01:24 TNAS kernel: [458846.121744] CPU: 1 PID: 1068593 Comm: logrotate Tainted: G O 6.1.120+ #52

[...same pattern repeating every ~60 seconds until 10:59...]

Apr 5 10:59:20 TNAS kernel: [483921.315650] rcu: INFO: rcu_preempt self-detected stall on CPU
[no further log entries after this]

LOGROTATE CONFIGURATION (default TOS config):

/var/log/* /var/log/**/* {
rotate 0
size 1M
missingok
copytruncate
notifempty
}

The "copytruncate" option requires memory-mapped file access which appears to trigger an infinite loop in the filemap_fault kernel function, causing the RCU stall.

WORKAROUND APPLIED:

Removed "copytruncate" from /etc/logrotate.conf and changed "rotate 0" to "rotate 1":

/var/log/* /var/log/**/* {
rotate 1
size 1M
missingok
notifempty
}

After applying this change, logrotate ran successfully in 22ms without any RCU stall.

ADDITIONAL NOTES:

- This issue is NOT related to BTRFS. The /var/log filesystem is ext4 on /dev/md9.
- The issue appears to be a kernel bug in 6.1.120+ #52 specific to the copytruncate + filemap_fault combination.
- The same logrotate configuration ran without issues for approximately 2 months after initial setup (January 2026), suggesting the log files gradually grew large enough to trigger the bug more frequently.

Thank you for the detailed description. Regarding the issue where the logrotate configuration interacts with a bug in kernel version 6.1.120+, triggering an RCU stall in the kernel, please assist with the following:

• Have you had debug mode enabled for an extended period?

• Please email the relevant logs to our technical support team ([email protected]) for analysis. If the system reports that the logs cannot be sent normally, please upload them to a cloud storage service first and then share the download link in your email. It would also be helpful if you could include a link to the original post in your email.

Thank you for your response! I have sent an email to [email protected] with the relevant log files attached. I have also included a detailed description of the issue and the findings from my investigation.

Debug mode was not enabled during the original outages. I enabled it on March 30, 2026 specifically for diagnostic purposes, after the problem had already been occurring for some time.

Impressive troubleshooting!
Pinpointing a Kernel RCU stall down to logrotate is top-tier technical work. We’ve confirmed the issue and passed your findings to our product team to evaluate optimizations for upcoming releases.
Thanks for the high-quality feedback—this truly helps improve the product!

Thank you for the quick response and for passing this on to the product team! Could you give me an approximate timeframe for when a software update addressing this issue might be released?

We are conducting in-depth analysis and comprehensive testing to prevent similar issues from occurring. Thanks for your patience. Once we have a specific timeline, we will leave a message to inform you.

Update – April 13, 2026: Another crash, root cause identified: ter_smartfan
This morning I woke up to another crash. Telegram alert came in at 04:27, I hard-reset the NAS at 06:01 using the power button.
Background: In previous sessions I had already disabled logrotate.timer (immutable) and removed the Tailscale app, as both were suspected triggers. Neither was involved this time.
What the persistent debug log showed (/Volume1/@system/debug/log/syslog):
The ter_smartfan process started kernel-crashing repeatedly from 04:04 onward, cycling through PIDs at an alarming rate as tnas-smartfan.service kept restarting it after each crash:
Apr 13 04:04:02 – ter_smartfan[1034149] exited with irqs disabled
Apr 13 04:04:02 – ter_smartfan[1034150] exited with irqs disabled
Apr 13 04:04:02 – ter_smartfan[1034151] exited with irqs disabled
Apr 13 04:04:33 – ter_smartfan[1034166] exited with irqs disabled
Apr 13 04:04:33 – ter_smartfan[1034167] exited with irqs disabled
Apr 13 04:04:44 – ter_smartfan[1034176] exited with irqs disabled
Apr 13 04:04:54 – ter_smartfan[1034178] exited with irqs disabled
Apr 13 04:04:54 – ter_smartfan[1034181] exited with irqs disabled
Apr 13 04:05:15 – ter_smartfan[1034191] exited with irqs disabled
...
Apr 13 04:23:43 – ter_smartfan[1034356] exited with irqs disabled ← final crash, network dies
The kernel oops at 04:23:43:
CPU: 2 PID: 1034356 Comm: ter_smartfan Tainted: G D O 6.1.120+ #52
BUG: kernel NULL pointer dereference / page fault
RIP: 0010:move_to_new_folio+0x30/0x140
Call Trace:
__anon_vma_prepare+0xdc/0x170
__handle_mm_fault+0x1260/0x12c0
handle_mm_fault+0xb1/0x220
__get_user_pages+0x1e5/0x630
get_arg_page+0x69/0x1a0
copy_string_kernel+0xbd/0x1c0
do_execveat_common.isra.0+0x11f/0x220
note: ter_smartfan[1034356] exited with irqs disabled
The crash happens inside kernel memory page migration (move_to_new_folio) triggered during process exec. After ~19 minutes of repeated crashing and restarting, the accumulated kernel state corruption took down the network at 04:23.

Follow-up analysis: ter_smartfan is a symptom, not the root cause
After a more thorough review of the full persistent syslog (/Volume1/@system/debug/log/syslog), the picture is significantly more complex than initially described.

The actual root cause: a kernel bug in move_to_new_folio / Transparent Huge Pages (THP)
The very first crash in this boot session was not ter_smartfan at all. On April 8 at 19:40, the kernel's own khugepaged daemon (PID 41) crashed with an Oops [#1] inside move_to_new_folio+0x30/0x140:
Apr 8 19:40:17 TNAS kernel: [84499.556894] BUG: unable to handle page fault for address: ffffa8dd0c3d5700
Apr 8 19:40:17 TNAS kernel: [84499.556909] Oops: 0000 [#1] PREEMPT SMP NOPTI
Apr 8 19:40:17 TNAS kernel: [84499.556912] CPU: 2 PID: 41 Comm: khugepaged Tainted: G O 6.1.120+ #52
Apr 8 19:40:17 TNAS kernel: [84499.557099] note: khugepaged[41] exited with irqs disabled
khugepaged is not a user-space process — it is the kernel's Transparent Huge Pages manager, responsible for merging small memory pages into larger ones. Its crash left the kernel in a silently corrupted memory state. The system appeared stable for the next 5 days.

April 13, 03:56 — the avalanche
127 hours and 44 minutes into the same boot session, a routine operation (likely ter_smartfan reading a temperature file via cat) touched the already-corrupted memory page at address ffffa8dd42446540. This triggered a cascade of 185 kernel crashes in under 27 minutes:
ProcessCrashessmbd (Samba daemon) 83
ter_smartfan61ResourceCollect 31
smartctl, TOSDaemon, others 10

Note that smbd crashed the most — 83 times. Every process that attempted to allocate or access memory in the affected region died. ter_smartfan happened to be restarted frequently by tnas-smartfan.service, which made it appear to be the primary culprit. It was not.
The pattern across all crash events is identical:

Same kernel function: move_to_new_folio+0x30/0x140
Same corrupted address: ffffa8dd42446540
Same CPU core: CPU 2
Kernel taint flag D (system previously Oopsed) present in every subsequent crash

Thank you for your further feedback. Please also send the new debug logs to the support email, and we will analyze them in combination with the latest situation.

If you are encountering a similar problem, please check this thread: viewtopic.php?p=56843
In my case, updating the BIOS to BJFX-ADLN-109 and adding intel_idle.max_cstate=1 to grub.cfg appears to have resolved the issue.