F6-424 TOS6 - Hibarnation interrupted by logrotate

[jollino]

Hello,
I have a F6-424 on TOS6 (can't upgrade to TOS7 at this time), with six Ironwolf disks set to hibernate.
This works for the most part, especially if I set it to 10 minutes of inactivity, but ideally I'd like to keep it to 1 hour.

The problem is that logrotate accesses the disks every hour, and wakes the disks up. With a one-hour timeout, this ultimately means that the disks never get to hibernate.

Oct 16 15:00:07 Supernova systemd[1]: Condition check resulted in Kernel Security Modules - SMACK being skipped.
Oct 16 15:00:07 Supernova systemd[1]: Condition check resulted in Security Spcack being skipped.
Oct 16 15:00:07 Supernova systemd[1]: Starting Rotate log files...
Oct 16 15:00:07 Supernova systemd[1]: logrotate.service: Deactivated successfully.
Oct 16 15:00:07 Supernova systemd[1]: Finished Rotate log files.
[…]
Oct 16 16:00:07 Supernova systemd[1]: Condition check resulted in Kernel Security Modules - SMACK being skipped.
Oct 16 16:00:07 Supernova systemd[1]: Condition check resulted in Security Spcack being skipped.
Oct 16 16:00:07 Supernova systemd[1]: Starting Rotate log files...
Oct 16 16:00:07 Supernova systemd[1]: logrotate.service: Deactivated successfully.
Oct 16 16:00:07 Supernova systemd[1]: Finished Rotate log files.

I found a systemd timer for it:

master@Supernova:/var/log# systemctl list-timers --all | grep logr
Fri 2026-10-16 17:00:00 CEST 51min left Fri 2026-10-16 16:00:07 CEST 8min ago logrotate.timer logrotate.service

But I'm wondering if I should edit /etc/systemd/system/timers.target.wants/logrotate.timer directly (e.g. changing OnCalendar=hourly to OnCalendar=daily), or there's some "more official way" of doing that from the web interface that I may have missed.

Thanks!

[CursaYang]

We have noticed this issue and plan to address it in TOS 7.

May I ask what exactly prevents you from upgrading to TOS 7?

[jollino]

Thanks, I will start by changing the timer to daily; slightly bigger logs aren't going to be an issue.

I'm hesitant to upgrade because my NAS is currently working reliably, and I had a rather unpleasant experience during the TRAID-to-TRAID+ migration: the web interface/backend got stuck and TerraMaster support had to intervene remotely to change a flag before the new configuration was recognized correctly. I can't recall the details as it's been a while, but it took a considerable amount of time, both before and during the remote appointment via TeamViewer.

I'd rather not risk disrupting a working RAID6 setup just to work around a bug in the current OS, especially since any issues over 30 TB of data would be quite inconvenient. Besides, from the marketing materials I don't see any specific features in TOS 7 that I miss in TOS 6 (in fact, to be honest I'm not entirely fond of the shift towards "AI", at least for my own use case). Actually, the only two issues I found with TOS 6 are this one, which I only just noticed as I previously kept my disks spinning at all times, and the fact that docker containers aren't started automatically on the rare occasion the NAS needs to be rebooted.

I will keep an eye on TOS 7 releases, hoping that the upgrade path is more and more stable (I have read a few sparse but terrifying horror stories...!), and pull the trigger when I'm confident I can deal with any potential issues that may crop up.

[EriChan]

Thank you very much for your candid feedback regarding past migration experiences, upgrade hesitations, and feature preferences. As long as TOS 6 continues to reliably meet your daily needs, please feel free to stay on it and use it with peace of mind.

If you ever decide to upgrade to TOS 7 in the future and have any questions, please feel free to reach out to us anytime!