Re: bind-chroot, runs, works, dies

[Reindl Harald]

Am 30.08.2017 um 15:21 schrieb Tony Finch:

Petr Mensik  wrote:


But presence of pid files also work as notification of completed
initialization (which is done BEFORE forking and finishing ExecStart
command).


named writes its pidfile relatively early during startup. The parent
doesn't exit until the child daemon has finished starting, so that's a
better notification (though not what systemd wants...).


Service type=simple is not good replacement of forking, because it does
not let you know when service failed to start at all.


Good grief


it's not true, it just don't let you know when start is finsished but 
other than sysvcrap systemd *always* let you know when a service failed 
and it's easy to write a simple script to catch that events from syslog 
and send periodically mails if that happens


what's better than forking/simple and so on is just native systemd 
support of the service to use type=notify like it is now poissble with 
MariaDB - that's it


maybe i should add that we run Fedora in production for a decade and 
with Fedora 15 i siwtched *every* service to native systemd-units since 
the Fedora mix of old compat services and new units was a unacceptable mess


so when i talk about systemd and servers i know what i talk about since 
we run httpd/mail/dns/epp/smb/afp and what not else likely as one of the 
first companies at all with exclusive native units and nothing else for 
production servers hosting hundrets of domains


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bind-chroot, runs, works, dies

[Tony Finch]

Petr Mensik  wrote:
>
> But presence of pid files also work as notification of completed
> initialization (which is done BEFORE forking and finishing ExecStart
> command).

named writes its pidfile relatively early during startup. The parent
doesn't exit until the child daemon has finished starting, so that's a
better notification (though not what systemd wants...).

> Service type=simple is not good replacement of forking, because it does
> not let you know when service failed to start at all.

Good grief.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Trafalgar: North or northwest 4 or 5, occasionally 6 later. Moderate,
occasionally rough later in northwest. Showers. Good.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bind-chroot, runs, works, dies

[Petr Mensik]

Hi Reindl,

I have tested it and it has undesired side-effects. It would be great if pid 
files did not have to match systemd unit files. But presence of pid files also 
work as notification of completed initialization (which is done BEFORE forking 
and finishing ExecStart command).

Service type=simple is not good replacement of forking, because it does not let 
you know when service failed to start at all. If you already have something 
listening on your port and start named with
$ systemctl start named

It prints nothing, error code 0 - success. But you have to look at 
$ systemctl status named

to see there is actually failure. I would not expect that. It works better now.

Forking does allow you to first read basic configuration, initialize first. 
When that is successfully done, continue with daemonizing. Systemd will wait 
until it finds pid file created by daemonizing. Any initialization errors, even 
those that named-checkconf cannot find, are reported and you are told it did 
NOT start. Before "systemd start named" returns. I consider it important 
feature, worth still playing with pid files.

I think type=notify would be good replacement. It would requires support 
implemented in bind however, so it can tell you when it finished initialization 
and started handling requests. I think nothing such is implemented yet. At 
least I do not know about option for that.

While I agree pid files are strange relicts of old days, the way systemd 
handles them has some advantages over simple services. Unless bind supports 
sd_notify of systemd, I think default configuration has to stay playing with 
pid files. Of course if you want automatically restarted service, simple 
service may suit you. Not for default configuration however.

Regards,
Petr

--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973


- Original Message -
From: "Reindl Harald" <h.rei...@thelounge.net>
To: bind-users@lists.isc.org
Sent: Friday, August 11, 2017 4:04:12 PM
Subject: Re: bind-chroot, runs, works, dies



Am 11.08.2017 um 15:57 schrieb Petr Mensik:
> Hi Todd.
> 
> I think much better than Ask Fedora would be filling a bug in 
> bugzilla.redhat.com. I would see it straight away.
> I am Fedora bind maintainer. If there is bug preventing correct start of 
> named-chroot, I would like to fix it.
> 
> You would see SElinux errors in command "ausearch -i -ts recent -m avc -m 
> user_avc -m selinux_err" if that errors were SElinux related.
> 
> I think your config file is missing pid-file "/run/named/named.pid"; It has 
> to match pid file used by your named-chroot.service. If systemd does not find 
> the pid file of forking service, it will cancel the service.
> PIDFile in named-chroot service includes chroot path, but configuration file 
> has to point to path inside chroot only.
> It should work with default configuration even when pid-file directive is 
> commented out. There is symlink from /var/run to /run also in 
> /var/named/chroot

