Hi, On 01-10-17 05:25, Selva wrote: > On Sat, Sep 30, 2017 at 1:28 PM, Gert Doering <g...@greenie.muc.de > <mailto:g...@greenie.muc.de>> wrote: > > > do_ifconfig, tt->did_ifconfig_ipv6_setup=0 > > This one comes as a bit of surprise - it's logged with M_DEBUG, and I > assumed that this would be something like "verb 3 or 4, or even higher". > > Selva, Steffan, or someone else who understands our message levels - > what's M_DEBUG for, and what *should* I have used here? > > > Hmm.. The log levels code is out of this world and I've only a vague > idea.. I for sure don't know the "officially sanctioned" way of using it > and have more questions than answers. > > M_DEBUG, M_WARN, M_FATAL etc by themselves do not define any printing > level -- in other words these will print at all verb levels unless > combined with something that sets the print level. M_INFO is the only > M_x flag that is different -- it has a "verb level" of 1 or more > encoded in it. > > I suppose the original design idea was that we are only supposed to use > M_INFO or one of the LOGLEV's defined in errlevel.h -- the ones starting > with D_xxx. If so I don't see one appropriate for printing ifconfig > errors/info/debug. You ma have to create one?
My thoughts exactly. Though everyone (including James) seems to use M_WARN directly for various types of warnings. > One could generate a log level on the fly using, say, > LOGLEV(4,0,M_DEBUG) meaning print at verb 4+, don't mute, tag as debug. > But there is not a single instance of such use anywhere in the code, so > I suppose that would be considered a hack? Yeah, I'd consider that a hack. My approach would be to find a suitable D_* flag or create one of no suitable flag is available. > > > WARNING: this configuration may cache passwords in memory -- use the > > > auth-nocache option to prevent this > > > > > > == Reconnect client: > > > WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1550', > > > remote='link-mtu 1602' > > > WARNING: 'cipher' is used inconsistently, local='cipher > AES-256-GCM', > > > remote='cipher AES-256-CBC' > > > WARNING: 'auth' is used inconsistently, local='auth [null-digest]', > > > remote='auth SHA512' > [..] > > > None of these are Fatal errors .. > > Indeed, WARNINGs could also be re-evaluated. Either we document that > "verb 0" will print errors *and* warnings, or we change the printout > to not print warnings. > > > Aha. so we're not supposed to print warnings or non-fatal errors at verb > 0 -- had no idea. > > I would wager that documentation is wrong as we have loads of messages > printed with just M_WARN or M_NONFATAL. All of those will print at verb > 0. Unless are we not supposed print anything with pure M_x flags alone > -- M_INFO being the only exception? Is every M_WARN to be used as > M_WARN|M_INFO so that it will print only at verb 1+? That would be a kludge. > > Then there is a M_VERB0 = 0 which is commented as "messages displayed > even at verb0 -- (fatal errors only)" but its used just once in the code > -- that too used by itself which does nothing but just print the message > at all verb levels. And make log consumers (like the GUI) wrongly > assume that its a benign info message. > > As all M_INFO messages will print at verb 1, we do not have much room to > define verb levels for WARN, ERROR, FATAL, do we.. This is unlike any > logging system I've seen and could be totally misreading the designer's > intent. Nothing to add but that I agree. Making our logging consistent is not on the top of my list, but I would certainly support patches that do :) -Steffan ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
