Bind9 service does not source OPTIONS from /etc/default/bind9

[lioncub]

Ubuntu 16.06 x86_64

Doesn't work OPTIONS from /etc/default/bind9

$sudo service bind9 stop
$cat /etc/default/bind9
 # run resolvconf?
 RESOLVCONF=no
 # startup options for the server
 OPTIONS="-u bind -4"

$ sudo service bind9 start
$ ps ax | grep named
 1112 ? Ssl 0:00 /usr/sbin/named -f -u bind

Where option "-4"?

In Ubuntu 14.04 this good work!

[vvhk (vvhk-deactivatedaccount-deactivatedaccount)]

This affects me as well on Xenial. It works in Debian, and the difference is this, in the bind9 systemd unit file:

[Service]
EnvironmentFile=/etc/default/bind9
ExecStart=/usr/sbin/named -f $OPTIONS

Debian's unit sources the env file and $OPTIONS from it are in effect.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Christian Ehrhardt  (paelzer)]

The fix you mention in Debian is likely this:
   [ Stefan Bader ]
   * Use the defaults file in systemd.

And that is actually a Ubuntu Developer, so I'd wonder that this is not in Ubuntu.
That came in on "Thu, 19 Jan 2017"
The Debian Version this came in is not merged into Zesty, so it will be the artful release very likely.

Given the fact that this was driven by Stefan I'll subscribe him.
He might know if there already is a bug to track pushing that into an SRU for X/Y/Z releases.

[Stefan Bader (smb)]

I thought I had created a ubuntu bug, but I cannot find any. So I probably hoped that the Debian fix would end up getting merged back sooner than artful. So we should just use this report for the SRU.

[Andreas Hasenack (ahasenack)]

This is fixed in artful:
/lib/systemd/system/bind9.service:
[Service]
EnvironmentFile=/etc/default/bind9
ExecStart=/usr/sbin/named -f $OPTIONS

I changed /etc/default/bind9 in the same way as the OP and it worked:
 4555 ? Ssl 0:00 /usr/sbin/named -f -u bind -4

[Timo Aaltonen (tjaalton)]

fixed in bionic at least

[Robie Basak (racb)]

Zesty is EOL, so this bug won't be fixed in Zesty.

The problem in Xenial is still valid, but at this stage I think it's no longer appropriate to fix, as a workaround is available (by overriding the systemd service locally) and I'd be concerned about changing behaviour for existing users who did tweak /etc/default/bind9 but then did something else. So I'm going to mark this as Won't Fix for Xenial also, but am open to reconsidering it if someone can provide a compelling reason.