group.of.nepali.translators team mailing list archive

[Launchpad Bug Tracker <1536181@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package bind9 - 1:9.10.3.dfsg.P4-8ubuntu1.3

---------------
bind9 (1:9.10.3.dfsg.P4-8ubuntu1.3) xenial; urgency=medium

  * Add RemainAfterExit to bind9-resolvconf unit configuration file
    (LP: #1536181).

 -- Nishanth Aravamudan <nish.aravamudan@xxxxxxxxxxxxx>  Tue, 15 Nov
2016 08:30:31 -0800

** Changed in: bind9 (Ubuntu Xenial)
       Status: Fix Committed => 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:
  In Progress
Status in bind9 package in Debian:
  New

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