Solved: hibernation problem on the DNS-323

[yannick]

A known problem of running SBS on a DNS-323 is that the disk never hibernate.
Some time ago I had presented in this post (http://forums.slimdevices.com/showpo...&postcount=110) a simple solution to make the server start/stop automatically when a client connects to it. This solution involving the SvrPowerControlPlugin (see http://forums.slimdevices.com/showthread.php?t=48521) and a simple script listening for a connection on the port used by SBS basically worked and the script was largely improved by Sydney on his blog (http://bfg100k.blogspot.com/2009/05/...ezecenter.html) but it also had a drawback: when you try to connect a squeezebox to a "sleeping" server using this technique, you have to wait about 2min for the server to be up before you can hear music. This is a trade-off to save energy and the lifetime of your hard-disk, but it is not really comfortable.
After having posted my technique I was busy on other things and hadn't looked again at this until shortly when I tried different approaches to get the disk sleep without this drawback.

The first thing I tried was to move the ffp plugins to an USB stick. There are several ready to use scripts on the internet to do that easily. I used this one (http://forum.dsmg600.info/t3203-setu...ount-root.html) as well as the additional explanations there: (http://bfg100k.blogspot.com/2008/11/...it-to-usb.html).
Moving ffp to an USB stick doesn't solve the hibernation problem with Squeezebox Server, because the swap file is still on the disk. But it makes ffp self contained on the stick (you can remove the stick to boot without it), and allows the disk to stay down until you really need it.

The next thing I tried was to move the swap file to the USB stick. There are good instructions there (http://forum.dsmg600.info/viewtopic.php?id=3400) explaining how to do it. The result was disappointing: it removed the disk accesses that prevented the hibernation, but the read rate of the USB stick was so slow that everything ran at a felt pace of 10% the original speed of the system. Maybe the problem is that I used the cheapest 2Gb stick I could find, but I didn't want to invest more, since it is quite probable that the stick wouldn't last very long with the constant write operations caused by the swap. So I gave up that idea. I kept ffp on the USB stick but with a swap on the disk.

I finally looked a bit deeper in my original idea of waiting for client activity to start the full server and ran some tests to find a way to reduce this 2min waiting time before the server is up. My idea was that instead of running a small program starting the full SBS when clients connect, I could start at least a part of SBS up to a point that doesn't cause swap activities. During these tests, I found out that the real problem that made the disk wake up are the constant communication between SBS and MySQL (apparently 1 query every 30s). That's how I came to the following solution:

- Instead a starting a dummy program listening on the port 3483 and starting SBS when a connection is detected, I start SBS until a point where it is at 95% initialized, but the network activity hasn't started yet. Then I freeze the execution at that point until a connection is detected on port 3483 (like with the old technique). SBS in this frozen status doesn't prevent the disk to swap. A part of goes to the swap, because it is too big to fit in memory, but since it sleeps, it is never read back from the swap before a connection is detected. Once a connection is detected, the initialiation of SBS is resumed and at the end the server is exactly in the same state as if it had been started normally. The difference between this approach and the old technique is that instead of having to wait 2min for the who server to come up, you only need to wait a couple of seconds for the last 5% of the initialization to start the network activity.
Later, when all clients are idle, the SvrPowerControl plugin is used to connect all clients to MySqueezeBox.com and restart the server which comes back in this sleeping state initialized at 95% until a client connects again.
The drawback of this technique is that it requires a small change in the code of SBS, but the change is so minimal that it can be done by anybody.

Here is the procedure to follow:

1)##### Prerequesites
My starting point is FFP 0.5 and SBS 7.4.1 installed from the fonz packages (http://www.inreto.de/dns323/fun-plug/0.5/) on an USB stick. I use the option of the USB script rebooting off the USB stick, since it is supposed to save more RAM (see explanation under http://forum.dsmg600.info/t3203-setu...ount-root.html). The firmware of my DNS323 is 1.05. I am pretty sure that the same technique would work even if ffp is not installed on an USB stick, but I didn't test.

2)##### Install the SrvrPowerControl plugin
- Telnet your DNS323

# cd /ffp/lib/squeezecenter/Plugins/
# wget -O SrvrPowerCtrl.zip http://srvrpowerctrl.googlecode.com/svn/SrvrPowerCtrl_beta.zip
# unzip SrvrPowerCtrl.zip
# rm SrvrPowerCtrl.zip

3)##### Modify Slimserver.pl
- Edit the file /ffp/lib/squeezeboxserver/slimserver.pl as follow (alternative you can replace it by the new version I attached to this thread, if you are using exactly the same version of SBS as I do: 7.4.1)

- Add the line in bold at the beginning of the file:

(...)
require 5.008_001;
use strict;
use warnings;
use Socket;

(...)

- Search for the following section in the code (line 456) and comment out the 2 lines in bold

(...)
    main::INFOLOG && $log->info("UDP init...");
    Slim::Networking::UDP::init();

#   main::INFOLOG && $log->info("Slimproto Init...");
#   Slim::Networking::Slimproto::init();                                    

    main::INFOLOG && $log->info("Cache init...");
    Slim::Utils::Cache->init();
(...)

- Search for the following section (at line 556) and add the code in bold

(...)
    Slim::Utils::Timers::setTimer(
            undef,                                                          
            time() + 30,
            \&Slim::Utils::Update::checkVersion,                            
    );                                                                      

    ####### Changed for DNS323
    ####### Suspend the execution until a client tries to connect
    my $ss_port = 3483;
    my $port = shift || $ss_port;
    my $proto = getprotobyname('tcp');

    # create a socket
    socket(SERVER, PF_INET, SOCK_STREAM, $proto) or die "socket: $!";
    setsockopt(SERVER, SOL_SOCKET, SO_REUSEADDR, 1) or die "setsock: $!";
    my $paddr = sockaddr_in($port, INADDR_ANY);

    # bind and listen
    bind(SERVER, $paddr)      or die "bind: $!";
    listen(SERVER, 1) or die "listen: $!";

    # wait for a connection
    my $client_addr = accept(CLIENT, SERVER);

    # Terminate connection with client
    close CLIENT;
    close SERVER;

    # Now start the UDP listening of the squeezebox server
    # (what was commented out before)
    main::INFOLOG && $log->info("Slimproto Init...");
    Slim::Networking::Slimproto::init();

    ####### End of Change

    main::INFOLOG && $log->info("Squeezebox Server HTTP enable...");
    Slim::Web::HTTP::init2();

    # otherwise, get ready to loop
    $lastlooptime = Time::HiRes::time();
(...)

4)##### Modify /ffp/start/slimserver.sh
This script needs to be slightly modified because in the current version the restart command fails, because it doesn't wait long enough for the server to be stopped before starting it again.
Edit the file and add the line in bold in the following section:

