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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test





[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux