Signed-off-by: Simon Deziel <simon@sdeziel.info>

There is no use for a PID file under systemd and
it's a better way to (Closes: #867192) now that
unbound supports skipping PID creation.

Signed-off-by: Simon Deziel <simon@sdeziel.info>

Signed-off-by: Simon Deziel <simon@sdeziel.info>

Signed-off-by: Simon Deziel <simon@sdeziel.info>

Signed-off-by: Simon Deziel <simon@sdeziel.info>

Signed-off-by: Simon Deziel <simon@sdeziel.info>

Signed-off-by: Simon Deziel <simon@sdeziel.info>

Signed-off-by: Simon Deziel <simon@sdeziel.info>

Signed-off-by: Simon Deziel <simon@sdeziel.info>

Closes: #919511

Signed-off-by: Simon Deziel <simon@sdeziel.info>

Gbp-Dch: ignore

Update to upstream version '1.9.0'
with Debian dir 1707f4dc7cf8010c754950b524b05aa680e365f5

Upstream version 1.8.1

Unbound release 1.8.0 introduced a bug in the upstream commit "Fix
use-systemd readiness signalling, only when use-systemd is yes and not
in signal handler" which only performs service manager state change
notification when "use-systemd: yes" is set, which controls whether
systemd socket activation is used, according to the unbound.conf
manpage.

On Debian, since we use [Service] Type=notify in the unbound.service
unit, this causes unbound starts/restarts to hang and timeout under
1.8.0, because "use-systemd: yes" (i.e., socket activation) is not
enabled, and unbound then fails to send the state change notification.
When unbound is compiled with systemd support, it should always
sd_notify() regardless of any settings in unbound.conf, because the
process startup type is controlled by the service unit, not by the
unbound.conf file, and sd_notify()'ing when not running under a
Type=notify service unit is harmless.

This commit restores the previous behavior which was introduced by
Vincent Bernat in the fix for Debian bug #892914 [0] and applied to
upstream unbound in [1].

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892914

[1] https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4108

Upstream version 1.8.0

Upstream version 1.7.3

Vincent Bernat authored Mar 14, 2018 and Robert Edmonds committed Jun 20, 2018

The systemd integration is a bit buggy with reload. On reload, unbound
will send STOPPING=1 then READY=1. After STOPPING=1 is sent, the
unbound-control process terminates. When receiving SIGCHLD, systemd
looks at the situation and transforms the "reload" state into a
"stop-sigterm" because of the STOPPING=1 notification previously sent:

Mar 14 13:07:54 infra-msg-pp002 systemd[1]: unbound.service: Child 13883 belongs to unbound.service
Mar 14 13:07:54 infra-msg-pp002 systemd[1]: unbound.service: Control process exited, code=exited status=0
Mar 14 13:07:54 infra-msg-pp002 systemd[1]: unbound.service: Got final SIGCHLD for state reload.
Mar 14 13:07:54 infra-msg-pp002 systemd[1]: unbound.service: Changed reload -> stop-sigterm

In this state, systemd waits for unbound to terminate. After a few
minutes, it will send SIGKILL to forcibly kill unbound.

[edmonds@debian.org: Commit imported from Debian bug #892914.]