On Thu, 1 Nov 2012 14:03:31 +0100, Thomas Hood wrote: > Well, the first thing I have done is to read the patch. I can at least say > that the patched code runs resolvconf with the correct syntax and that you > have the right idea. > > I don't know the wicd code very well, so I can't comment on whether or not > you are in fact calling FlushDNS() or flush_dns_addresses() in all the > right places. If iface.FlushDNS() gets called when iface gets deconfigured > and if FlushDNS() gets called on all configured ifaces when the app quits, > then you have done it right. :)
Heh :)
> To cause DNS to be flushed when the process is terminated you will have to
> atexit.register(on_exit) where
>
> def on_exit():
> for iface in list_of_active_ifaces:
> iface.FlushDNS()
>
> I see you already use atexit.register in the daemon, so you know what I am
> talking about.
Yes, *but* I really consider it a feature of wicd, that in the case of a crash,
the connection will keep working.
In fact, even killing the daemon, doesn't stop wpa_supplicant or deconfigures
interfaces. Flushing DNSes would make this feature vanish for resolvconf users.
I'd prefer to keep it, unless someone badly complains about leaving a
connection alive after killing wicd.
> Remark: You should run FlushDNS *before* deconfiguring the interface, thus
> (I presume) before doing SetAddress('0.0.0.0') or anything like that.
I'm running FlushDNS *before* putting the interface down, so I assume it's
already what you mean here.
> Remark about the _connect() functions: I see you "take down interface"
> before you "bring up interface". If you are entirely sure that you are very
> shortly going to do "resolvconf -a foo.wicd" (after bringing up the
> interface) then you don't have to do "resolvconf -d foo.wicd" first (before
> taking it down) and it might be a worthwhile optimization to skip
> the "resolvconf -d foo.wicd", keeping in mind that there is a run-parts on
> a hook script directory involved. But if it's possible that we don't get so
> far as "resolvconf -a foo.wicd" or if it can take a significant amount of
> time to get there, then it's safer to keep the initial "resolvconf -d
> foo.wicd" that you have included in the patch.
I've seen those operations being delayed for a number of reasons; even buggy
kernel drivers. I'd prefer to keep it failsafe. Thanks for the remark, though :)
I already asked for an unblock request to Debian release managers; in the
meanwhile I'll commit it upstream.
Thanks for your help,
David
--
. ''`. Debian developer | http://wiki.debian.org/DavidPaleino
: :' : Linuxer #334216 --|-- http://www.hanskalabs.net/
`. `'` GPG: 1392B174 ----|---- http://deb.li/dapal
`- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
signature.asc
Description: PGP signature
