Stop journald from truncating your output when your service goes rogue

Technical Briefing | 10/31/2026

We have all been there. A service dumps a stack trace or a massive JSON payload to stdout, and you go to grep through the logs only to find they have been mercilessly chopped off by journald. You try to read the tail of the error, but it is just gone, replaced by a wall of frustration. It is a default protection mechanism to keep your disk from exploding, but it is rarely what you need when the system is actually on fire.

Why the log cuts off before the good stuff

Systemd imposes a LineMax limit. By default, it is 4K. If your application decides to spew a multi-line formatted error string that hits that ceiling, journald simply splits the message or drops the tail. Most people assume their app is behaving and that the logs are complete, but you are effectively flying blind once the buffer hits that arbitrary wall.

journalctl -u your-service-name --no-pager -o cat | grep -v '^--$'

• Check /etc/systemd/journald.conf and bump the LineMax setting to something sane like 64K
• Restart the journald service, but remember it will not drop existing logs, just change how it handles new ones
• Use bpftrace to hook into the read/write syscalls if you think the truncation is happening before it even hits the socket

Don’t rely on the journal alone

If you are chasing a ghost that seems to be vanishing mid-flight, eBPF is your best friend. Use a kprobe on the vfs_write syscall to verify exactly what data is leaving the process before it ever touches the systemd logging infrastructure. If the syscall write is complete but the journal is short, you know exactly where the bottleneck lives. Stop trusting the logs you see and start verifying what the kernel actually sees.