[pve-devel] [PATCH corosync] corosync.service: add patch to reduce log spam in broken network setups

[Thomas Lamprecht]

Am 04.04.25 um 11:18 schrieb Friedrich Weber:
> On 04/04/2025 10:55, Thomas Lamprecht wrote:
>> Would be more fitting if we did not package corosync our self, as is
>> this integrated way would be fine to me. That sasid yours could be too.
> 
> Hmm, is this cut off?

no, just a few typos that might have added some confusion on reading
it.

Am 04.04.25 um 11:28 schrieb Maximiliano Sandoval:
> Friedrich Weber <f.weber at proxmox.com> writes:
> 
>> If I read the journald.conf docs [1] right, the default interval is 30s
>> and the burst value is 10000 multiplied by a factor depending on the
>> free disk space, I guess 4-6 on reasonable setups -- this is a lot of
>> messages, but as you mention probably fine for limiting really noisy
>> services. I was more thinking about this from a technical support
>> point-of-view, where I'd fear that having extreme corosync logspam over
>> days or weeks would cause the actually interesting stuff to be rotated
>> away more quickly than I'd like. :)
>>
>> But as we have no idea how many broken setups are out there, this is all
>> somewhat hypothetical, so I'm also fine with not applying this -- if we
>> get many user reports seeing logspam I guess we can still do this.
>>
>> [1]
>> https://www.freedesktop.org/software/systemd/man/latest/journald.conf.html#RateLimitIntervalSec=
> 
> 
> I am starting to lean towards not limiting this here. However, I have
> seen multiple instances at our support portal where logs are rotated
> rather quickly and useful messages are lost.

In dmesg (kernel ring buffer) sure, but the systemd journal should not
really be affected of such limitations, and such similar logs should
compress very well and not cause that much growth.
And FWIW rate-limiting is also a loss of logs, so it's really a trade
of.

If more than a handful of people run into this, we can also add the
rate-limit log stanza to the release notes known issue section (where
a general entry might be nice in any way) with direction for how to
create a systemd service override similar to Maximiliano's proposal
but for /etc. People can also always downgrade.

I'm just not comfortable rate-limiting such an important service with
the justifications presented so far.