Red Hat Bugzilla – Bug 1305519
Named service does not conflict with named-chroot service
Last modified: 2016-02-09 06:02:34 EST
Description of problem:
I can start named and named-chroot at the same time without conflict even though they clearly conflict as they utilise the same files (errors in logs relating to malformed transaction because serials didn't match).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. systemctl start named-chroot
2. systemctl start named
Two named daemons running in conflict with one another.
For the second named to start to known itself to be in conflict with the first.
I think simply adding "Conflicts=named.service" would be appropriate to add to the service definition.
The thing is that you could have the chrooted instance running with different configuration and actually on different address and/or port.
I agree that in the default configuration, when you just install both packages, you are able to start both variants of BIND and one of them (the second) will fail.
However one can have a different configuration file in the /var/named/chroot/etc/ and in that case, it is used. I know that couple of users are actually doing this. I'm not sure how many people run two instances of BIND on the same system (one in chroot, the other outside of it), however adding the conflict into the service file would just introduce artificial constrains for some of the users.
I'm closing this as WONTFIX as I don't think we should add artificial constrains that would prohibit potentially valid use cases.
Sorry to poke a closed bug but I do not believe it is true that you can have different configurations.
On the system that I have (RHEL7) I can see that the directories have been "mount --bind".
/dev/mapper/VolGroup00-lv_root on /var/named/chroot/etc/localtime
/dev/mapper/VolGroup00-lv_root on /var/named/chroot/etc/named
/dev/mapper/VolGroup00-lv_root on /var/named/chroot/etc/named.root.key
/dev/mapper/VolGroup00-lv_root on /var/named/chroot/etc/named.conf
/dev/mapper/VolGroup00-lv_root on /var/named/chroot/etc/named.rfc1912.zones
/dev/mapper/VolGroup00-lv_root on /var/named/chroot/etc/rndc.key
/dev/mapper/VolGroup00-lv_root on /var/named/chroot/usr/lib64/bind
/dev/mapper/VolGroup00-lv_root on /var/named/chroot/etc/named.iscdlv.key
tmpfs on /var/named/chroot/run/named type tmpfs
/dev/mapper/VolGroup00-lv_root on /var/named/chroot/var/named
Found that the "mount --bind" is documented:
But I also note it has some check to determine if the directories are empty before using "mount --bind" which I was unaware of.
"The following directories are automatically mounted into the /var/named/chroot/ directory if the corresponding mount point directories underneath /var/named/chroot/ are empty"
Not sure if there is any successful logic that can be wrapped on that, or indeed if there should be any at all.
So the bottom line as you've already found out is, that you can have a completely different configuration, in case you placed all the directories and files into the /var/named/chroot/ directory.
In case some of the important files/directories are not present in /var/named/chroot/, then these are bind-mounted which would result in some of the configuration and directories being shared between the instances of BIND (which may be a problem, but not necessarily).