dccifd 1.2.49 dying, any help?

Vernon Schryver vjs@calcite.rhyolite.com
Sat Jun 12 21:13:34 UTC 2004

> From: Henrik Edlund 

> I just prefer to start all servers from rc.local and the way I started it 
> was the same way start-dccifd does. 

If that were true, you would not have encountered the dccifd core-dump.

>                                     The benefit with my approach is that I 
> do not have to update some config file in the dcc directory every time I 
> upgrade and start over with a fresh default directory (keeping in mind the 
> entire dcc installation is kept inside its own version-dependent directory 
> in order not to infect any other part of the system). Now I can upgrade 
> dcc and symlink "dcc" to "dcc-1.2.49" and the system will pick up and use 
> the new version after a "kill-old-daemon, start-new-daemon". Without 
> having to enable dccifd in some config file (dcc_conf I presume).

In my view it is a serious bug for installing a new version to break
a working installation unless the version skew is enormous.  That
includes messing with control files.  The DCC `make install` generates
a dcc_conf-new using your existing dcc_conf, but it does not change
your existing dcc_conf.  The dcc_conf-new is not required if you don't
want any new features.  Dcc_conf has a version number so that the
scripts can do the right things when they change but the form of
the configuration script doesn't.

> > The only fanciness in start-dccifd is to shut down an existing instance
> > of the daemon and to get parameters from dcc_conf.  Given the nature
> > of UNIX domain sockets, you must stop it before restarting it.
> kill `cat /path/to/pid/file` works splendily for any daemon. "pkill 
> dccifd" as well if you want to be a bit Solaris-like.

`kill` does not work very well for daemons that catch signals so
that they can clean up.  Dccifd takes several seconds to exit for
various reasons I'd like to fix but don't see how without making
bigger problems.  Dccd can take a long time to exit.

There's always `kill -9`, but applied to dccifd that will leave a stray
UNIX domain socket, a minor issue.  Applied to dccd it will leave the
database possibly corrupt and certainly requiring at least several and
sometimes tens of minutes of attention from dbclean before dccd can
restart.  That's a major issue.

> [offtopic] I compile and install all server software that accept remote 
> connections myself plus other server software. That way I know exactly 
> what patches are applied, what versions I run and I can upgrade directly 
> when I need to, even if the company/group has not released new packages. 

Even if you read all of the code you install, you don't really know
what you're running.  For example, if you really knew, you would have
recognized the bug in the new version of dccifd before you installed
it.  There is always a necessary element of trust and ignorance about
what you're really running, even if you run only own code that you
write.  I don't like 3rd party "distributions" or what seem to be
random collections of patches because they break that trail of trust.

Vernon Schryver    vjs@rhyolite.com

More information about the DCC mailing list

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