One more thing - could you try adding

After=network-online.target

to kresd.socket?

Ondřej


On Fri, 6 Oct 2017, 21.51 Ondřej Surý, <ondrej@dns.rocks> wrote:
When it's not starting is there anything else listening on UDP or TCP port 53? 

Did you tweak the configuration or is it running on default config? 

Ondřej 

On Fri, 6 Oct 2017, 20.21 Thomas Van Nuit, <thomasvannuit@protonmail.ch> wrote:
Hello,

thank you for your reply.

The IP is definitely correct and there isn't anything else installed on the system, only Knot Resolver.
After a few reboots I've observed that sometimes the service starts OK, sometimes it fails. Is it possible that there is some sort of race condition?
First I thought it's with systemd-resolved, which I disabled. But that didn't help. I have to manually start kresd.socket again to get it working. After disabling the systemd-resolved there was nothing else listening on ports 53 (TCP or UDP), the error was the same.

Since no one else in this mailing list seems to have this problem I must be missing something elementary.

Thanks!

--
Regards,
Thomas Van Nuit

Sent with ProtonMail Secure Email.

-------- Original Message --------
Subject: Re: [knot-dns-users] Knot Resolver autostart on systemd
Local Time: October 1, 2017 11:34 PM
UTC Time: October 1, 2017 9:34 PM
To: Thomas Van Nuit <thomasvannuit@protonmail.ch>


On 10/01/2017 11:26 PM, Thomas Van Nuit wrote:
What is the proper way of autostarting Knot Resolver 1.4.0 on systemd (Debian Stretch in my case) to be able to listen on interfaces other from localhost?
[...]

Oct 01 23:17:12 <myhostname> systemd[1]: kresd.socket: Failed to listen on sockets: Cannot assign requested address
Oct 01 23:17:12 <myhostname> systemd[1]: Failed to listen on Knot DNS Resolver network listeners.
Oct 01 23:17:12 <myhostname> systemd[1]: kresd.socket: Unit entered failed state.

I'm not sure immediately.  My first guess would be that either the address is wrong (i.e. not assigned to this machine), or some other daemon is already listening on that IP:port combination.


Also, this is also in the log (again, Debian default):
Oct 01 23:18:22 <myhostname> kresd[639]: [ ta ] keyfile '/usr/share/dns/root.key': not writeable, starting in unmanaged mode
The file has permissions 644 for root:root. Should this be owned by knot, or writeable by others?

In general, it depends on how you want to update the root.key.  In Debian it's within a package by default, and therefore it's read-only and updates are left to on the package system.  Another way is to have a writable file and let kresd manage it according to RFC 5011.

--Vladimir


_______________________________________________
knot-dns-users mailing list
knot-dns-users@lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
--
Ondřej Surý <ondrej@sury.org>
--
Ondřej Surý <ondrej@sury.org>