Hello

This is expected behavior.

If customer wants to change the name of the configuration file, they should copy the service file to /etc/systemd/system and modify the service file there. This means defining the '-c' option in ExecStart and also changing the ExecStartPre section. This is the only valid approach when they need such change.

To be honest, /etc/sysconfig/named stayed in RHEL mostly for historical reasons. The fact that you can change the configuration path is more of a side effect, than an intended behavior.

The check of the configuration before starting named is a distribution thing and is Red Hat specific. named-checkconf is part of the upstream project and therefore modifying it to read /etc/sysconfig/named is not an option, because upstream would never accept such change.

From my point of view there is not much to fix, except maybe to provide better documentation. Although the fact that if administrator needs to modify the the service file, they should do it in one of the supported ways. This is covered by System Administrators Guide [1]. Changing the location of the configuration is one of such changes.

[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html/System_Administrators_Guide/sect-Managing_Services_with_systemd-Unit_Files.html#sect-Managing_Services_with_systemd-Unit_File_Modify

Please communicate these facts to the customer. I'll leave the bug opened until the issue is resolved/communicated with the customer.

I'm lowering the severity, since there is an easy workaround (which is in fact the right way to address such problem).

Note: 7.2 update will include fix for #1236475 which will allow one to disable the named-checkconf check. However I believe this is not what the customer wants.

I understand and have conveyed that message to the customer.

Perhaps we need to add a warning to /etc/sysconfig/named. Or remove the "-c" as a valid option since it prevents the service from running.

There is already one for "ROOTDIR" since you can't use that option, it has its own syntax.

Possibly something along the lines of:
   "Using the -c option to specify a different configuration file is not supported"

*This is the intended method of using this file. But using it with the "-c" option, does not allow the service to start. 

Resolutions:

-Create a softlink (ln -s /etc/customnamed.conf /etc/named.conf) needs to be created so /etc/named.conf is still there.

-Modify the service file to account for the custom named.conf, per the instructions below:

[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html/System_Administrators_Guide/sect-Managing_Services_with_systemd-Unit_Files.html#sect-Managing_Services_with_systemd-Unit_File_Modify

Just a small comment, that the customer can easily use also systemd drop-in in a similar way as described in Bug #1278082 comment #13. I think this is the cleanest solution.

Created attachment 1267015 [details]
example systemd service extension

Example configuration extension for named systemd services. Place it into /etc/systemd/system/$SVC.service.d/custom-config.conf.
$SVC can be one of: named named-pkcs11 named-sdb named-chroot

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:1767