Limit mixxx.log size #13684
Limit mixxx.log size #13684
Conversation
There was a problem hiding this comment.
What is the expected behaviour with log rotation? Currently, my log files are rotated with up to 10 log archive:
-rw-rw-r-- 90K ../.mixxx/mixxx.log
-rw-rw-r-- 90K ../.mixxx/mixxx.log.1
-rw-rw-r-- 128K ../.mixxx/mixxx.log.10
-rw-rw-r-- 80K ../.mixxx/mixxx.log.2
-rw-rw-r-- 80K ../.mixxx/mixxx.log.3
-rw-rw-r-- 116K ../.mixxx/mixxx.log.4
-rw-rw-r-- 80K ../.mixxx/mixxx.log.5
-rw-rw-r-- 121K ../.mixxx/mixxx.log.6
-rw-rw-r-- 254K ../.mixxx/mixxx.log.7
-rw-rw-r-- 927K ../.mixxx/mixxx.log.8
-rw-rw-r-- 64K ../.mixxx/mixxx.log.9
Is this something that Mixxx handle cross platform? Is that some logrotate Linux specific behaviour? In case linux already ship with some logrotate setup, I would suggest we keep unlimited the default in there.
Also a suggestion, instead of preventing further append to the log file, shall we discard the N first lines, N being the minimum required line to discard to allow appending the new line. Appreciate this will have a performance impact, but this will also make the log usable.
Another suggestion, we could solve this issue by introducing a duplication limiter like for ffmpeg, where the log file will not write duplicated lines but will instead write the line once, and maintain a repeater counter on the next line.
[HidIoThread Traktor Kontrol S2 9E2E_3] Unable to read buffered HID InputReports from "Traktor Kontrol S2 9E2E_3" : "hid_read_timeout: unexpected poll error (device disconnected)"
[Previous line repeated 1547 times]
The limitation is, you may have a repeated pattern, which wouldn't be de-dupped.
|
The log rotation happens after each start up of Mixxx. It is a Mixxx home made implementation. Does that suite? |
|
I think it make sense to quickly issue that mitigation to 2.4, but I would be worried that this becomes a long term fix as well. Shall we merge that in 2.4 but not sync it with next version till we have a proper solution? |
This should help in the 2.5 and main branch in the same way. What is the main disadvantage? |
…g-max-file-size <bytes>
daschuer
force-pushed
the
log-max-file-size
branch
from
c974786 to
7bcba98
Compare
|
I have amended your suggestions. |
|
merge? |
IMO, this could lead to the log file to include data as it will stop outputting if it reaches the limit. Usually, relevant information to help fixing a bug or a crash tends to be closer to the end of the file, which means this could limit the usefulness of the log file. In the meantime, 100MB is fairly large, but I can imagine DJs using Mixxx to broadcast to radios for example may extend that limit |
|
Do you propose a different size? Different approach? |
|
@acolombier can we merge this as it is or is there something to do? |
|
I'm happy with merging this as mitigation. I thought @Swiftb0y had change requests tho? |
|
done |
|
Lets merge this! |
This sets a limit to 100 MB to lint the issue reported here:
#13660
The limit can be adjusted by the command line parameter --log-max-file-size