Never Mail me: Hunny

Never Mail me: Hunny Never Mail me: Hunny Never click here!
powered by EUserv
This page is part of my Western Digital My Book World Edition scratch pad.

Silencio! And make Space! And watch Time!


We want the box to be on steroids and valium at the same time: high-performing, but silent, energy-efficient, and long-lasting. Interestingly, caring for any of these goals / problems helps the others as well. Let's optimise the sleep mode. We can achieve this by a few steps freeing memory, stopping unused and useless tasks and optimise those tasks left to do their disk access more efficiently / less frequently. Besides we fight overheating, some poeple reported issues.

Free some memory

What is the issue of saving RAM, as long as the box has enough to work properly? To keep the disks sleeping, having as much free memory as possible is essential. The accessed files are cached in memory as long as the memory isn't needed for something else, thus having more free memory means more files in cache means less disk access means disks spin up less frequently. Besides, less disk access means more overall performance.

Your box has a huge hard disk and a fast NIC. Anything else is meagre, especially RAM and CPU are comparatively small and slow. So it helps a lot to get rid of services you do not really need. (Which is a proper way on any system anyway. On standard computers, I recommend the Less Watts site for a start.) Any running service, no matter how little it has to do, will steal some memory and will need some CPU time and wake up your disk at least once in a while. This is the chapter to do some optimisation concerning the objective to save resources, both inside the box, as well as your environment by reducing need for energy and raising lifetime.

Get rid of unneeded protocols and services

First the most simple step. Use your administrative web interface to switch off anything you don't need. As a rule of thumb: If you don't know it, you don't need it. Candidates for removal are:

Some things can't be switched off by the interface, so you go to your /etc/init.d directory to switch off things by hand. In Unix the standard procedure to have a service running means to have a start script (linked) here. The process starting the system will call any script named Snn* in numerical order. I recommend to not delete anything or edit too heavily, as this can break things and reactivation might be difficult. Clever people will have copies of the original anyway! Instead of deleting you could rename a file, so it does not follow the Snn* name standard and would not be called. e.g. Snnstartup to _off_Snnstartup, and you can always switch back easily. Or what I often do is to edit the file and add one line in the beginning of the start) section:

echo Self disabled; exit

This way a disabled service identifies itself as such when you try to start it manually.

Be careful not to disable services essential for the system to work and for you to access it. Do some misconfiguration, and disable ssh or the entire network by accident, and you have trouble! You get the idea.

The administrative web interface

The web interface needs a lot of memory. Ask yourself if and how often you need it. Consider to have it generally disabled, and start it manually in those rare situations. There is a nice idea to have it automatically start on demand only, first described here: lighthttpd on demand. But be careful, this script is for the Blue Ring Edition of the MBWE and needs quite some changes for the White Light. I will make my way public soon. I walked another path: Let the GUI start with system start, but shutdown after some time when it is not used. This way you keep your safety fallback when you do something stupid ;-) Never switch off both GUI and ssh at the same time!!!

Teach programs to behave

Optimise those services you don't want to switch off, so at least they don't access the disk too frequently.


If you did not judge twonky to be an unneeded service already, at least tell it to not automatically rebuild its database periodically, or at least set this time to a high value. You may prefer to start indexing manually whenever you really changed some content.


The MBWE does not have a true RTC (real time clock). Indeed, here they really overdid it to save hardware costs! There is a clock that runs as long as the system is powered up. In-between the box uses a stop-start time approach to at least guarantee time never steps backwards between system restarts: Scripts like /etc/rc.poweroff and /etc/rc.reboot, write the current time to /etc/.defaultRTC. This file is read on system start to initialise the RTC. Really bad: Paranoid to ensure timekeeping even between system failure like power loss, /etc/init.d/S99sxminit starts a job /usr/bin/php -q /proto/SxM_webui/admin/tools/monitorRTC.php that also regularly updates /etc/.defaultRTC! This will wake up the disk. Stop this.

The missing true RTC makes a properly working ntp client setting really necessary! But again the responsible job /etc/init.d/S85ntpdated behaves really stupid. It tries to find a time-server once on startup and then every day again. When it misses its first opportunity (because the timeserver in your LAN is not up or the internet is not connected) it runs a complete day on wrong time! The whole process must be made more reliable and lighter at the same time. You write your own job to get the time via net:

# ToDo: make file to ensure unique instance
# This file holds the ntp servers configured via web interface,
# fed by your configuration in the admin web gui.
servers=`cat /etc/ntpdate.conf`
# Current time according to our clock
ct=`/bin/date +%Y%m%d%H%M`
while ! /usr/bin/ntpdate $servers
sleep 300
ct=`/bin/date +%Y%m%d%H%M`
/bin/date +%Y%m%d%H%M > /etc/.defaultRTC
logger -t `basename $0` ntp success, old time: $ct

This script loops until ntpdate successfully synchronises with a time server once, then exits entirely. It will not occupy memory and wake up the disk by writing the timestamp again and again. This script should be nohupped and backgrounded in a startup script or by MyAnaCron. You disable the resident job by commenting the call /proto/SxM_webui/admin/tools/monitorRTC.php in S99sxminit, and you disable S85ntpdated or change it to call your script instead.


/usr/sbin/logrotate is started by /etc/init.d/S98logrotate and stays resident in memory. We better call this once a day via MyAnaCron. ... to be continued ...

Little daemon-like beasts

like e.g. /usr/bin/php -q /proto/SxM_webui/admin/tools/monitorRTC.php
more to come ...

Spin down the disk

This has its own chapter.