[CentOS] abrt-watch-log -F BUG: WARNING: at WARNING: CPU: INFO: possible recursive locking detected

Mon Feb 15 05:28:32 UTC 2016
Jakub Filak <jfilak at redhat.com>

Please, do not be scared from that ugly command line. It is a perfectly 
valid command line where
abrt-watch-log process is searching for the strange strings in 
/var/log/messages and calling
/usr/bin/abrt-dump-oops if the tool finds a string present in the list 
of searched strings.

You can get the list of searched strings by issuing the following command:
$ abrt-dump-oops -m

In the upstream, we have replaced abrt-watch-log abrt-dump-oops with a 
single tool
watching systemd-journal and the searched strings are no longer passed 
command line arguments.


PS: It's better to do something late, than to never do it at all.

On 08/24/2015 02:41 PM, Michael H wrote:
> Hi All,
> I've been tuning a server recently and just today this has started to 
> appear in my top/htop output.
> [root at db1 ~]# ps -aux | grep kernel
> root 1011 0.0 0.0 212048 4532 ? Ss 13:34 0:00 /usr/bin/abrt-watch-log 
> -F BUG: WARNING: at WARNING: CPU: INFO: possible recursive locking 
> detected ernel BUG at list_del corruption list_add corruption do_IRQ: 
> stack overflow: ear stack overflow (cur: eneral protection fault nable 
> to handle kernel ouble fault: RTNL: assertion failed eek! 
> page_mapcount(page) went negative! adness at NETDEV WATCHDOG ysctl 
> table check failed : nobody cared IRQ handler type mismatch Machine 
> Check Exception: Machine check events logged divide error: bounds: 
> coprocessor segment overrun: invalid TSS: segment not present: invalid 
> opcode: alignment check: stack segment: fpu exception: simd exception: 
> iret exception: /var/log/messages -- /usr/bin/abrt-dump-oops -xtD
> I had made a few changes to sysctl.conf which I have now reverted and 
> the error still exists.
> my sysctl.conf contained;
> vm.swappiness=0
> vm.overcommit_memory=2
> vm.overcommit_ratio=90 - this was only added this morning because of 
> an 'out of memory' error in postgresql.
> kernel.shmmax=35433480192
> kernel.shmall=2214592512
> which I have now removed.
> Can anyone shine any light on this? A little search on Google mentions 
> faulty memory, I will install memtest today and see what the output is 
> like.
> Thanks
> Michael
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos