is there a better solution than "killall -9 journalctl"?
adamwill at fedoraproject.org
Tue Jul 15 02:09:19 UTC 2014
On Mon, 2014-07-14 at 18:54 -0700, Adam Williamson wrote:
> I might go poking through the abrt code in a minute to see why it's
> calling journalctl. It does seem a somewhat inefficient approach.
So what it's doing here is trying to store 'relevant log lines' for the
uid=`cat uid` &&
log="[System Logs]:\n" &&
log=$log`journalctl -b --system | grep -F -e "$base_executable" | tail -99` &&
log=$log"\n[User Logs]:\n" &&
log=$log`journalctl _UID="$uid" -b | grep -F -e "$base_executable" | tail -99` &&
log=`echo -e "$log"`
that's from abrt src/plugins/ccpp_event.conf . The '-b' there limits it
to reading the logs from the current boot only, which *should* make it
reasonably fast and not particularly resource-sucking; the other thing
I'd find interesting is whether Robert's system has something producing
an excessive amount of log spam, so even the logs just from a 10 minute
old boot are very long. Robert, is that the case? If you just run 'sudo
journalctl -b' and see how many lines you get, how many is it? My
system's been up all day, for instance, and that command gives me 4709
lines of logs, and only takes a second or two to page from start to end.
If you have tens or hundreds of thousands of lines of output for a
single boot, that could be contributing to the problem.
Still, abrt is obviously being inefficient here. grepping journalctl
access is I think inherently inefficient and not what apps that want to
programatically access the journal should be doing, but it could at
least use journalctl _PID="$pid" (reading the pid in from the abrt
problem directory the same way it currently reads the executable name,
obviously) instead of reading the entire journal and grepping for the
I'll file a report against abrt for this (if there isn't one already).
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
More information about the test