[Pkg-dns-devel] Bug#807132: Bug#807132: Bug#807132: Related issue? unbound not restarted after upgrade

[Robert Edmonds]

There's a very important step missing in the text below, which is to
install the postfix package between steps 5 and 6. Sorry about that.

Robert Edmonds wrote:
> I've attached the unbound.service unit file that I've been working on
> that ports the functionality from the sysvinit script. I can reliably
> get this unit file to fail with the following steps:
> 
> 1) Start with a minimal installation of Debian testing in a virtual
> machine, with DHCP networking, and no MTA installed. /etc/resolv.conf
> should list the DNS resolvers learned from the DHCP server.
> 
> 2) Install unbound 1.5.8-1 from testing/unstable. This package uses the
> old sysvinit script. The default config listens on localhost only.
> 
> 3) Install resolvconf and reboot the VM. /etc/resolv.conf should now
> list the unbound server running on localhost.
> 
> 4) Copy the attached unbound.service file into /etc/systemd/system.
> I think there's a systemctl command you have to run to activate this so
> that it takes over from the generated unit file.
> 
> 5) Reboot the VM. It should still work and /etc/resolv.conf should still
> list the unbound server as before.
> 
> 6) Run "systemctl stop unbound.service". It should stop normally and
> /etc/resolv.conf should switch back to the resolvers learned from the
> DHCP server.
> 
> 7) Run "systemctl start unbound.service". This command will hang for a
> few minutes and then print:
> 
>     Job for unbound.service failed because a timeout was exceeded. See
>     "systemctl status unbound.service" and "journalctl -xe" for details.
> 
> 8) While that command is hung, "ps axfwu" shows the following process
> tree (edited slightly) corresponding to the resolvconf hooks being run.
> These are ultimately being invoked by the ExecStartPost= in the
> unbound.service unit file.
> 
> [...] /bin/sh -e /usr/lib/unbound/package-helper resolvconf_start
> [...]  \_ run-parts --arg=-a --arg=lo.unbound /etc/resolvconf/update.d
> [...]      \_ run-parts /etc/resolvconf/update-libc.d
> [...]          \_ /bin/sh -e /etc/resolvconf/update-libc.d/postfix
> [...]              \_ /bin/sh -e /etc/init.d/postfix reload
> [...]                  \_ /bin/systemctl --no-pager reload postfix.service
> 
> Also while the "start" command is hung, "systemctl list-jobs" shows the
> following output:
> 
>     JOB UNIT              TYPE   STATE
>     283 nss-lookup.target start  waiting
>     284 postfix.service   reload waiting
>     226 unbound.service   start  running
> 
>     3 jobs listed.
> 
> postfix's resolvconf hook (/etc/resolvconf/update-libc.d/postfix) calls
> back into the init system to reload postfix when /etc/resolv.conf has
> been changed by resolvconf, and this resolvconf hook is itself running
> as a result of the init system starting unbound. This must be causing
> some sort of dependency cycle or deadlock somewhere.
> 
> That's as far as I've gotten.

-- 
Robert Edmonds
edmonds at debian.org