On Sun, Dec 15, 2024 at 11:34:54AM +0100, Tomasz Pala via Postfix-users wrote:
> System-wide "defaults to 10000 messages in 30s" and "is applied per- > service", so this can be easily resolved by providing postfix.service > with: > > LogRateLimitIntervalSec=0 Nice in theory, but neither Wietse nor I distribute systemd service definition files, and the ones in wide use don't do that. > > > stream rather than datagram based (separate stream per-process), and so > > gets the logs out of order when logs are sent in close succession by > > multiple processes. > > Proper ordering is supposed to be one of the journald promises - are you > talking about stdout/stderr capture (I guess no), or /dev/log handling? It fails when there are multiple coöperating processes doing the logging. Precisely because a stream socket is chosen. > If /dev/log - what's the fault of journald here? Choosing SOCK_STREAM > over SOCK_DGRAM? Yes. > I don't think that proper ordering depending on that is > it's fault - a quick glance show that various syslogds have been > switching between them: I'm used to seeing dgram. Stream is also unwise, because a sender can block, if the logging service is slow, which I've run into because on a 64-core server (and a much chattier log client than Postfix, say a KDC), with just one poor systemd-journald, it can fall behind. > and actually the oldest system I got (which is really ancient postfix > 2.3.12) also uses unix-stream() in syslog-ng 2.x. You might want to reconsider that choice. > OTOH unix-dgram() reliability was discussed just 3 months ago: > https://github.com/syslog-ng/syslog-ng/issues/3828 > https://github.com/syslog-ng/syslog-ng.github.io/issues/130 Reliability means: - Being performant - Not *deliberately* dropping messages - Not having clients block if you're not keeping up, then, yes perhaps losing some messages, that's OK. - Preserving time order of messages (in order written to the shared dgram socket). > I have no idea what systems and versions have reliable SOCK_DGRAMs, Not looking for *lossless*, rather operationally reliable. -- Viktor. _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
