** Changed in: bind9 (Debian) Status: New => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1536181
Title: bind9-resolvconf service doesn't work Status in bind9 package in Ubuntu: Fix Released Status in bind9 source package in Xenial: Fix Released Status in bind9 source package in Yakkety: Fix Released Status in bind9 package in Debian: Fix Released Bug description: [Impact] * If using the bind9-resolvconf service to have the local named managed resolv.conf, the service exits after running starting, and the system resolv.conf ends up reverting to the default content. * The user is effectively prevented from using bind9-resolvconf to manage their local resolv.conf. * The issue is that the bind9-resolvconf service needs to detected as still running even after the /etc/resolv.conf modification occurs. As per Debian Bug 744304: "RemainAfterExit tells systemd that a service should be considered running even after it exited. Currently, systemd thinks the service went inactive after the ExecStart command exits, and then immediately calls the ExecStop command, thus removing 127.0.0.1 from resolvconf." [Test Case] * Install bind9-resolvconf with a local bind9 configuration. Start the bind9-resolvconf service and the prior content of /etc/resolv.conf will remain even if it differs from bind9's configuration. [Regression Potential] * I believe the regression potential to be very low for this change. The bind9-resolvconf service currently does not work as expected. Users may have made manual changes locally, as suggested in this bug, but those seem to generally not be permanent solutions and should not collide with the change to the service. --- I enabled the bind9-resolvconf service and restarted my system, because I want to use the named running on localhost as my nameserver. Even after the restart, however, the nameservers in /etc/resolv.conf (actually /var/run/resolvconf/resolv.conf) were still the ones provided by DHCP. This, despite the fact that the logs claim that bind9-resolvconf ran successfully during boot. I tried manually running "sudo systemctl start bind9-resolv.conf", and again, the logs claim it ran, but /etc/resolv.conf was unmodified. Finally, I manually ran "sudo /bin/sh -c 'echo nameserver 127.0.0.1 | /sbin/resolvconf -a lo.named'", i.e., the command listed in /lib/systemd/system/bind9-resolv.conf.service, and _that_ successfully updated /etc/resolv.conf. After doing that, interestingly, "sudo systemctl stop bind9-resolv.conf" _also_ doesn't change /etc/resolv.conf, i.e., it still retains the 127.0.0.1 line which I added by running the resolvconf command manually. ProblemType: Bug DistroRelease: Ubuntu 15.10 Package: bind9 1:9.9.5.dfsg-11ubuntu1.2 ProcVersionSignature: Ubuntu 4.2.0-25.30-generic 4.2.6 Uname: Linux 4.2.0-25-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.19.1-0ubuntu5 Architecture: amd64 CurrentDesktop: Unity Date: Wed Jan 20 08:03:35 2016 InstallationDate: Installed on 2016-01-16 (4 days ago) InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021) RelatedPackageVersions: bind9utils 1:9.9.5.dfsg-11ubuntu1.2 apparmor 2.10-0ubuntu6 SourcePackage: bind9 UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.bind.named.conf: [modified] modified.conffile..etc.bind.named.conf.local: [modified] mtime.conffile..etc.bind.named.conf: 2016-01-16T19:01:39.827033 mtime.conffile..etc.bind.named.conf.local: 2016-01-16T21:13:51.991632 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1536181/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp