Dennis HilkLinux Fix LabDE

Services & systemd

Journald suppresses a burst of service messages

A noisy service has log gaps with suppression notices. Distinguish journal rate limits from application-side logging and storage retention settings.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • Journald names a service whose messages were suppressed.
  • The service remains active but parts of its output are absent.

Relevant environment

systemd-journald and service LogRateLimitIntervalSec/LogRateLimitBurst overrides.

Recognizable messages (synthetic examples)
systemd-journald[412]: Suppressed 1200 messages from example.service

Missing log messages are weak evidence during the dropped burst.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • Rapid repeated messages may exceed journal or per-service burst limits.
  • An application can also limit its own messages; journald reports only drops after reception.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Reads journald notices; system journal access may require authorized administrative read access.

journalctl -b -u systemd-journald.service --no-pager -n 100

Interpret the result: A notice names the source and count but cannot reconstruct the missing message text.

Check 2

Replace example.service; shows logging targets and unit overrides without restart.

systemctl show example.service -p LogRateLimitIntervalUSec -p LogRateLimitBurst -p StandardOutput -p StandardError

Interpret the result: Unit rate-limit settings can supersede global values. File-only output needs the application's own logging inspection.

Evidence-guided next steps

Fix the repeated message source

If one reconnect or configuration failure floods output, repair that condition or reduce documented application verbosity. Save a representative sample before lowering the log level.

Precautions: Reducing verbosity can hide other evidence. Do not suppress all errors solely to remove the notice.

Recovery / rollback: Restore the prior application log level. Already dropped journal messages cannot be recovered.

Did this solution help you?

Share this solution#

Adjust this service's log budget temporarily

If a necessary diagnostic burst must be retained, temporarily increase this unit's documented log budget and monitor journal capacity. Restore normal limits after evidence collection.

Precautions: Extra output consumes I/O and storage. Check local directive support and avoid disabling global limits for unrelated services.

Recovery / rollback: Restore recorded unit values, reload the manager and apply a restart only if the unit change requires it and interruption is acceptable.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.