DCC version 1.2.58

Vernon Schryver vjs@calcite.rhyolite.com
Wed Nov 3 20:02:30 UTC 2004


> From: David Sparks 

> The rebuild doesn't restart properly for me.  Is it supposed to or 
> should I stop the daemon before running the update script?

The first thing the updatedcc script does is stop the daemon.

> bind(UDP 209.139.197.116,6277): Address already in use; fatal error
> + trap 0 1 2 15
> + cdcc rtt
>
> dcc1 libexec # !cdcc
> cdcc 'id 1213' 'flood stats all'
> DCC server 127.0.0.1 at 127.0.0.1 not responding

That looks like the problem that the updatedcc stopping the daemon
first is intended to avoid, but often does not.
Perhaps the timeout in the script needs to be increased.

If this is the problem, then running updatedcc three times should 
(1) see the problem, (2) get dccd running again, and (3) not see
the problem becaues the in-core buffers will be empty or clean.


One would think that a reasonable mmap() implementation would continually
flush dirty buffers to the underlying file, particularly when the
application gives the kernel all kinds of hints about buffers are
currently least interesting.  However, as far as I know, no UNIX flavor
does a competent job of that.

So when you shut down dccd, the process stalls in close() as the
kernel writes the dirtied mapped buffers to the file.  If you have
a GByte of dirtied mmap() data, that can take a long time.


Perhaps I'm doing something wrong in srvrlib/db.c.  I've spent
a lot of time playing with lots of things to try to get various
UNIX flavors to flush dirty buffers.


Vernon Schryver    vjs@rhyolite.com



More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.