slimserver_stop()
{
    if [ -r /ffp/lib/squeezeboxserver/Logs/slimserver.pid ]; then
        kill $(cat /ffp/lib/squeezeboxserver/Logs/slimserver.pid)
    fi
    killall slimserver.pl 2>/dev/null
    sleep 30
}

5)##### Configure sudoers to allow the user nobody to restart SBS

# cd /ffp/etc
# chmod u+w sudoers
# echo "nobody ALL= NOPASSWD: /ffp/bin/sh /ffp/start/slimserver.sh restart" >> sudoers
# chmod u-w sudoers

6)##### Start the server

# sh /ffp/start/slimserver.sh start

With the command top, you can observe that it starts normally and at some point, with a memory usage of about 92% it sleeps.
Now let a client connect to it, and you'll see with top that it wakes up and the client gets the connection shortly after that.

7)##### Edit the properties of the SvrPowerControl:
Open the web interface, edit the properties of the SvrPowerControl plugin as follow:
- Check the option "Include “Shutdown to SqueezeNetwork” as a menu option?"
- Edit the command "Shutdown Command (include full path and cmd line args):" as follow:

sudo /ffp/bin/sh /ffp/start/slimserver.sh restart

- Let all the other options unchecked
- In the section "Idle Player Monitor", check the option "Monitor idle Player" and set the "Action to take after idle time:" to "Shutdown to SqueezeNetwork"
- Setup the idle time you allow before the server goes to bed.
- Save the properties

