Bug 997030 - named-chroot.service should unmount all mounted files/dirs if it fails to start
named-chroot.service should unmount all mounted files/dirs if it fails to start
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Tomáš Hozza
Fedora Extras Quality Assurance
Depends On: 997031
  Show dependency treegraph
Reported: 2013-08-14 10:10 EDT by Tomáš Hozza
Modified: 2014-06-09 07:25 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Previously named-chroot.service set-up chroot environment for the named before starting the daemon by mounting necessary files and directories to the /var/named/chroot path. However if the start-up of the daemon failed, the mounts were not unmounted, but stayed there. This way the chroot environment got messed up. Note that also named-sdb-chroot.service used the same chroot path and suffered from the same imperfection. named-chroot.service and named-sdb-chroot.service have been modified and the chroot set-up code has been separated into new systemd service: - named-chroot-setup.service (for named) - named-sdb-chroot-setup.service (for named-sdb) As an addition named-sdb now uses its own chroot path '/var/named/chroot_sdb' and has been separated into its own subpackage 'bind-sdb-chroot' and is NOT a part of 'bind-chroot' package any more. Users that want to use named-sdb in the chroot have to install the 'bind-sdb-chroot' package.
Story Points: ---
Clone Of:
: 1004300 (view as bug list)
Last Closed: 2013-12-17 11:30:29 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tomáš Hozza 2013-08-14 10:10:05 EDT
Description of problem:
named-chroot.service should unmount all mounted files dirs if starting named
in chroot fails.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. install bind-chroot
2. break named.conf
3. # mount
4. # systemctl start named-chroot
5. watch it fail
6. # mount

Actual results:
After named-chroot failed to start, everything mounted into the
/var/named/chroot remains mounted.

Expected results:
Everything mounted into /var/named/chroot should be unmounted if named-chroot
fails to start.

Additional info:
Bug #984764

The best way how to do it is to extract the part that sets up/destroys the
chroot in named(-sdb)-chroot.service into a separate oneshot service that
would be stopped in case the service that requires it (named(-sdb)-chroot)
is stopped/failed to start/... Unfortunately to achieve this we need to use
StopWhenUnneeded unit option which is not working correctly at the moment.
Comment 1 Tomáš Hozza 2013-12-17 10:03:31 EST
I decided to fix this by dividing the package named-chroot into two subpackages:
- named-chroot (for named)
- named-sdb-chroot (for named-sdb)
and also by using different chroot path for named (/var/named/chroot) and
named-sdb (/var/named/chroot_sdb).
This also requires to extract the rndc key generation to a separate systemd unit and also extracting the setting-up/destroying of chroot into separate systemd
unit for each binary (named and named-sdb).

Although the best solution would be to use the systemd StopWhenUnneeded option,
it is not working OK now and systemd people are not showing any progress with it.

This change will apply only to rawhide to not break any existing installations.
Comment 2 Tomáš Hozza 2013-12-17 11:30:29 EST
Fixed in bind-9.9.4-10.fc21
Comment 3 Pieter D.J. Krul 2014-02-26 04:20:29 EST
(In reply to Tomas Hozza from comment #1)
> This change will apply only to rawhide to not break any existing
> installations.

Hello Tomas, 

Sorry for replying on a closed BZ, but I have a question;
At the time of this writing, on FC20 with testing-repo enabled, we have 


where I installed the latter about an hour ago.

As I understood from BZ#997031, the systemd part should be fixed, only the bind-chroot version is still the old one, hence broken. I can verify this by seeing a huge mess in the mount table:

root@fuzzy ~]# cat /proc/mounts | egrep -e bind -e named |  wc -l

Would you like me to create a new BZ, requesting to backport this from Rawhide / upstream to FC20?

With best regards,

Pieter Krul
Comment 4 Pieter D.J. Krul 2014-02-26 05:08:17 EST
Ok, I just did an RPM rebuild of bind-9.9.5-1-fc21.src on my FC20 machine, and can confirm that a) building and b) updating to this version works perfectly on FC20, without any regression that I could notice;

[root@fuzzy ~]# uname -a
Linux fuzzy.psyphoros.com 3.13.4-200.fc20.x86_64 #1 SMP Thu Feb 20 23:00:47 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

[root@fuzzy ~]# rpm -qa bind*

[root@fuzzy x86_64]# service named-chroot start
Redirecting to /bin/systemctl start  named-chroot.service

[root@fuzzy ~]# mount |grep named
/dev/mapper/vg_fuzzy-root on /var/named/chroot/etc/named type ext4 (rw,noatime,nodiratime,data=ordered)
/dev/mapper/vg_fuzzy-root on /var/named/chroot/etc/named.root.key type ext4 (rw,noatime,nodiratime,data=ordered)
/dev/mapper/vg_fuzzy-root on /var/named/chroot/etc/named.rfc1912.zones type ext4 (rw,noatime,nodiratime,data=ordered)
/dev/mapper/vg_fuzzy-root on /var/named/chroot/etc/rndc.key type ext4 (rw,noatime,nodiratime,data=ordered)
/dev/mapper/vg_fuzzy-root on /var/named/chroot/usr/lib64/bind type ext4 (rw,noatime,nodiratime,data=ordered)
/dev/mapper/vg_fuzzy-root on /var/named/chroot/etc/named.iscdlv.key type ext4 (rw,noatime,nodiratime,data=ordered)
tmpfs on /var/named/chroot/run/named type tmpfs (rw,nosuid,nodev,mode=755)
/dev/mapper/vg_fuzzy-root on /var/named/chroot/var/named type ext4 (rw,noatime,nodiratime,data=ordered)

Thank you, and best regards,

Pieter Krul

Note You need to log in before you can comment on or make changes to this bug.