Hi,

--debug-log is good as well, whatever suits you more.

On 3/2/21 6:49 PM, Simon Kelley wrote:
> 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
>>
> 

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

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Reply via email to