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 [email protected]
