dccifd 1.2.49 dying, any help?

Henrik Edlund henrik@edlund.org
Sat Jun 12 20:47:40 UTC 2004

On Sat, 12 Jun 2004, Vernon Schryver wrote:

> It seems odd to trust your mail to my C programs

Well, the mail is just given a score and it is up to the user to decide if 
they trust you and DCC. Rejecting mail at SMTP level based on DCC would 
not honour the user's rights to receive and handle their own mail. Can't 
just go about that reject mail like that, spam or no-spam.

> but not trust my Bourne shell scripts to start those programs.

I just prefer to start all servers from rc.local and the way I started it 
was the same way start-dccifd does. 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).

> 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.

>> From your strace output, I inferred that you are running Linux.

I do, Slackware Linux. Keeping it simple and stable. :)

> Local control is another argument against "RPMs", "packages," "ports," 
> and so forth.  Such installation mechanisms make decisions about where 
> things should go that some people will consider wrong.

[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. 
Just look at RedHat's RPMs with hundreds of gray-zone patches so you have 
no idea if you are running a vunerable version or not, if things are 
fixed, or what the hell they patched away or in (packporting feature 
patches with security holes and so on). I also do not have to rely on and 
wait for distribution makers to release security updates. So basically I 
am not relying on pre-packaged software for server services. Knowing what 
code you run is #1 when it comes to security. [/offtopic]

More information about the DCC mailing list

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