Re: abrt-watch-log -F BUG: WARNING: at WARNING: CPU: INFO: possible recursive locking detected

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



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 through
command line arguments.


Regards,
Jakub

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@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@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos

_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos



[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux