Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Bind chroot mounts /var/named on top of /var/named/chroot creating 2 chroot directories
Version-Release number of selected component (if applicable):
bind-9.7.3-2.el6_1.P1.1.i686
bind-chroot-9.7.3-2.el6_1.P1.1.i686
How reproducible:
Starting the named service with an empty /var/named/chroot/var/named
Steps to Reproduce:
1. service named start
2. cd /var/named/chroot/var/named/chroot/var/named
[root@dns /]# service named start
Starting named: [ OK ]
[root@dns /]# cd /var/named/chroot/var/named/chroot/var/named/
[root@dns named]# pwd
/var/named/chroot/var/named/chroot/var/named
[root@dns named]#
Additional info:
BIND wont mount the /var/named directory on /var/named/chroot if there's data on /var/named/chroot/var/named, so copying everything but chroot would be enough to avoid the double chroot
[root@dns /]# cd /var/named
[root@dns named]# cp -rp [!chroot]* /var/named/chroot/var/named/.
[root@dns named]# service named start
Starting named: [ OK ]
[root@dns named]# ls -la /var/named/chroot/var/named
total 36
drwxr-x--- 5 root named 4096 Jun 23 09:53 .
drwxr-x--- 6 root named 4096 Jun 17 10:44 ..
drwxrwx--- 2 named named 4096 Jun 21 03:24 data
drwxrwx--- 2 named named 4096 Jun 23 10:37 dynamic
-rw-r----- 1 root named 1892 Feb 18 2008 named.ca
-rw-r----- 1 root named 152 Dec 15 2009 named.empty
-rw-r----- 1 root named 152 Jun 21 2007 named.localhost
-rw-r----- 1 root named 168 Dec 15 2009 named.loopback
drwxrwx--- 2 named named 4096 May 27 06:38 slaves
[root@dns named]#
(In reply to comment #0)
> [root@dns /]# service named start
> Starting named: [ OK ]
> [root@dns /]# cd /var/named/chroot/var/named/chroot/var/named/
> [root@dns named]# pwd
> /var/named/chroot/var/named/chroot/var/named
> [root@dns named]#
This feature (well, in this case it is more shortage than feature) is inherited from --bind mounts.
When /var/named is mounted into /var/named/chroot/var/named then entire /var/named subtree (which also contains chroot/var/named directory) is mounted into /var/named/chroot/var/named. This is explanation why /var/named/chroot/var/named/chroot/var/named exists. Its existence doesn't cause any issue.
I don't think this is a bug, closing.