[SERVER-30387] maxLogSizeKB parameter should only be positive Created: 28/Jul/17  Updated: 02/Mar/20  Resolved: 28/Feb/20

Status: Closed
Project: Core Server
Component/s: Internal Code, Logging
Affects Version/s: 3.4.0
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Kevin Pulo Assignee: Henrik Edin
Resolution: Done Votes: 1
Labels: ?, neweng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
is documented by DOCS-13485 Investigate changes in SERVER-30387: ... Closed
Related
related to SERVER-17358 Add flag to customize maxLogLine when... Closed
related to SERVER-34952 Require validators for non-boolean se... Closed
is related to SERVER-30389 Simple and generic way to restrict se... Closed
Backwards Compatibility: Minor Change
Sprint: Sharding 2018-03-12, Sharding 2019-02-25, Sharding 2019-03-11, Sharding 2019-03-25, Dev Tools 2020-03-09
Participants:

 Description   

It's currently possible to set the maxLogSizeKB parameter to 0 or a negative value, neither of which make sense.

The parameter variable itself is a signed int, but gets assigned to a size_t (which is unsigned). But it's not possible to use an unsigned type (see SERVER-27520), so either the allowed values should be restricted to only > 0, or values <= 0 reinterpreted (eg. to mean "default value" of 10 KB).



 Comments   
Comment by Kevin Pulo [ 02/Mar/20 ]

Ok, thanks for confirming that. I've flagged this for docs downstream attention, since this is a documented parameter.

Comment by Kevin Pulo [ 02/Mar/20 ]

Thanks henrik.edin! I notice the validator is "gte: 0", permitting a value of 0. I skimmed the code and it looks like this value is used to inhibit truncation, is that correct?

Comment by Henrik Edin [ 28/Feb/20 ]

Fixed by SERVER-46017

Comment by Kevin Pulo [ 07/Jun/18 ]

SERVER-34345 makes this much easier to do.

Comment by Gregory McKeon (Inactive) [ 19/Jan/18 ]

kevin.pulo If you send us a code review, we'll review it.

Generated at Thu Feb 08 04:23:38 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.