Re: scheduling while atomic followed by oops upon conntrackd -c execution

[Kerin Millar <kerframil@gmail.com>]

On 08/03/2012 01:33, Pablo Neira Ayuso wrote:
> Moreover, I need to know if there was some traffic circulating
> through the backup or no traffic at all.

Sorry, I didn't address this point in my previous email. The backup does 
indeed handle some traffic. Both systems run BIND and, as such, the 
backup is also our secondary public-facing nameserver. The load 
generated by this is not significant though. At any given moment, the 
number of state entries hovers at between 100-150 and almost all of 
these are from UDP entries on account of DNS queries.

The rest can be accounted for by ntpd (about 4 active entries for 
upstream ntp servers), ssh (1 connection only), ICMP echo-request 
handling and a few other sundries.

In my test case, I am running conntrackd -c under circumstances where 
conntrackd on the master is still pushing events across. But, I have 
also simulated a realistic failover scenario on at least two occasions 
by shutting down the master (at which point, conntrackd terminates and 
is obviously no longer pushing events to the backup). Regardless, the 
backup still crashes upon conntrackd -c.

In summary:

* Both nodes are handling DNS traffic (but it's packet forwarding which
   really generates a heavy load)

* conntrackd -c has been run under circumstances where conntrack daemon
   is and isn't continuing to receive traffic from other node. It crashes
   anyway.

Cheers,

--Kerin