and why in the world does the unit contain that pid-file stuff at all?

i maintain 25 production servers running on Fedora for nearly a decade 
and removed all that pid-file-stuff excatly becuse it causes only 
troubles long before most package maintainers provided systemd-units 
while as we deloyed F15 we overrided every single service with a unit in 
/etc/systemd/system

after 6 years running systemd nobody was able to show me a single 
service which needs a pid-file these days because the whole concept is 
broken by design when we have a system manager which can track services 
and processes proper

the pid-file stuff in systemd is last ressort for heavily broken software
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bind-chroot, runs, works, dies

[Reindl Harald]

Am 11.08.2017 um 15:57 schrieb Petr Mensik:

Hi Todd.

I think much better than Ask Fedora would be filling a bug in 
bugzilla.redhat.com. I would see it straight away.
I am Fedora bind maintainer. If there is bug preventing correct start of 
named-chroot, I would like to fix it.

You would see SElinux errors in command "ausearch -i -ts recent -m avc -m user_avc 
-m selinux_err" if that errors were SElinux related.

I think your config file is missing pid-file "/run/named/named.pid"; It has to 
match pid file used by your named-chroot.service. If systemd does not find the pid file 
of forking service, it will cancel the service.
PIDFile in named-chroot service includes chroot path, but configuration file 
has to point to path inside chroot only.
It should work with default configuration even when pid-file directive is 
commented out. There is symlink from /var/run to /run also in /var/named/chroot


and why in the world does the unit contain that pid-file stuff at all?

i maintain 25 production servers running on Fedora for nearly a decade 
and removed all that pid-file-stuff excatly becuse it causes only 
troubles long before most package maintainers provided systemd-units 
while as we deloyed F15 we overrided every single service with a unit in 
/etc/systemd/system


after 6 years running systemd nobody was able to show me a single 
service which needs a pid-file these days because the whole concept is 
broken by design when we have a system manager which can track services 
and processes proper


the pid-file stuff in systemd is last ressort for heavily broken software
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bind-chroot, runs, works, dies

[Petr Mensik]

Hi Todd.

I think much better than Ask Fedora would be filling a bug in 
bugzilla.redhat.com. I would see it straight away.
I am Fedora bind maintainer. If there is bug preventing correct start of 
named-chroot, I would like to fix it.

You would see SElinux errors in command "ausearch -i -ts recent -m avc -m 
user_avc -m selinux_err" if that errors were SElinux related.

I think your config file is missing pid-file "/run/named/named.pid"; It has to 
match pid file used by your named-chroot.service. If systemd does not find the 
pid file of forking service, it will cancel the service.
PIDFile in named-chroot service includes chroot path, but configuration file 
has to point to path inside chroot only.
It should work with default configuration even when pid-file directive is 
commented out. There is symlink from /var/run to /run also in /var/named/chroot.

Can you check rights and selinux context of chroot run directories?

These are on my Fedora 26.

$ ls -ldZ /var/named/chroot/{,var/}run{,/named}
drwxr-x---. 3 root  named system_u:object_r:named_conf_t:s04096 Aug 11 
13:01 /var/named/chroot/run
drwxr-xr-x. 2 named named system_u:object_r:named_var_run_t:s0 4096 Jun 30 
18:45 /var/named/chroot/run/named
lrwxrwxrwx. 1 named named system_u:object_r:named_conf_t:s0   6 Jun 30 
18:45 /var/named/chroot/var/run -> ../run
drwxr-xr-x. 2 named named system_u:object_r:named_var_run_t:s0 4096 Jun 30 
18:45 /var/named/chroot/var/run/named

Is it possible you do not have the /var/run symlink there? It would not find 
pid file and cancel the service then.
Did you upgrade to Fedora 26 from previous version?

I would be grateful If you could fill a bug. You may not be the only one 
affected and I would like to fix it for everyone.

I would test whether Type=service proposed by Reindl can be used in new Fedora 
release. I like it.

--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973

- Original Message -
From: "toddandmargo" <toddandma...@zoho.com>
To: bind-users@lists.isc.org
Sent: Thursday, August 10, 2017 12:14:00 AM
Subject: bind-chroot, runs, works, dies


Hi All, 

Help! 

Fedora 26 x64 
Xfce 4.12 

# rpm -qa \bind\* 
bind-libs-lite-9.11.1-2.P2.fc26.x86_64 
bind99-libs-9.9.10-1.P2.fc26.x86_64 
bind-chroot-9.11.1-2.P2.fc26.x86_64 
bind-license-9.11.1-2.P2.fc26.noarch 
bind-9.11.1-2.P2.fc26.x86_64 
bind-libs-9.11.1-2.P2.fc26.x86_64 
bind99-license-9.9.10-1.P2.fc26.noarch 
bind-utils-9.11.1-2.P2.fc26.x86_64 


I have a weird one. I am trying to set up bind-chroot. When I run it, it works 

for about 30 seconds, then dies. And for the entire 30 seconds, it works 

beautifully. I can go anywhere with Firefox and look up anything with "host". 
Then it breaks my heart. 
# systemctl start named-chroot Job for named-chroot.service canceled. 


This is my error logs: 
Aug  8 15:58:49 FedoraServer named[10120]: all zones loaded Aug  8 15:58:49 
FedoraServer named[10120]: running Aug  8 15:58:49 FedoraServer named[10120]: 
zone 255.168.192.in-addr.arpa/IN: sending notifies (serial 57) Aug  8 15:58:49 
FedoraServer named[10120]: zone alpine.local/IN: sending notifies (serial 60) 
Aug  8 15:58:49 FedoraServer systemd: named-chroot.service: PID file 
/var/named/chroot/run/named/named.pid not readable (yet?) after start: No such 
file or directory  Aug  8 16:00:19 FedoraServer systemd: named-chroot.service: 
Start operation timed out. Terminating. Aug  8 16:00:19 FedoraServer 
named[10120]: shutting down Aug  8 16:00:19 FedoraServer named[10120]: stopping 
command channel on 127.0.0.1#953 Aug  8 16:00:19 FedoraServer named[10120]: 
stopping command channel on ::1#953 Aug  8 16:00:19 FedoraServer named[10120]: 
no longer listening on ::#53 Aug  8 16:00:19 FedoraServer named[10120]: no 
longer listening on 127.0.0.1#53 Aug  8 16:00:19 FedoraServer named[10120]: no 
longer listening on 50.124.80.106#53 Aug  8 16:00:19 FedoraServer named[10120]: 
exiting Aug  8 16:00:19 FedoraServer systemd: Stopped Berkeley Internet Name 
Domain (DNS). Aug  8 16:00:19 FedoraServer systemd: named-chroot.service: Unit 
entered failed state. Aug  8 16:00:19 FedoraServer systemd: 
named-chroot.service: Failed with result 'timeout'. Aug  8 16:00:19 
FedoraServer systemd: Stopping Set-up/destroy chroot environment for named 
(DNS)... Aug  8 16:00:19 FedoraServer audit: SERVICE_START pid=1 uid=0 
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 
msg='unit=named-chroot comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? 
addr=? terminal=? res=failed' Aug  8 16:00:20 FedoraServer systemd: Stopped 
Set-up/destroy chroot environment for named (DNS). Aug  8 16:00:20 FedoraServer 
audit: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 
subj=system_u:system_r:init_t:s0 msg='unit=named-chroot-setup comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res

Re: bind-chroot, runs, works, dies

[Todd Chester]

On 08/09/2017 03:28 PM, /dev/rob0 wrote:

Your issue might more effectively be dealt with in a Fedora forum, or
as a Fedora bug.


Tried that to no avail: both Ask Fedora and Fedora Forum

But Reindl knew what to do and it fix the thing.  It now
runs so smooth it is like poetry.


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bind-chroot, runs, works, dies

[Todd Chester]

On 08/09/2017 03:28 PM, /dev/rob0 wrote:

Your mail client has a problem with line wrapping, which made this
very difficult to read.


Ya, no fooling.  That would be Zoho's web mail.  I had to
post from the field.

I am back in station on Thunderbird now.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: bind-chroot, runs, works, dies

[Darcy Kevin (FCA)]

Your point is taken, I looked at a very old Redhat system, although I'll note 
that the pathnames under a chroot are not subject to the technical limitations 
you mentioned.

- Kevin


-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Reindl 
Harald
Sent: Wednesday, August 09, 2017 6:48 PM
To: bind-users@lists.isc.org
Subject: Re: bind-chroot, runs, works, dies



Am 10.08.2017 um 00:35 schrieb Darcy Kevin (FCA):
> I’m not very familiar with Fedora, but on Redhat, at least, there is 
> no /run directory

don't get me wrong but you are missing some years - /run is a important part of 
the system for a long time because it is a) tmpfs and b) available at early 
boot while /var maybe a later mounted filesystem

https://unix.stackexchange.com/questions/13972/what-is-this-new-run-filesystem

[root@hosting:~]$ stat /run
   File: '/run'
   Size: 560 Blocks: 0  IO Block: 4096   directory
Device: 11h/17d Inode: 9222Links: 22
Access: (0755/drwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
Access: 2017-07-19 10:51:46.5 +0200
Modify: 2017-08-09 03:44:16.083351213 +0200
Change: 2017-08-09 03:44:16.083351213 +0200
  Birth: -
[root@hosting:~]$ rpm -q --file /run
filesystem-3.2-21.el7.x86_64

[root@hosting:~]$ cat /etc/redhat-release CentOS Linux release 7.3.1611 (Core) 
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bind-chroot, runs, works, dies

[toddandmargo]

that did the trick.  Thank you
 On Wed, 09 Aug 2017 15:19:02 -0700 Reindl 
Haraldh.rei...@thelounge.net wrote  

 
 
[Service] 
Type=simple




___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bind-chroot, runs, works, dies

[Reindl Harald]

Am 10.08.2017 um 00:35 schrieb Darcy Kevin (FCA):
I’m not very familiar with Fedora, but on Redhat, at least, there is no 
/run directory


don't get me wrong but you are missing some years - /run is a important 
part of the system for a long time because it is a) tmpfs and b) 
available at early boot while /var maybe a later mounted filesystem


https://unix.stackexchange.com/questions/13972/what-is-this-new-run-filesystem

[root@hosting:~]$ stat /run
  File: '/run'
  Size: 560 Blocks: 0  IO Block: 4096   directory
