NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
vbif
Jun 10, 2019Aspirant
Spin-down problem and how I resolved it
Since the Spin-down option was built in it has been never working properly. After each and every Update (wich I appreciate a lot by the way) I've been trying to activate this function always with the same result: the noflushd starts to spinning down the disks and then cancelled it or spins the disks up after a very short time:
Jun 9 13:51:25 NAS noflushd[1219]: Spinning down disk 1 (/dev/sda). Jun 9 13:51:28 NAS noflushd[1219]: Spinning down disk 2 (/dev/sdb). Jun 9 13:52:01 NAS noflushd[1219]: Spinning up disk 1 (/dev/sda) after 0:00:33. Jun 9 13:52:01 NAS noflushd[1219]: Spinning up disk 2 (/dev/sdb) after 0:00:31.
So, as lazy as I was all this time, I think I have a solution now. The big problem for the spin-down function on the rn102 system is that the root file system is located on the disks (/dev/md0) itself, the /var/log is located there, the /tmp !!! is located there. So we have a problem here, there are so many processes that continuously writes and logs to the disks so that noflushd has to spin up the disks over and over again.
I do some changes to my system, and now I see that noflushd keep disks down for hours!
Jun 10 07:27:43 NAS noflushd[12648]: Spinning down disk 1 (/dev/sda). Jun 10 07:27:45 NAS noflushd[12648]: Spinning down disk 2 (/dev/sdb). Jun 10 11:02:59 NAS noflushd[12648]: Spinning up disk 1 (/dev/sda) after 3:35:14. Jun 10 11:02:59 NAS noflushd[12648]: Spinning up disk 2 (/dev/sdb) after 3:35:11.
Hier are the changes I've made:
/etc/pam.d/frontview
#%PAM-1.0 #auth requisite pam_tally2.so onerr=fail deny=5 unlock_time=300 auth required pam_unix.so #account required pam_tally2.so account required pam_unix.so
the first and the third lines were commented out, so that the /var/log/tallylog is no longer updated. I think, on my system with only access from home network I could give up a small security feature for a better power consumption.
then the /etc/rsyslog.conf was modified so that only .err messages are been writen to /var/log/...
auth,authpriv.err /var/log/auth.log *.err;auth,authpriv.none -/var/log/syslog daemon.err -/var/log/daemon.log daemon.* /run/lock/daemon.log kern.* /run/lock/kern.log kern.err -/var/log/kern.log lpr.err -/var/log/lpr.log mail.err -/var/log/mail.log user.err -/var/log/user.log
the daemon.log and the kern.log are now located at /run/lock wich lives in ram. I know, /run/lock is not a suitable place for logs, but it is only tmfs partitions big enough to hold the logs. The daemon.log is usefull to track down the noflushd work.
My plan is to use USB flash drive for all the logs, and to change the /tmp to the tmpfs file system so that noflushd have acctually some chance to spin down the disks.
I run the latest firmware 6.10.1
5 Replies
Replies have been turned off for this discussion
- StephenBGuru - Experienced User
I don't have many of the log files you reference (and don't have /etc/rsyslog.conf either). Normally the NAS logging is done with journalctl.
I am thinking you might have installed rsyslog manually - is that the case?
- vbifAspirant
that is an interesting point. But I haven't installed rsyslog manually, may be it came with some Netgear apps as a dependence, I did test some of them.
by the way journalctl also writes to the root aka md0
- StephenBGuru - Experienced User
vbif wrote:
that is an interesting point. But I haven't installed rsyslog manually, may be it came with some Netgear apps as a dependence, I did test some of them.
There is (or was) a log monitoring app that installs rsyslog. I suggest uninstalling any apps you no longer use (and if you've done that already, manually uninstall rsyslog). Some of them can destabilize the NAS (particularly when upgrading firmware).
vbif wrote:by the way journalctl also writes to the root aka md0
Yes of course. But you got spindown to work without changing journalctl. My recollection is that Netgear set up logging to defer writes (at least to some degree) in order to avoid spinup. There are some posts where they say they said that they made some adjustments to flushd.
FWIW, I wouldn't have made your mods - at least not all of them. /tmp is rarely used, so I'd leave that alone. Writing logs to RAM sounds like a bad idea to me, as you'd likely lose them when you need them the most. I think tallylog is normally updated when users attempt to log in - which likely will spin up the disks anyway. So I wouldn't be inclined to fiddle with pam or tallylog either.
But it'd be interesting to see the results of making each mod individually (after removing rsyslog, and seeing what difference that makes).
Related Content
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!