2016-12-21 20:40 GMT+01:00 David Lang <[email protected]>: > On Wed, 21 Dec 2016, [email protected] wrote: > > On 12/21/2016 10:43 AM, David Lang wrote: >> >>> On Wed, 21 Dec 2016, [email protected] >>> wrote: >>> >>> you can also set the retries so that it will only attempt to deliver a >>>>> message X times before it gives up on that message. >>>>> >>>> >>>> Thanks for mentioning that. Is there a setting or command-line option >>>> that you know of to dump all stock settings and current settings to the >>>> screen/file? Something like 'postconf -d' or 'postconf' ? >>>> >>> >>> I don't think so (there may be something buried in the debug options, >>> but that would be the only place for it) >>> >>> There are a LOT of possible options, and the vast majority are not >>> touched by 99.99%+ of people. >>> >> >> Understood. Aside from explicitly setting a value, is there any other way >> to know what a value is set to? For example, the watermark values that you >> mentioned earlier. I guess the safest approach is to be explicit with all >> of the values. >> > > The documentation always lists the default value of an option.
It should also be noted that some defaults change from time to time. This happens when internal algorithms are changed, or experience tells a default should be different. That applies only to fine-tuning parameters like dequeue batch size. If they are not specified, we assume that the user want's the parameter set in the way that is best for typical applications. For example, the dequeue batch size default has been adjusted several times to cope with algorithm changes. We also increased it at least once in response to the experience gained that a larger batch size than the previous default was positive in all most all cases and did not introduce bad impact in the few remaining cases. Non-tuning parameters (e.g. default forwarding ports) will of course never change (and we really mean "never"). If we want to craft a simple rule, than it is that tuning parameters should be modified if and only if a) the user *really* understands the implications b) the use case *really* justifies this Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