Device: 11h/17d Inode: 9222Links: 22
Access: (0755/drwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
Access: 2017-07-19 10:51:46.5 +0200
Modify: 2017-08-09 03:44:16.083351213 +0200
Change: 2017-08-09 03:44:16.083351213 +0200
 Birth: -
[root@hosting:~]$ rpm -q --file /run
filesystem-3.2-21.el7.x86_64

[root@hosting:~]$ cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: bind-chroot, runs, works, dies

[Darcy Kevin (FCA)]

I’m not very familiar with Fedora, but on Redhat, at least, there is no /run 
directory. Which makes me think that “/var/named/chroot/run/named/named.pid” is 
a misconfiguration. That would be seen as “/run/named/named.pid” from *within* 
the chroot. Following usual conventions, I think you probably meant to specify 
“/var/run/named/named.pid” in named.conf, didn’t you? The full, pre-chroot’ed 
path would then presumably be /var/named/chroot/var/run/named/named.pid.


-Kevin


From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
toddandmargo
Sent: Wednesday, August 09, 2017 6:14 PM
To: bind-users@lists.isc.org
Subject: bind-chroot, runs, works, dies


Hi All,

Help!

Fedora 26 x64
Xfce 4.12

# rpm -qa \bind\*
bind-libs-lite-9.11.1-2.P2.fc26.x86_64
bind99-libs-9.9.10-1.P2.fc26.x86_64
bind-chroot-9.11.1-2.P2.fc26.x86_64
bind-license-9.11.1-2.P2.fc26.noarch
bind-9.11.1-2.P2.fc26.x86_64
bind-libs-9.11.1-2.P2.fc26.x86_64
bind99-license-9.9.10-1.P2.fc26.noarch
bind-utils-9.11.1-2.P2.fc26.x86_64

I have a weird one. I am trying to set up bind-chroot. When I run it, it works

for about 30 seconds, then dies. And for the entire 30 seconds, it works

beautifully. I can go anywhere with Firefox and look up anything with "host". 
Then it breaks my heart.

# systemctl start named-chroot Job for named-chroot.service canceled.

This is my error logs:

Aug  8 15:58:49 FedoraServer named[10120]: all zones loaded Aug  8 15:58:49 
FedoraServer named[10120]: running Aug  8 15:58:49 FedoraServer named[10120]: 
zone 255.168.192.in-addr.arpa/IN: sending notifies (serial 57) Aug  8 15:58:49 
FedoraServer named[10120]: zone alpine.local/IN: sending notifies (serial 60) 
Aug  8 15:58:49 FedoraServer systemd: named-chroot.service: PID file 
/var/named/chroot/run/named/named.pid not readable (yet?) after start: No such 
file or directory  Aug  8 16:00:19 FedoraServer systemd: named-chroot.service: 
Start operation timed out. Terminating. Aug  8 16:00:19 FedoraServer 
named[10120]: shutting down Aug  8 16:00:19 FedoraServer named[10120]: stopping 
command channel on 127.0.0.1#953 Aug  8 16:00:19 FedoraServer named[10120]: 
stopping command channel on ::1#953 Aug  8 16:00:19 FedoraServer named[10120]: 
no longer listening on ::#53 Aug  8 16:00:19 FedoraServer named[10120]: no 
longer listening on 127.0.0.1#53 Aug  8 16:00:19 FedoraServer named[10120]: no 
longer listening on 50.124.80.106#53 Aug  8 16:00:19 FedoraServer named[10120]: 
exiting Aug  8 16:00:19 FedoraServer systemd: Stopped Berkeley Internet Name 
Domain (DNS). Aug  8 16:00:19 FedoraServer systemd: named-chroot.service: Unit 
entered failed state. Aug  8 16:00:19 FedoraServer systemd: 
named-chroot.service: Failed with result 'timeout'. Aug  8 16:00:19 
FedoraServer systemd: Stopping Set-up/destroy chroot environment for named 
(DNS)... Aug  8 16:00:19 FedoraServer audit: SERVICE_START pid=1 uid=0 
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 
msg='unit=named-chroot comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? 
addr=? terminal=? res=failed' Aug  8 16:00:20 FedoraServer systemd: Stopped 
Set-up/destroy chroot environment for named (DNS). Aug  8 16:00:20 FedoraServer 
audit: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 
subj=system_u:system_r:init_t:s0 msg='unit=named-chroot-setup comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

I find the

PID file /var/named/chroot/run/named/named.pid not readable (yet?) after start: 
No such file or directory

error to be a bit weird as the directory does exist and the entire directory 
tree from /var/named is owned by "named". This is usually SELinux's doing. But 
SELinux does not throw an error.

My "named.conf":

// generated by named-bootconf.pl  options { # the following forwarders 
is for Open DNS forwarders { 208.67.222.222; 208.67.220.220; }; 
directory "/var/named"; # pid-file 
"/var/named/chroot/run/named/named.pid"; # pid-file 
"/var/named/chroot/run/named/nonamed.pid"; /*  * If there is a firewall 
between you and nameservers you want  * to talk to, you might need to 
uncomment the query-source  * directive below.  Previous versions of BIND 
always asked  * questions using port 53, but BIND 8.1 uses an unprivileged  
* port by default.  */ // query-source address * port 53; };  //  
// /etc/named.boot //  // This is the boot file that /etc/init.d/inetsvc uses 
to run in.named //  //  // The "directory " statement points to where the 
name server (and // its files) will be running. // example: // directory  
/var/named //  //  //  // The "cache  .  named.ca" statement appears on all 
servers and tells the // server which servers are authoritative name servers 
for the root zone. // The addresses of the "higher authorities" are 

Re: bind-chroot, runs, works, dies

[/dev/rob0]

On Wed, Aug 09, 2017 at 03:14:00PM -0700, toddandmargo wrote:
> Help!
> 
> Fedora 26 x64
> Xfce 4.12
> 
> # rpm -qa \bind\*
> bind-libs-lite-9.11.1-2.P2.fc26.x86_64
> bind99-libs-9.9.10-1.P2.fc26.x86_64
> bind-chroot-9.11.1-2.P2.fc26.x86_64
> bind-license-9.11.1-2.P2.fc26.noarch
> bind-9.11.1-2.P2.fc26.x86_64
> bind-libs-9.11.1-2.P2.fc26.x86_64
> bind99-license-9.9.10-1.P2.fc26.noarch
> bind-utils-9.11.1-2.P2.fc26.x86_64I have a weird one. I am trying 
> to set up bind-chroot. When I run it, it works for about 30 
> seconds, then dies. And for the entire 30 seconds, it works 
> beautifully. I can go anywhere with Firefox and look up anything 
> with "host". Then it breaks my heart.

Your mail client has a problem with line wrapping, which made this 
very difficult to read.

> # systemctl start named-chroot Job for named-chroot.service 
> # canceled.  This is my error logs:
>  Aug 8 15:58:49 FedoraServer named[10120]: all zones loaded Aug 8 
>  15:58:49 FedoraServer named[10120]: running Aug 8 15:58:49 

Yes, named seems to start and to be running fine.

> FedoraServer named[10120]: zone 255.168.192.in-addr.arpa/IN: 
> sending notifies (serial 57) Aug 8 15:58:49 FedoraServer 
> named[10120]: zone alpine.local/IN: sending notifies (serial 60) 
> Aug 8 15:58:49 FedoraServer systemd: named-chroot.service: PID 
> file /var/named/chroot/run/named/named.pid not readable (yet?) 
> after start: No such file or directory Aug 8 16:00:19 FedoraServer 
> systemd: named-chroot.service: Start operation timed out. 
> Terminating.

Your systemd, for some reason probably related to what it said, has 
killed named.

> Aug 8 16:00:19 FedoraServer named[10120]: shutting 
> down Aug 8 16:00:19 FedoraServer named[10120]: stopping command 
> channel on 127.0.0.1#953 Aug 8 16:00:19 FedoraServer named[10120]: 
> stopping command channel on ::1#953 Aug 8 16:00:19 FedoraServer 
> named[10120]: no longer listening on ::#53 Aug 8 16:00:19 
> FedoraServer named[10120]: no longer listening on 127.0.0.1#53 Aug 
> 8 16:00:19 FedoraServer named[10120]: no longer listening on 
> 50.124.80.106#53 Aug 8 16:00:19 FedoraServer named[10120]: exiting 

And named obediently did a clean shutdown.

Your issue might more effectively be dealt with in a Fedora forum, or 
as a Fedora bug.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bind-chroot, runs, works, dies

[Reindl Harald]

Am 10.08.2017 um 00:14 schrieb toddandmargo:
I have a weird one. I am trying to set up bind-chroot. When I run it, it 
works


for about 30 seconds, then dies. And for the entire 30 seconds, it works

beautifully. I can go anywhere with Firefox and look up anything with 
"host". Then it breaks my heart.


|# systemctl start named-chroot Job for named-chroot.service canceled. |


|PID file /var/named/chroot/run/named/named.pid not readable (yet?) after 
start: No such file or directory |


error to be a bit weird as the directory does exist and the entire 
directory tree from /var/named is owned by "named". This is usually 
SELinux's doing. But SELinux does not throw an error


while this is Fedora 25 - get rid of the crappy PID file dance for every 
systemd-unit, i ripped them out many years ago and since named is even a 
single process service "Type=simple" is enough while it even works for 
httpd-preforker


frankly i go so far and specify /dev/null for mariadb and guess what - 
all the random startup errors are gone for a long time


[root@srv-rhsoft:~]$ cat /etc/systemd/system/named.service
[Unit]
Description=DNS Server
After=network.service systemd-networkd.service network-online.target 
network-wan-bridge.service network-wlan-bridge.service openvpn.service


[Service]
Type=simple
ExecStartPre=/usr/libexec/setup-named-chroot.sh /var/named/chroot on
ExecStartPre=/usr/sbin/named-checkconf -t /var/named/chroot -z 
/etc/named.conf

ExecStart=/usr/sbin/named -4 -f -u named -t /var/named/chroot
ExecReload=/usr/bin/kill -HUP $MAINPID
ExecStop=/usr/bin/kill -TERM $MAINPID
ExecStopPost=/usr/libexec/setup-named-chroot.sh /var/named/chroot off
TimeoutSec=25
Restart=always
RestartSec=1

PrivateTmp=yes
PrivateDevices=yes
CapabilityBoundingSet=CAP_CHOWN CAP_SETGID CAP_SETUID CAP_SYS_ADMIN 
CAP_DAC_OVERRIDE CAP_KILL CAP_NET_ADMIN CAP_NET_BIND_SERVICE 
CAP_NET_BROADCAST CAP_NET_RAW CAP_IPC_LOCK CAP_SYS_CHROOT
SystemCallFilter=~acct modify_ldt add_key adjtimex clock_adjtime 
delete_module fanotify_init finit_module get_mempolicy init_module 
io_destroy io_getevents iopl ioperm io_setup io_submit io_cancel kcmp 
kexec_load keyctl lookup_dcookie migrate_pages move_pages 
open_by_handle_at perf_event_open process_vm_readv process_vm_writev 
ptrace remap_file_pages request_key set_mempolicy swapoff swapon uselib 
vmsplice


ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr
ReadOnlyDirectories=/var/lib

InaccessibleDirectories=-/root
InaccessibleDirectories=-/media
InaccessibleDirectories=-/boot
InaccessibleDirectories=-/home
InaccessibleDirectories=-/run/console
InaccessibleDirectories=-/run/dbus
InaccessibleDirectories=-/run/lock
InaccessibleDirectories=-/run/mount
InaccessibleDirectories=-/run/systemd/generator
InaccessibleDirectories=-/run/systemd/system
InaccessibleDirectories=-/run/systemd/users
InaccessibleDirectories=-/run/udev
InaccessibleDirectories=-/run/user
InaccessibleDirectories=-/var/lib/dbus
InaccessibleDirectories=-/var/lib/rpm
InaccessibleDirectories=-/var/lib/systemd
InaccessibleDirectories=-/var/spool

[Install]
WantedBy=multi-user.target
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

bind-chroot, runs, works, dies

[toddandmargo]

Hi All,

Help!

Fedora 26 x64
Xfce 4.12

# rpm -qa \bind\*
bind-libs-lite-9.11.1-2.P2.fc26.x86_64
bind99-libs-9.9.10-1.P2.fc26.x86_64
bind-chroot-9.11.1-2.P2.fc26.x86_64
bind-license-9.11.1-2.P2.fc26.noarch
bind-9.11.1-2.P2.fc26.x86_64
bind-libs-9.11.1-2.P2.fc26.x86_64
bind99-license-9.9.10-1.P2.fc26.noarch
bind-utils-9.11.1-2.P2.fc26.x86_64I have a weird one. I am trying to set up 
bind-chroot. When I run it, it works
for about 30 seconds, then dies. And for the entire 30 seconds, it works
beautifully. I can go anywhere with Firefox and look up anything with "host". 
Then it breaks my heart.
 # systemctl start named-chroot Job for named-chroot.service canceled.  This is 
my error logs:
 Aug 8 15:58:49 FedoraServer named[10120]: all zones loaded Aug 8 15:58:49 
FedoraServer named[10120]: running Aug 8 15:58:49 FedoraServer named[10120]: 
zone 255.168.192.in-addr.arpa/IN: sending notifies (serial 57) Aug 8 15:58:49 
FedoraServer named[10120]: zone alpine.local/IN: sending notifies (serial 60) 
Aug 8 15:58:49 FedoraServer systemd: named-chroot.service: PID file 
/var/named/chroot/run/named/named.pid not readable (yet?) after start: No such 
file or directory Aug 8 16:00:19 FedoraServer systemd: named-chroot.service: 
Start operation timed out. Terminating. Aug 8 16:00:19 FedoraServer 
named[10120]: shutting down Aug 8 16:00:19 FedoraServer named[10120]: stopping 
command channel on 127.0.0.1#953 Aug 8 16:00:19 FedoraServer named[10120]: 
stopping command channel on ::1#953 Aug 8 16:00:19 FedoraServer named[10120]: 
no longer listening on ::#53 Aug 8 16:00:19 FedoraServer named[10120]: no 
longer listening on 127.0.0.1#53 Aug 8 16:00:19 FedoraServer named[10120]: no 
longer listening on 50.124.80.106#53 Aug 8 16:00:19 FedoraServer named[10120]: 
exiting Aug 8 16:00:19 FedoraServer systemd: Stopped Berkeley Internet Name 
Domain (DNS). Aug 8 16:00:19 FedoraServer systemd: named-chroot.service: Unit 
entered failed state. Aug 8 16:00:19 FedoraServer systemd: 
named-chroot.service: Failed with result 'timeout'. Aug 8 16:00:19 FedoraServer 
systemd: Stopping Set-up/destroy chroot environment for named (DNS)... Aug 8 
16:00:19 FedoraServer audit: SERVICE_START pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=named-chroot 
comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? 
res=failed' Aug 8 16:00:20 FedoraServer systemd: Stopped Set-up/destroy chroot 
environment for named (DNS). Aug 8 16:00:20 FedoraServer audit: SERVICE_STOP 
pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 
msg='unit=named-chroot-setup comm="systemd" exe="/usr/lib/systemd/systemd" 
hostname=? addr=? terminal=? res=success'  I find the
 PID file /var/named/chroot/run/named/named.pid not readable (yet?) after 
start: No such file or directory  error to be a bit weird as the directory does 
exist and the entire directory tree from /var/named is owned by "named". This 
is usually SELinux's doing. But SELinux does not throw an error.
 My "named.conf":
 // generated by named-bootconf.pl options { # the following forwarders is for 
Open DNS forwarders { 208.67.222.222; 208.67.220.220; }; directory 
"/var/named"; # pid-file "/var/named/chroot/run/named/named.pid"; # pid-file 
"/var/named/chroot/run/named/nonamed.pid"; /* * If there is a firewall between 
you and nameservers you want * to talk to, you might need to uncomment the 
query-source * directive below. Previous versions of BIND always asked * 
questions using port 53, but BIND 8.1 uses an unprivileged * port by default. 
*/ // query-source address * port 53; }; // // /etc/named.boot // // This is 
the boot file that /etc/init.d/inetsvc uses to run in.named // // // The 
"directory path" statement points to where the name server (and // its 
files) will be running. // example: // directory /var/named // // // // The 
"cache . named.ca" statement appears on all servers and tells the // server 
which servers are authoritative name servers for the root zone. // The 
addresses of the "higher authorities" are listed in the named.ca file. // zone 
"." { type hint; file "named.ca"; }; // // // forwarders 206.40.79.2 // 
forward-only // // key DHCP_UPDATER { algorithm hmac-md5; secret 
dgGQZwgQ==; }; zone "alpine.local" { type master; file 
"slaves/alpine.hosts"; allow-update { key DHCP_UPDATER; }; # allow-update { 
127.0.0.1; }; }; zone "255.168.192.in-addr.arpa" { type master; file 
"slaves/alpine.hosts.rev"; allow-update { key DHCP_UPDATER; }; # allow-update { 
127.0.0.1; }; }; zone "0.0.127.in-addr.arpa" { type master; file "named.local"; 
}; logging { channel update_debug { file "slaves/named-update-debug.log"; 
severity debug 3; print-category yes; print-severity yes; print-time yes; }; 
channel security_info { file "slaves/named-auth.info"; severity info; 
print-category yes; print-severity yes; print-time yes; }; category update { 
update_debug; }; category security { security_info; }; };