Bug 997030

Summary:	named-chroot.service should unmount all mounted files/dirs if it fails to start
Product:	[Fedora] Fedora	Reporter:	Tomáš Hozza <thozza>
Component:	bind	Assignee:	Tomáš Hozza <thozza>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	19	CC:	pkrul, thozza, vonsch
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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:
Clones:	1004300 (view as bug list)		Environment:
Last Closed:	2013-12-17 16:30:29 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	997031
Bug Blocks:

Description Tomáš Hozza 2013-08-14 14:10:05 UTC

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):
bind-9.9.3-5.P2.fc19

How reproducible:
always

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 15:03:31 UTC

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 16:30:29 UTC

Fixed in bind-9.9.4-10.fc21

Comment 3 Pieter D.J. Krul 2014-02-26 09:20:29 UTC

(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 

systemd-208-14.fc20
bind-chroot-9.9.4-11.P2.fc20

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
4615

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 10:08:17 UTC

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*
bind-chroot-9.9.5-1.fc20.x86_64
bind-license-9.9.5-1.fc20.noarch
bind-libs-9.9.5-1.fc20.x86_64
bind-utils-9.9.5-1.fc20.x86_64
bind-libs-lite-9.9.5-1.fc20.x86_64
bind-9.9.5-1.fc20.x86_64

[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