is there a better solution than "killall -9 journalctl"?

[Robert P. J. Day]

On Mon, 14 Jul 2014, Adam Williamson wrote:

> On Mon, 2014-07-14 at 19:09 -0700, Adam Williamson wrote:
> > 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
> > crash:
> >
> >                 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
> > executable name.
> >
> > I'll file a report against abrt for this (if there isn't one already).
>
> It looks like Amit Shah filed what seems to be the same problem last
> week:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1043670
>
> I attached an analysis and proposed patch to that.

  thanks, i appreciate all the assistance. weirdly, the problem of
multiple journalctl processes seems to have gone away in the last
couple days, i'm not sure why. they might still be hideously
inefficient, but if they're not running, then i'm happy. :-)

  i have no idea what recent "yum update" might have changed things.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================