On 17/07/2014 16:00, Zdeněk Zámečník wrote: Hi Zdenek, Looks like Knot is being run by upstart. In this case, killing Knot with "kill" or "knotc stop" will cause it to be restarted by upstart, because upstart's job is to keep services running. You will have to stop it by running "stop knot" or "initctl stop knot" (they are equivalent). Regards, Anand Buddhdev RIPE NCC

Hi Zdeněk, upstart was never not supported on Debian 7 as init system, thus the integration might not be ideal. I would suggest using some other supervisor to keep your processes running (runit, daemontools, systemd from backports). Cheers, Ondrej -- Ondřej Surý -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ ------------------------------------------- ----- Original Message ----- > From: "Zdeněk Zámečník" <zdenek.zamecnik(a)mauriceward.com> > To: "Anand Buddhdev" <anandb(a)ripe.net>et>, knot-dns-users(a)lists.nic.cz > Sent: Thursday, 17 July, 2014 18:24:05 > Subject: Re: [knot-dns-users] knot init in Debian > Hi Anand, > you are right. I just tried to remove package upstart and it works as I > expected. I'm going to place it back as I understand it ensures the knot > will start again in case of crash... > Maybe it would be fine to modify the init script to get it work with > upstart too. > > Thanks for the help! Best regards, > Zdenek > > > On 17.7.2014 16:47, Anand Buddhdev wrote: >> On 17/07/2014 16:00, Zdeněk Zámečník wrote: >> >> Hi Zdenek, >> >>> I have following issue with Knot: when I try to stop it by command >>> /etc/init.d/knot stop then the daemon is still running. If i run command >>> knotc stop then it's stopped but immediately run again. If I kill it by >>> command kill, it's the same... >>> >>> As I found the /etc/init.d/knot is not working at all and Knot is >>> probably run during boot by /etc/init/knot.conf and I'm not able to >>> control it. The "unkillable" proccess is named /usr/sbin/knotd -c >>> /etc/knot/knot.conf >> Looks like Knot is being run by upstart. In this case, killing Knot with >> "kill" or "knotc stop" will cause it to be restarted by upstart, because >> upstart's job is to keep services running. You will have to stop it by >> running "stop knot" or "initctl stop knot" (they are equivalent). >> >> Regards, >> >> Anand Buddhdev >> RIPE NCC > > > _______________________________________________ > knot-dns-users mailing list > knot-dns-users(a)lists.nic.cz > https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

Hello, I have recently upgraded our knot to 1.5.0. Then I noticed error messages coming from server Aug 20 05:50:31 knot-test knot[3723]: Incoming IXFR of 'domain.cz' from '192.168.122.193@53': Starting. Aug 20 05:50:31 knot-test knot[3723]: [error] Incoming IXFR of 'domain.cz' from '192.168.122.193@53': Failed - Malformed data. Aug 20 05:50:31 knot-test knot[3723]: [notice] IXFR of 'domain.cz.' with '192.168.122.193@53': Fallback to AXFR. I've done some debugging (I didnt find any more info), I also reproduced this on 2 virtual servers. My Configuration: Bind master (tried 9.8.4, 9.7.3) <-> Knot slave (tried 1.5.0, 1.5.1) allowed ixfr I dont know if its an error in knot or bind. AXFR works fine Thanks for any advices. Regards Jakub Stollmann LiveSport s.r.o. _______________________________________________ knot-dns-users mailing list knot-dns-users(a)lists.nic.cz https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

this is common when Bind sends AXFR when Knot asked for IXFR. Does this happen often?

It's been a while since I had to configure Bind, but I think you have to explicitly enable IXFR (ixfr-from-differences option and journal) or it will just send AXFRs for all requests.

How does the log file look on Bind's side?

On 08/20/2014 12:58 PM, Jakub Štollmann wrote: _______________________________________________ knot-dns-users mailing list knot-dns-users(a)lists.nic.cz https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

You're definitely right that this should not be treated as error (and this goes to any error during IXFR I suppose), because indeed there are cases when AXFR-style IXFR response is valid, Knot sends such responses as well. Our reasoning here was that this should happen rarely when things are set up properly, and, more importantly, we did not want to bloat the IXFR processing code. Nevertheless, we will fix this in the upcoming update.

I think it depends on how one modifies his zone.

So it seems for the manual zone file change + rndc reload combo you still need ixfr-from-differences enabled, but I'll admit I haven't tested this. I did not know BIND can create IXFRs from diffs between AXFRs, that's an interesting feature we might add to Knot.