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...
StephenB
Jun 11, 2019Guru - 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?
- vbifJun 11, 2019Aspirant
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
- StephenBJun 12, 2019Guru - 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).
- vbifJun 14, 2019Aspirant
->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).
I don't have any apps installed, but the rsyslog was still active. For now I just deactivated it with systemctl disable rsyslog.
->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.
So, without rsyslog running:
Jun 14 14:26:49 NAS noflushd[30958]: Spinning up disk 1 (/dev/sda) after 7:45:55. Jun 14 14:26:49 NAS noflushd[30958]: Spinning up disk 2 (/dev/sdb) after 7:45:52.
that is OK
But hier I still have some questions
Jun 14 14:56:50 NAS noflushd[30958]: Spinning down disk 1 (/dev/sda). Jun 14 14:56:53 NAS noflushd[30958]: Spindown of disk 1 (/dev/sda) cancelled. Jun 14 14:56:53 NAS noflushd[30958]: Spinning down disk 2 (/dev/sdb). Jun 14 15:09:11 NAS noflushd[30958]: Spinning up disk 2 (/dev/sdb) after 0:12:16. Jun 14 15:32:12 NAS noflushd[30958]: Spinning down disk 1 (/dev/sda). Jun 14 15:32:15 NAS noflushd[30958]: Spinning down disk 2 (/dev/sdb). Jun 14 16:17:13 NAS noflushd[30958]: Spinning up disk 1 (/dev/sda) after 0:44:58. Jun 14 16:32:15 NAS noflushd[30958]: Spinning down disk 1 (/dev/sda).
I think, it may be caused by the journalctl or some other logging daemon, at this time of the day the was nobody at home using the nas
->Writing logs to RAM sounds like a bad idea to me, as you'd likely lose them when you need them the most.
the RAM thing was actually temporary and used only for a daemon.log, I needed a log that wouldn't be written on the root system for the noflushd. At this time I have no knowledge of the journalctl.
For the tallylog - I'm sure it was updated due to some cron jobs or some other activity from readynasd, The configuration for tallylog is in the pam.d file for 'frontview' service. I don't know what is it, but the tallylog was written without any user been logging in.
So my suggestion is sitll to transfer all kind of system stuff aka logging to the USB and the /tmp to the tmpfs drive.
Related Content
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!