dccifd: restart after signal 6

Vernon Schryver vjs@calcite.rhyolite.com
Fri Jun 5 18:14:28 UTC 2009


> From: Petar Bogdanovic <petar@smokva.net>

> I just noticed the following irregularity since we replaced 1.3.103 with
> 1.3.105 on a NetBSD 4.0 machine (no virtualization):
>
> Jun  4 16:10:14 dccifd: restart after signal 6
> Jun  4 16:10:14 dccifd: 1.3.105 listening to /var/dcc/dccifd (...)
> Jun  4 16:10:14  spamd: dcc: dccifd -> check skipped: failed to read header (...)
> ...

> According to kill(1) on NetBSD, signal 6 is ``ABRT (abort)''.  What
> could that be?  It certainly never occured when we used 1.3.103.

Signal 6 generally comes from the abort() library function.  That
ought to be associated with a system log complaint about a major problem.

There should also be a core file in the DCC home directory.  That core
file might be useful with gdb if dccifd has been built with
debugging information.  
To rebuild the DCC software with debugging information, run

   .../libexec/updatedcc -e DBGFLAGS=-g

If the core file is for version of dccifd built with -g, 
then the following will get the stack trace on NetBSD with the DCC
home and libexec directories set to the defaults:

   % gdb /var/dcc/libexec/dccifd /var/dcc/dccifd.core
   bt
   exit



} From: MrC <lists-dcc@cappella.us>

} I had the same experience, and didn't have time to track the issue.  I
} reverted to dccproc for the time being.  I'd be curious about the
} situation too.

Is that also with NetBSD?


Vernon Schryver    vjs@rhyolite.com



More information about the DCC mailing list

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