Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#33450 - systemd-journal pegs CPU and disk freezing system

Attached to Project: Arch Linux
Opened by Eric Schulte (eschulte) - Saturday, 19 January 2013, 01:37 GMT
Last edited by Dave Reisner (falconindy) - Tuesday, 22 January 2013, 23:40 GMT
Task Type General Gripe
Category System
Status Closed
Assigned To No-one
Architecture x86_64
Severity Critical
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

Under certain situations (described below) the systemd-journal process consumes increasing amounts of CPU and disk resources until the entire computer becomes unusable. At this point sudo hangs and the computer must be hard rebooted.

Additional info:
* systemd 197
* The default configuration installed by pacman.


Steps to reproduce:
1. Find an executable which dumps core. If need be I can supply one for a 64-bit machine.
2. Run this executable a number of times.
3. Run top and watch systemd-journal load up your system repeatedly logging the core dump to disk.
4. If you're lucky at this point you can use kill to STOP the systemd-journal process (don't kill it or another one will start). If you're unlucky your system will be frozen and it is time for a hard reboot.
5. Use journalctl to view the repetitive logs created by the systemd-journal.
6. Clean out the huge journal files and reboot.

This task depends upon

Closed by  Dave Reisner (falconindy)
Tuesday, 22 January 2013, 23:40 GMT
Reason for closing:  Upstream
Additional comments about closing:  Nothing for Arch to do here. Either disable coredump collection by masking the sysctl fragment, or work out something with upstream.
Comment by Dave Reisner (falconindy) - Saturday, 19 January 2013, 01:49 GMT
No problems here. If this bothers you then disable coredump collection by masking /usr/lib/sysctl.d/coredump.conf

If you still care, gripe upstream. There's nothing Arch is going to fix here.

And for clarity, here's what I did:

$ printf 'int main(void) { int *i = 0; *i = 10; return 0; }' | gcc -x c -
$ for x in {1..100}; do ./a.out; done

journald spikes for about 2 seconds and then returns to business as usual.
Comment by Eric Schulte (eschulte) - Tuesday, 22 January 2013, 00:20 GMT
Thanks after commenting out the last line of /usr/lib/sysctl.d/coredump.conf I'm able to dump core all over the place w/o problem.
Comment by Jan (medhefgo) - Tuesday, 22 January 2013, 12:32 GMT
Honestly, this testcase doesn't really demonstrate the issue at hand. For journald coredump collection to be an issue, you'd need to be in a low(er) memory situation (maybe have like 100MB free or so), and then have a memory heavy process coredump. In my situation, a wine'd java game realiably crashes on exit. That game basically fills my whole memory available, and once journald wants to collect the dump, its memory usage skyrockets, starting CPU and swap thrashing.

Loading...