Skip to main content
Unix & Linux

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

13
  • A well-reasoned argument - thank you. I feel like this is the correct answer, and the answer I expected as there's virtually nothing in the way of how-to-recipes explaining how journald might be removed or disabled. And since this is a comment, I'll express an opinion in closing: journald is to Linux what Siri is to Apple: You might not like it, but you're "forced" (more or less) to accept something you revile in order to get something you want or need. Commented Jun 5, 2022 at 20:32
  • 1
    Journald could certainly use some work on that front end part for contexts where it is the only logger (which it probably is now on most linux systems). It's only features are --unit to get service specific stuff, and of course it's colourful. BTW, I added a footnote that I realized might be important if you are putting this information into practice. Commented Jun 5, 2022 at 21:36
  • my servers struggle with postfix on Debian stable with systemd: some messages that postfix logs correctly into journald do not get forwarded to the log-server via rsyslogd. with journalctl -feu "postfix*" they can be observed on the postfix-system while on log-server, tail -f /var/log/mail.info only provides some. I seems to me that on the postfix-server either rsyslogd or journald consider the sequences of log-messages to exhaust the burst-limits. Tests with either or both imuxsock as well as imjournal have not helped. Any hints? Commented Apr 9, 2023 at 7:32
  • @luke Have you tried tinkering with the rate limit? Imuxsock has a similar feature: rsyslog.com/doc/v8-stable/configuration/modules/… Although it is noted there that "the journal tends to drop messages when it becomes busy instead of forwarding them to the system log socket". I'd presume that doesn't apply to the journal, although maybe that is optimistic. Commented Apr 10, 2023 at 15:30
  • they play very well together this way Not according to the rsyslog documentation: "Note that this module reads the journal database, what is considered a relatively performance-intense operation. As such, the performance of a configuration utilizing this module may be notably slower than when using imuxsock." and then (bolding is original to rsyslog): "Warning: Some versions of systemd journal have problems with database corruption, Commented May 26, 2023 at 16:06