Hello, [email protected], le jeu. 25 sept. 2025 13:11:07 +0200, a ecrit: > Hi SamuelI found something in kmsg_putchar. > > if kmsg_write_offset +1 == kmsg_read_offset (mod KMSGBUFFSIZE) > it just discards the character which leads to the previous message being > malformed.
Which is kind of expected: we are overflowing. > Should it in that case also terminate the current message by setting the > previously written char (at kmsg_write_offset -1 mod KMSGBUFFERSIZE) to \n ? I'd rather not alter the content. > I tried this patch and it fixes the problem. Some messages are being lost but > I don't know what else to do with them. (i am reusing the offset variable > that is not needed anymore) > I guess I encounter this because at boot time a lot of messages are being > written to the buffer in a short time before the syslogd can start emptying > them so increasing the buffer prevents the early wraparound. Yes, there is no way around that issue except increasing the buffer size if our boot log is indeed quite verbose (we can indeed do that). Perhaps we'd rather instead drop some messages which are not really that useful. That being said, dropping the latest characters being put might not be the best, I'd rather say drop the oldest characters so that you are sure you have the latest information. And then you'll have '\n'. Samuel
