Ubuntu
distributed-net package

Would a flush operation at shutdown be good?

Asked by Jim Cheetham

When shutting down the dnetc client, I'd like to flush any completed work to the dnet servers.

This could be inplemented with an option in /etc/default/distributed-net :-
FLUSHONSTOP=true

and a small addition to the "stop)" section of /etc/init.d/distributed-net

        ...
        if start-stop-daemon --quiet --stop --signal 0 --user daemon --name dnetc 2>/dev/null; then
        ----- if [ ! -z "$FLUSHONSTOP" ]; then
                  su daemon -c "$DAEMON $OPTIONS -flush"
            fi
            su daemon -c "$DAEMON $OPTIONS -shutdown" 2>&1
            ...

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu distributed-net Edit question
Assignee:
No assignee Edit question
Solved by:
Jim Cheetham
Solved:
Last query:
Last reply:
Revision history for this message
James E. Stark (jstark-ieee) said : 		#1

As the distributed-net package maintainer I am strongly against this. As it is the distributed.net client has problems shutting down. The distributed.net client has been know to hang, or otherwise ignore the shutdown command. When the system is shutting down this will grind the entire process to a halt waiting for distributed.net, which may not ever stop. There is a hack in the shutdown section of the init script to attempt to deal with this case. If distributed.net hasn't stopped after 30 seconds the init script will send all matching processes SIGKILL (since the startup process doesn't return pid(s)), and assume that the it is dead. The last think that I want to do is add some dependency on contacting some server over the internet to send it data while the system is trying to shutdown. What happens if your connection is having problems? How long should we wait for this to complete? It just get ugly. Also keep in mind that the init script can't tell the difference between a system shutdown and a user requested shutdown of distributed.net.

In my opinion there isn't much to be gained from this either. If you are shutting down for a short time then the worst case is that your results won't be counted in your stats for a few days. If you shutdown and leave it for a long time then the distributed.net servers will reissue the units in your queue to another client. The next time that you sync with the server you will get credit for doing the work. If you're still worried about this then you could look at the flush target in the init script.

Revision history for this message
Jim Cheetham (jim.cheetham) said : 		#2

OK, I wasn't aware that the client had so many issues :-) Adding extra dependancies doesn't help, agreed.

The flush operation blocks, and to correctly give this a timeout you'd have to mess around backgrounding it while starting a timer. Not the sort of thing shell scripts are best used for. I'll probably just cron a flush to happen every so often instead.

(The main usecase is a desktop machine that is so slow it only completes a packet of work every couple of days. It is shutdown daily, so having a regular flush helps to avoid having the work-units reallocated to other users simply because no-one has heard from the machine in a long time ...)