Re: conntrackd won't start, "can't open multicast server!"

[Pablo Neira Ayuso <pablo@netfilter.org>]

Max Kellermann wrote:
> Waking up daemons without a reason is sloppy design most of the time.
> A quick look at the conntrackd code made me believe that conntrackd
> just doesn't check when the next scheduled event is due, and instead
> performs a check on all alarm objects in the current step 5 times a
> second.  That is easily fixable, and not only saves CPU cycles and
> power, but also leads to better overall design.

Indeed. This makes a lot sense to me. I have committed a patch to SVN to
wake up the daemon only if there is any alarm event to process instead
of polling. I'll do some testing of it tomorrow.

> The whole alarm.c looks like duplicated effort, you could have used
> libevent instead.

Well, I think that libevent is too much since conntrackd handles not
that many descriptors and the alarm implementation is enough for what
conntrackd needs IMO.

> By the way, I saw an add_alarm() in cache_timer.c, but its callback
> function "timeout()" neither sets a new "expires" value, nor does it
> delete the alarm object.  That may lead to integer underflow in the
> next do_alarm_run() invocation.

I have also changed this since I needed it for the lastest commit.
However, AFAICS such underflow doesn't ever happen in 0.9.5.

>> I'll investigate this. Are you using 0.9.5 or a SVN snapshot? Are
>> you using the `alarm' mode (formely known as `persistent')?
> 
> I am using the most recent release, i.e. 0.9.5.  I have no idea about
> "alarm" or "persistent" mode, and I did not find any documentation on
> this.  I am using the "stats" example configuration from the tarball.

Please, could you check out a working copy from SVN and tell me if the
problem that you're reporting persists?

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers