Re: Using catz (catalog zones): BIND does not remove the catz-journal file on the slave
Opened issue: https://gitlab.isc.org/isc-projects/bind9/-/issues/2842 > On 28 Jul 2021, at 23:38, Tom wrote: > > Hi > > Using BIND-9.16.19: When removing a member zone from a catz (catalog zone), > then the journal files are not removed on the slave: > > Current situation before removing the zone "example.com" from catz: > > $ ls -lahF > -rw-r--r--. 1 named named 4.0K 28. Jul 15:21 > __catz___default_catalog.123456.local_example.com.db > -rw-r--r--. 1 named named 1.2K 28. Jul 15:26 > __catz___default_catalog.123456.local_example.com.db.jnl > > > After removing the zone on the master (catz), the slave removes the > __catz___default_...-files for the corresponding zone, but not the > journal-file: > > 28-Jul-2021 15:29:56.018 general: info: catz: updating catalog zone > 'catalog.123456.local' with serial 2021072803 > 28-Jul-2021 15:29:56.018 xfer-in: info: zone catalog.123456.local/IN: > transferred serial 2021072803: TSIG 'master-slave' > 28-Jul-2021 15:29:56.018 xfer-in: info: transfer of 'catalog.123456.local/IN' > from 172.16.1.1#53: Transfer status: success > 28-Jul-2021 15:29:56.018 xfer-in: info: transfer of 'catalog.123546.local/IN' > from 172.16.1.1#53: Transfer completed: 1 messages, 5 records, 343 bytes, > 0.001 secs (343000 bytes/sec) (serial 2021072803) > 28-Jul-2021 15:29:56.020 general: info: catz: deleting zone 'example.com' > from catalog 'catalog.123456.local' - success > 28-Jul-2021 15:29:56.021 general: warning: catz: catz_delzone_taskaction: > zone 'example.com' deleted > > $ ls -lahF > -rw-r--r--. 1 named named 1.2K 28. Jul 15:26 > __catz___default_catalog.123456.local_example.com.db.jnl > > Is this intentional or possibly a bug? > > Many thanks. > Kind regards, > Tom > ___ > Please 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please 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
response policy zones (rpz) and views - memory consumption
Hi, I’ve read many archived mails here and I haven’t found solution / answer, so let me ask you guys. I’m running Bind 9.11+ and using views for around 10 clients on single server, all clients has different settings and everything was working great, until we’ve decided to implement RPZ for them. We build single rpz zone file from opensource/paid sources and it contains more than 200k malicious/adware/phishing domains that we want our clients protect from. When we use this zone and set response policy for testing view, everything was working perfect and binds memory consumption has increased by ~100MB. However when we’ve set the same rpz zone any response policy for other views (we want all view has the same RPZ zone and policy), binds memory consumption has increased by ~100MB for each zone. This might be a problem in future when rpz zone file gets bigger. Is there any way to reuse already loaded rpz zone in memory for other views ? I know in-view is not an option for rpz, using one master / slave zones has same memory effect. Thank you for any advice. Jiri ___ Please 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: ITS THE NUMBER OF CORES/THREADS
Hi, FTR I spent some time today trying to reproduce the issue and I can’t reproduce it locally, so it must be something else than just simple number of workers. The associated issue is here: https://gitlab.isc.org/isc-projects/bind9/-/issues/2837 If anybody experiencing the issue was to go through the hassle of building a Debug version of `named` in a local Visual Studio 2017, I can pass a recipe. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org > On 23. 7. 2021, at 20:53, Ondřej Surý wrote: > > Thanks, having such a simple reproducer is helpful. > > Can you try if adding `-n 8` vs `-n 7` have the same effect? > > Ondřej > -- > Ondřej Surý — ISC (He/Him) > > My working hours and your working hours may be different. Please do not feel > obligated to reply outside your normal working hours. > >> On 23. 7. 2021, at 20:31, Peter via bind-users >> wrote: >> >> Well I reported it and we see what happens my main bind is not in a >> virtual machine I guess I cound disbale Hyper-Threading as a workaround... >> ___ >> Please 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 ___ Please 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: How do I identify if bind9 is using 4 cores?
Hi Petr,
this is a side effect of libuv threadpool which inherits the name of the
“parent” thread (but then it’s shared between all of them).
If you use gdb on the `named`, you’ll see that those extra threads are waiting
for work in the uv threadpool:
(gdb) bt
#0 futex_wait_cancelable (private=0, expected=0, futex_word=0x7feaf147d22c
) at ../sysdeps/nptl/futex-internal.h:186
#1 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x7feaf147d1c0
, cond=0x7feaf147d200 ) at pthread_cond_wait.c:508
#2 __pthread_cond_wait (cond=cond@entry=0x7feaf147d200 ,
mutex=mutex@entry=0x7feaf147d1c0 ) at pthread_cond_wait.c:638
#3 0x7feaf146ab19 in uv_cond_wait (cond=cond@entry=0x7feaf147d200 ,
mutex=mutex@entry=0x7feaf147d1c0 ) at ./src/unix/thread.c:780
#4 0x7feaf1458d4d in worker (arg=0x0) at ./src/threadpool.c:76
#5 0x7feaf1248ea7 in start_thread (arg=) at
pthread_create.c:477
#6 0x7feaf114bdef in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Perhaps somebody might want to fill issue with the libuv, so it resets the
internal thread names.
Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org
> On 5. 7. 2021, at 10:28, Petr Menšík wrote:
>
> Consult log of bind9 service. It should autodetect 4 cores without any
> options, just with plain start of the service.
>
> It should show isc-socket thread for each core:
>
> pstree -t $(pidof named)
>
> I were surprised of my output however, because I have multiple
> isc-net-000{1}. My version is bind-9.16.18-1.fc34.x86_64
>
> $ pstree -t $(pidof named)
> named─┬─2*[{isc-net-}]
> ├─5*[{isc-net-0001}]
> ├─{isc-net-0002}
> ├─{isc-net-0003}
> ├─{isc-socket-0}
> ├─{isc-socket-1}
> ├─{isc-socket-2}
> ├─{isc-socket-3}
> └─{isc-timer}
>
> Are those numbers intentional?
>
> On 6/17/21 5:32 AM, Manish Rane wrote:
>> Hi Team,
>>
>> I have BIND 9.16.17-Ubuntu on ubuntu and have 4 cores. I have configured
>>
>> more /etc/default/bind9
>> OPTIONS="-n 4"
>>
>> And then restarted the services. How do I verify if bind9 has spawned 4
>> processes and distributed among those?
>>
>> TIA
>> Manish R
>>
>>
>>
>>
>> ___
>> Please 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
> --
> Petr Menšík
> Software Engineer
> Red Hat,
> http://www.redhat.com/
>
> email:
> pemen...@redhat.com
>
> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
>
> ___
> Please 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
___
Please 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