After all clients are idle for the time you set in the properties, you should see the process of the server stop and restart to the standby menu.

Note that if the clients are not completely powered off and still connected to the server, it will cause the server to fully start again. That's why it is recommanded to setup the properties of the SvrPowerControl to "Shutdown to SqueezeNetwork", and that you only connect to the DNS323 when you want to listen to your local library. For alarms and internet radio you can use SqueezeNetwork...

Yannick

[epoch1970]

I don't know this platform, but can you send signals to the squeezebox server process ?

kill -STOP <pid> should freeze the server, and kill -CONT <pid> to resume it.

[yannick]

I don't know this platform, but can you send signals to the squeezebox server process ?

kill -STOP <pid> should freeze the server, and kill -CONT <pid> to resume it.

Hi,

the platform is basically a linux. So yes kill -STOP/-CONT can freeze and resume the server. Thanks for the hint, I must admit that I hadn't thought about this possibility. But even if the kill command would have the advantage of having no delay at all, there would be a technical problem to solve: it would be easy to freeze the server by using the command "kill -STOP pid" with the SrvrPowerControl plugin, but how could you detect a client activity to resume it? With kill, even if the process is sleeping the port 3483 is still bound to it, preventing any other process to listen to the same port.

Any idea how client activity can be detected with any other method, or how to temporary unbound slimserver from the port 3483 during it sleeps, so that the wake up process can listen to it?

Yannick

[epoch1970]

Heh. I'm not an expert, but I believe that if the traffic is unicast or broadcast, there can only be one socket receiving the traffic.
On BSD (a mac) I have played with divert sockets (Net:: Divert on CPAN), but this doesn't exist on linux AFAIK. That's a slick trick to insert random curse words in the web pages fetched by an innocent browser ...
Divert sockets are a kind of raw sockets. So perhaps tcpdump/libpcap can help ? Is there a firewall on this machine ?
If so, I'd give a try to something like Net::Pcap::Easy, and send the kill signal in the callback.

The possibilities are endless

Also: I think the suspend signal is a possibility, but does it really work ? What does SBS do, when suddenly for him the time jumps from 13:30 to 18:45 ??

[norp]

Yannick
just registered to say thanks, even it this post is more than 1 year old!
your solution works great with SBS 7.6 beta installed on a QNAP TS410!

[Mooner]

Hi Yannick,

thanks for all of your input with everything relating to the DNS323 and Squeezecenter. Using your invaluable input I'm running version 7.5.3 off of a DNS320 (ffp installed on the disk not a USB)to stream (SUCCESSFULLY!) to a SBTouch and am attempting to get the NAS disks to spin-down between usage as per your above instructions.

Step 6 (the final Linux command) in your walkthrough:

# sh /ffp/start/slimserver.sh start

just isn't working for me though and the only way I can restart Sueezecenter is to reboot my DNS320. I don't get any error messages after hitting <cr> ....just the Telnet / # prompt. I have replaced "####### Changed for DNS323" with "####### Changed for DNS320" in step 3. As far as I can see this is the only assumed necessary difference in code betwen the two NASs?

Also, re your step 4 where I should modify to include " sleep 30 ", I seem to have an extra line of code to your screenshot in line 40 (right at the end of the script): "run_rc_command "$1" ". Should I close the script with } AFTER this?

Hopefully I have configured the sudoers correctly re your step 5. I simply telnet to the DNS320 then enter the code line by line. I'm new to Linux so I'm not sure what confirmations i should be seeing to confirm that the commands have been received

The ONLY other thing that doesn't match your walkthrough perfectly is that part of your code modification in step 3 shows || but I can only input ¦¦ in Telnet...even by copying and pasting your code

Many thanks - hoping I can get this working