unbound DNS killed immediately after starting

Question

I'm trying to set up unbound as my DNS resolver, but it seems that unbound terminates immediately after starting. Nothing in the logs seems to suggest why that is happening. This server has pi-hole installed on it and is also running an Apache webserver.

The config file is exactly as in pi-hole's documentation, except that logfile is changed to /var/log/unbound/unbound.log and verbosity is set to 2.

Starting unbound using service unbound start will result in systemd attempting to start unbound over and over again.

Jan 28 15:58:51 srv01 systemd[1]: unbound.service: Main process exited, code=killed, status=9/KILL
Jan 28 15:58:51 srv01 systemd[1]: unbound.service: Failed with result 'signal'.
Jan 28 15:58:51 srv01 systemd[1]: Failed to start Unbound DNS server.
Jan 28 15:58:51 srv01 systemd[1]: unbound.service: Service hold-off time over, scheduling restart.
etc..

Running it in the foreground shows this:

[1584217278] unbound[31341:0] notice: Start of unbound 1.6.7.
[1584217278] unbound[31341:0] debug: increased limit(open files) from 1024 to 4140
[1584217278] unbound[31341:0] debug: creating udp4 socket 127.0.0.1 5353
[1584217278] unbound[31341:0] debug: creating tcp4 socket 127.0.0.1 5353
[1584217278] unbound[31341:0] debug: creating tcp4 socket 127.0.0.1 8953
[1584217278] unbound[31341:0] debug: setup SSL certificates
[1584217278] unbound[31341:0] warning: did not exit gracefully last time (30708)
[1584217278] unbound[31341:0] debug: chdir to /etc/unbound
[1584217278] unbound[31341:0] debug: drop user privileges, run as unbound
[1584217278] unbound[31341:0] debug: switching log to /var/log/unbound/unbound.log
Killed

The log file output from the last run is:

[1584216438] unbound[30708:0] debug: module config: "subnetcache validator iterator"
[1584216438] unbound[30708:0] notice: init module 0: subnet
[1584216438] unbound[30708:0] debug: subnet: option registered (8)
[1584216438] unbound[30708:0] notice: init module 1: validator
[1584216438] unbound[30708:0] debug: reading autotrust anchor file /var/lib/unbound/root.key
[1584216438] unbound[30708:0] info: trust point . : 1
[1584216438] unbound[30708:0] info: assembled 0 DS and 2 DNSKEYs
[1584216438] unbound[30708:0] info: DNSKEY:: .  172800  IN  DNSKEY  257 3 8 <redacted> ;{id = 20326 (ksk), size = 2048b}

[1584216438] unbound[30708:0] info: DNSKEY:: .  172800  IN  DNSKEY  257 3 8 <redacted> ;{id = 19036 (ksk), size = 2048b}

[1584216438] unbound[30708:0] info: file /var/lib/unbound/root.key
[1584216438] unbound[30708:0] info: last_queried: 1584203277 Sat Mar 14 16:27:57 2020
[1584216438] unbound[30708:0] info: last_success: 1584203277 Sat Mar 14 16:27:57 2020
[1584216438] unbound[30708:0] info: next_probe_time: 1584242781 Sun Mar 15 03:26:21 2020
[1584216438] unbound[30708:0] info: query_interval: 43200
[1584216438] unbound[30708:0] info: retry_time: 8640
[1584216438] unbound[30708:0] info: query_failed: 0
[1584216438] unbound[30708:0] info: [  VALID  ] .   172800  IN  DNSKEY  257 3 8 <redacted> ;{id = 20326 (ksk), size = 2048b} ;;state:2 ;;pending_count:0 last:Sat Mar 14 16:27:53 2020
[1584216438] unbound[30708:0] info: [ MISSING ] .   172800  IN  DNSKEY  257 3 8 <redacted> ;{id = 19036 (ksk), size = 2048b} ;;state:3 ;;pending_count:0 last:Sat Mar 14 16:27:53 2020
[1584216438] unbound[30708:0] debug: validator nsec3cfg keysz 1024 mxiter 150
[1584216438] unbound[30708:0] debug: validator nsec3cfg keysz 2048 mxiter 500
[1584216438] unbound[30708:0] debug: validator nsec3cfg keysz 4096 mxiter 2500
[1584216438] unbound[30708:0] notice: init module 2: iterator
[1584216438] unbound[30708:0] debug: target fetch policy for level 0 is 3
[1584216438] unbound[30708:0] debug: target fetch policy for level 1 is 2
[1584216438] unbound[30708:0] debug: target fetch policy for level 2 is 1
[1584216438] unbound[30708:0] debug: target fetch policy for level 3 is 0
[1584216438] unbound[30708:0] debug: target fetch policy for level 4 is 0
[1584216438] unbound[30708:0] debug: donotq: 127.0.0.0/8
[1584216438] unbound[30708:0] debug: EDNS known options:
[1584216438] unbound[30708:0] debug:   Code:    Bypass_cache_stage: Aggregate_mesh:
[1584216438] unbound[30708:0] debug:   edns-cli NO

Is there any way of knowing why did the process receive a SIGKILL?

Answer 1

can you run unbound manually in terminal by following

unbound -d

Because you want the early error in logs, unbound will verbose on terminal only for early errors before logging.