[Dnsmasq-discuss] [PATCH] --bind-dynamic and fast netlink changes

[Simon Kelley]

On 01/03/2021 10:56, Petr Menšík wrote:
> On 3/1/21 1:02 AM, Simon Kelley wrote:
>> That looks sensible except for one thing. I wasn't sure about the
>> logging in the first place, and having to add Yet Another Config Option
>> to control it is the last straw; I think it's better just removed.
> Is there any good way to monitor them without logging possible? I
> considered also enabling the log just in debug mode (-d). It seems
> better if it can be configured separately. Still, I find those logs very
> important to observe listener changes. It was hard to watch more than
> single change using debugger.
> 
> I also considered using log-queries option, because it logs quite often
> anyway. But I think it would be better to have separate option.

For debugging, logging is useful for fixing these problmes, but once
this is working, is this logging providing anything useful for someone
who is setting up and configuring a dnsmasq installation?  I think that
was my hesitation to this originally. I'd expect bind-dynamic to just
work, in the same was that the other two bind- modes do, and not to need
to fill the logs with details of its internal behaviour.

Debug mode is not a good choice, since you may well want to control
logging independently of making forking and suchlike work in a way which
makes running under gdb.

Maybe to should have a new option to control debug-level logging.
Without that set my_syslog could just discard any calls with LOG_LEVEL
set to DEBUG (which is just the ones we're talking about, as far as I
can see, but could be extended later, once the facility exists.) I'm
sure the various varieties of syslog daemons can be configured to dom
something similar, but there's still the overhead of talking to them.



> 
> Logging those events seems right to me. But they should not be logged
> during netlink reading, but after it. It seems quite complicated to
> gather changed listeners after iface_enumerate is finished however. They
> are usually just one or two lines, just during my artificial test, it
> was worth noting. I should mention, the first commit itself fixed it
> well on 2.79 in RHEL8. Listeners logging still in place and slowing down
> the test. Yet it always passed.
> 
> I removed them just as precaution to improve performance. As a last
> resort, could they remain there under compile time define?
> 

Yes, but I like my --debug-log option better. What do you think?


Simon.

>>
>>
>> Will apply the others and test tomorrow.
> Great, if you need help with testing, just let me know.

Sorry, yesterday didn't go to plan. Applying patches now.


Simon.

> 
> Cheers,
> Petr
>