I recently installed Debian 9 on a Seagate PersonalCloud. Because the device will only get backed up to once every day, I want its disk to be spun down when it’s not needed. Even on a minimal install, you’ll find quite a few background services that access the root disk every few minutes. Here is what I had to do to keep my disk spun down.
hdparm
First, install hdparm (apt-get install hdparm) and configure /etc/hdparm.conf to spin down your disks after 10 minutes:
#quiet spindown_time = 120
Since hdparm isn’t available in the initrd, when the rule /lib/udev/rules.d/85-hdparm.rules fires, you need to add /etc/systemd/system/hdparm-sda.service:
[Unit] Description=hdparm sda ConditionPathExists=/lib/udev/hdparm [Service] Type=forking Environment=DEVNAME=/dev/sda ExecStart=/lib/udev/hdparm TimeoutSec=0 StandardOutput=tty RemainAfterExit=yes [Install] WantedBy=multi-user.target
Now systemctl daemon-reload && systemctl enable hdparm-sda && systemctl start hdparm-sda.
cron.hourly
When you look into /var/log/syslog, you see messages like
CRON[393]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Of course, we can’t have these messages written to a log if we want the disk to remain spun down, so edit /etc/crontab and comment out the hourly job. As long as /etc/cron.hourly is empty, this will not do any harm. If you have any hourly jobs, you might want to move them to daily jobs.
systemctl timers
Systemctl has its own cron-like timer mechanism. You can view active timers with systemctl list-timers --all and disable ones you don’t need, especially ones that run more than once a day. systemctl disable snapper-timeline.timer && systemctl stop snapper-timeline.timer.
smartd
If you have smartmontools installed (apt-get install smartmontools), you’ll see lines like the following appear in the syslog when the disk is spun down:
smartd[294]: Device: /dev/sda [SAT], is in STANDBY mode, suspending checks
Writing these messages causes the disk to spin up, so we need to disable smartd: systemctl stop smartd && systemctl disable smartd. To keep monitoring our disks, put the following into /etc/cron.daily/smart-check and then chmod +x /etc/cron.daily/smart-check:
#!/bin/bash /usr/sbin/smartctl -q errorsonly -A /dev/sda
systemd-tmpfiles-clean
When you run
inotifywait -m -r -e access -e modify -e create -e delete --timefmt '%c' --format '%T PATH:%w%f EVENTS:%,e' --exclude '/(dev/pts|proc|sys|run)' /
to see what is going on on your disk, you’ll see that your temporary directories are being cleaned every couple of minutes. We can reduce that to bi-weekly by running systemctl edit systemd-tmpfiles-clean.timer and pasting
[Timer] OnBootSec=5min OnUnitActiveSec=14d
postfix
If you have Postfix installed, inotify will also show you that it periodically checks its queue directories. So uninstall postfix (apt-get remove postfix) and configure a forwarding MTA that does not run as a daemon.
systemd-timesync
This last one was tricky to discover because it doesn’t appear in the logs and inotify doesn’t see it. You can logging of every disk access to the kernel log to see even more, but you need to disable syslog, otherwise you’ll get a self-amplifying write cascade.
systemctl stop syslog.socket systemctl stop rsyslog.service dmesg -C echo 1 | sudo tee /proc/sys/vm/block_dump dmesg -Tw
Here you’ll see that systemd-timesyncd stores its last sync date by touching a file. It only changes metadata, which is why inotify doesn’t see it happening. My solution was to put the following into /etc/tmpfiles.d/zz-clock.conf:
d /run/systemd/timesync 0755 systemd-timesync systemd-timesync - - f /run/systemd/clock 0644 systemd-timesync systemd-timesync - - f /run/systemd/timesync/clock 0644 systemd-timesync systemd-timesync - - L+ /var/lib/systemd/timesync/clock - - - - /run/systemd/timesync/clock L+ /var/lib/systemd/clock - - - - /run/systemd/clock
/var/lib/systemd/clock is used by systemd 234 and lower, while /var/lib/systemd/timesync/clock is used by systemd 235 and higher. So the latter will only be needed once you upgrade to Debian 10.