Request for increased debug logging size limit

[Grumpy_Geoff]

Can we please have the maximum value for config.crash.sizeloglimit increased (MENU>>Setup>>System>>Log settings>>Maximum total space used (MB)) from 20?
Now that adoxa has fixed the code, LogManager is cleaning up my logs and only keeping about two days worth.
I'd like to see the increments at something like 1, 2, ..., 19, {as current} 20, 50, 100, 200, 500MB - or even user enterable (with sanity at say 10GB).

[Grumpy_Geoff]

Okay, I just saw this in UsageConfig.py -

Code: Select all

	config.crash.sizeloglimit = ConfigSelectionNumber(default=10, min=1, max=20, stepwidth=1, wraparound=True)

so perhaps it's simpler to just change the 'max' value (and I'll wrap-around from 1 ).

[adoxa]

I could change it to 0 to 100 in steps of 5 (21 values). 0 means disabled, don't limit by size. I take it the other maxima are sufficient? There's a bug with the maximum log size (it resizes, but keeps writing at the same position, so it gets extended with nulls back to the original size; a fix has been submitted). Looking at the description, there's possibly another bug in that it says it writes to a new file, but doesn't (as I say, it just reduces the existing log). Should the description be changed, or the behaviour?

[Grumpy_Geoff]

I could change it to 0 to 100 in steps of 5 (21 values). 0 means disabled, don't limit by size.

Fine by me.

I take it the other maxima are sufficient?

For me, yep.

There's a bug with the maximum log size (it resizes, but keeps writing at the same position, so it gets extended with nulls back to the original size; a fix has been submitted).

Good-o for dogs.

Looking at the description, there's possibly another bug in that it says it writes to a new file, but doesn't (as I say, it just reduces the existing log). Should the description be changed, or the behaviour?

Description is fine by me.

[prl]

When looking at increasing the max size for the log file, remember that the the maximum limit of log data will be read into memory in one block equal to the truncation size in order to do the truncation. I.e. if the maximum truncation size is 20MB, 20MB of memory will be used to do the truncation. If 100MB is the limit, 100MB will be used.

When the fix to truncate at a line boundary is added, the memory requirement is doubled (briefly, but still doubled).

At a setting of 20MB, I consider that a bit wasteful. At 100MB it gets more concerning, especially on the T2 & T3, which have only 512MB memory.

Also, the re-write is done by an ordinary timer, so if the rewrite (no matter how the memory is handled) takes a significant amount of time, then the user may get the spinner activated.

[Grumpy_Geoff]

I'm not requesting a change to the current 10MB limit for individual log sizes (config.crash.debugloglimit).
My request is for an increase to the current 20MB limit for the 'logs' directory size (config.crash.sizeloglimit) when the older debug logs are deleted.

[prl]

I'm not requesting a change to the current 10MB limit for individual log sizes (config.crash.debugloglimit).
My request is for an increase to the current 20MB limit for the 'logs' directory size (config.crash.sizeloglimit) when the older debug logs are deleted.

Ah. Sorry, I misread that. As you were

I agree with allowing more space for the total amount of log data in the logs directory.

[adoxa]

I could change it to 0 to 100 in steps of 5 (21 values). 0 means disabled, don't limit by size.

Fine by me.

Submitted.

Looking at the description, there's possibly another bug in that it says it writes to a new file, but doesn't (as I say, it just reduces the existing log). Should the description be changed, or the behaviour?

Description is fine by me.

Submitted.

[Grumpy_Geoff]

Thanks.