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.
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.
Fixed in bind-9.9.4-10.fc21
(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
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