Re: Chroot Bind failed to start
Am 15.03.22 um 15:14 schrieb Paul Amaral: Reindi, thanks for the explanation, I do manually edit the zones because we don’t make many DNS changes these days and I usually do named-checkzone but I missed that this time, although I did reload that problematic zone with rndc reload and saw no errors. I do have bind restarting once a week via chron. It restarted early this morning and of course it failed to come up with no errors in the log, making it difficult to troubleshoot ☹ than do yourself a favor and include the named-checkzone in your cron script before restart it hard unattended in the middle of the night (besides a weekly restart without any reason is questionable as you see it's only asking for trouble) -Original Message- From: bind-users On Behalf Of Reindl Harald Sent: Tuesday, March 15, 2022 10:01 AM To: bind-users@lists.isc.org Subject: Re: Chroot Bind failed to start Am 15.03.22 um 14:37 schrieb Paul Amaral via bind-users: Neverminded, I was able to traceback my steps and realize a fat fingered a DNS entry in one of the zones, added two periods to an authoritative zone’s DNS record, causing bind to fail to start. The concerning issue was there was no error on the logs at all, making it hard to figure out the issue. that's the terrible packaging Which leads me to the next question, let’s say I’m authoritative for regular zone ABC.com and I fat fingered its DNS record, ns1..something.com. Why would this affect the bind instance from starting up? because that's what ExecStartPre is for if it fails the unit fails Like I said there was nothing on the logs and I understand that might be due to the Centos PKG itself. Just wondering why that mistake down bind down and how I can get more meaningful logs on the logs even those a prepackaged bind version. the ExecStartPre happens long before named it even tried to start, so it can't log anything - in my opinion the ExecStartPre stuff should go in it's own script and just log but not fail the unit with a non-zero exit code BTW: don't write directly in zone files and if you do so verify it at your own - good chances named would refuse to start at it's own with such errors that's why you *don't hard restart named* just because you changed a zone - a reload most likely would have logged the error and just refused to reload the zone itself you need tools for altering zones which would refuse such wrong input before they make it into the zone-file -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Chroot Bind failed to start
Reindi, thanks for the explanation, I do manually edit the zones because we don’t make many DNS changes these days and I usually do named-checkzone but I missed that this time, although I did reload that problematic zone with rndc reload and saw no errors. I do have bind restarting once a week via chron. It restarted early this morning and of course it failed to come up with no errors in the log, making it difficult to troubleshoot ☹. Paul -Original Message- From: bind-users On Behalf Of Reindl Harald Sent: Tuesday, March 15, 2022 10:01 AM To: bind-users@lists.isc.org Subject: Re: Chroot Bind failed to start Am 15.03.22 um 14:37 schrieb Paul Amaral via bind-users: > Neverminded, I was able to traceback my steps and realize a fat > fingered a DNS entry in one of the zones, added two periods to an > authoritative zone’s DNS record, causing bind to fail to start. The > concerning issue was there was no error on the logs at all, making it > hard to figure out the issue. that's the terrible packaging > Which leads me to the next question, let’s say I’m authoritative for > regular zone ABC.com and I fat fingered its DNS record, > ns1..something.com. Why would this affect the bind instance from > starting up? because that's what ExecStartPre is for if it fails the unit fails > Like I said there was nothing on the logs and I understand that might > be due to the Centos PKG itself. Just wondering why that mistake down > bind down and how I can get more meaningful logs on the logs even > those a prepackaged bind version. the ExecStartPre happens long before named it even tried to start, so it can't log anything - in my opinion the ExecStartPre stuff should go in it's own script and just log but not fail the unit with a non-zero exit code BTW: don't write directly in zone files and if you do so verify it at your own - good chances named would refuse to start at it's own with such errors that's why you *don't hard restart named* just because you changed a zone - a reload most likely would have logged the error and just refused to reload the zone itself you need tools for altering zones which would refuse such wrong input before they make it into the zone-file -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Chroot Bind failed to start
Am 15.03.22 um 14:37 schrieb Paul Amaral via bind-users: Neverminded, I was able to traceback my steps and realize a fat fingered a DNS entry in one of the zones, added two periods to an authoritative zone’s DNS record, causing bind to fail to start. The concerning issue was there was no error on the logs at all, making it hard to figure out the issue. that's the terrible packaging Which leads me to the next question, let’s say I’m authoritative for regular zone ABC.com and I fat fingered its DNS record, ns1..something.com. Why would this affect the bind instance from starting up? because that's what ExecStartPre is for if it fails the unit fails Like I said there was nothing on the logs and I understand that might be due to the Centos PKG itself. Just wondering why that mistake down bind down and how I can get more meaningful logs on the logs even those a prepackaged bind version. the ExecStartPre happens long before named it even tried to start, so it can't log anything - in my opinion the ExecStartPre stuff should go in it's own script and just log but not fail the unit with a non-zero exit code BTW: don't write directly in zone files and if you do so verify it at your own - good chances named would refuse to start at it's own with such errors that's why you *don't hard restart named* just because you changed a zone - a reload most likely would have logged the error and just refused to reload the zone itself you need tools for altering zones which would refuse such wrong input before they make it into the zone-file -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Chroot Bind failed to start
Neverminded, I was able to traceback my steps and realize a fat fingered a DNS entry in one of the zones, added two periods to an authoritative zone’ s DNS record, causing bind to fail to start. The concerning issue was there was no error on the logs at all, making it hard to figure out the issue. Which leads me to the next question, let’s say I’m authoritative for regular zone ABC.com and I fat fingered its DNS record, ns1..something.com. Why would this affect the bind instance from starting up? Like I said there was nothing on the logs and I understand that might be due to the Centos PKG itself. Just wondering why that mistake down bind down and how I can get more meaningful logs on the logs even those a prepackaged bind version. TIA Paul From: bind-users On Behalf Of Paul Amaral via bind-users Sent: Tuesday, March 15, 2022 9:08 AM To: 'bind-users@lists.isc.org' Subject: Chroot Bind failed to start Hi, I realize this is related to Centos, but all the sudden chroot bind failed to start up with any meaningful errors. Anyone know what might be the issue here? I have no clues on that the issue is. Paul Job for named-chroot.service failed because the control process exited with error code. See "systemctl status named-chroot.service" and "journalctl -xe" for details. [r...@ns1.frv.ma:/var/named/meganet]#systemctl status named-chroot.service -l ● named-chroot.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named-chroot.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Tue 2022-03-15 08:46:11 EDT; 6min ago Process: 3045 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -t /var/name d/chroot -z "$NAMEDCONF"; else echo "Checking of zone files is disabled"; fi (code=exited, status=1/FAILURE) Mar 15 08:46:11 ns1.frv.ma systemd[1]: named-chroot.service: control process exited, code=exited status=1 Mar 15 08:46:11 ns1.frv.ma systemd[1]: Failed to start Berkeley Internet Name Domain (DNS). Mar 15 08:46:11 ns1.frv.ma systemd[1]: Unit named-chroot.service entered failed state. Mar 15 08:46:11 ns1.frv.ma systemd[1]: named-chroot.service failed. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Chroot Bind failed to start
Am 15.03.22 um 14:08 schrieb Paul Amaral via bind-users: Hi, I realize this is related to Centos, but all the sudden chroot bind failed to start up with any meaningful errors. you need to debug this terrible "ExecStartPre" where the package maintainer was too lazy to include a script file in the package and wrapped everything in "/bin/bash -c" that's a good example how a systemd-unit should *not* look like - especially combined with env-vars and what not try to disable the check and look if at least named would work as expected - good chances only the check is borked Job for named-chroot.service failed because the control process exited with error code. See "systemctl status named-chroot.service" and "journalctl -xe" for details. [r...@ns1.frv.ma:/var/named/meganet]#systemctl status named-chroot.service -l ● named-chroot.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named-chroot.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Tue 2022-03-15 08:46:11 EDT; 6min ago Process: 3045 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -t /var/name d/chroot -z "$NAMEDCONF"; else echo "Checking of zone files is disabled"; fi (code=exited, status=1/FAILURE) Mar 15 08:46:11 ns1.frv.ma systemd[1]: named-chroot.service: control process exited, code=exited status=1 Mar 15 08:46:11 ns1.frv.ma systemd[1]: Failed to start Berkeley Internet Name Domain (DNS). Mar 15 08:46:11 ns1.frv.ma systemd[1]: Unit named-chroot.service entered failed state. Mar 15 08:46:11 ns1.frv.ma systemd[1]: named-chroot.service failed -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Chroot Bind failed to start
Hi, I realize this is related to Centos, but all the sudden chroot bind failed to start up with any meaningful errors. Anyone know what might be the issue here? I have no clues on that the issue is. Paul Job for named-chroot.service failed because the control process exited with error code. See "systemctl status named-chroot.service" and "journalctl -xe" for details. [r...@ns1.frv.ma:/var/named/meganet]#systemctl status named-chroot.service -l ● named-chroot.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named-chroot.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Tue 2022-03-15 08:46:11 EDT; 6min ago Process: 3045 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -t /var/name d/chroot -z "$NAMEDCONF"; else echo "Checking of zone files is disabled"; fi (code=exited, status=1/FAILURE) Mar 15 08:46:11 ns1.frv.ma systemd[1]: named-chroot.service: control process exited, code=exited status=1 Mar 15 08:46:11 ns1.frv.ma systemd[1]: Failed to start Berkeley Internet Name Domain (DNS). Mar 15 08:46:11 ns1.frv.ma systemd[1]: Unit named-chroot.service entered failed state. Mar 15 08:46:11 ns1.frv.ma systemd[1]: named-chroot.service failed. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
