CentOS

today I run the 'ps -ef' command, and when scrolling down I saw the following ...

.
.
/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

All in one row!

Question - is this a known issue?

It's not an issue. Those are the error strings that abrt is looking for in logs, passed to the process as arguments. Ignore it or yum remove abrt\* fixes it permanently.

tnx. great support!

Sorry Trevor. I disagree. My issue: fairly fresh load of C7 with KDE. Gigabyte MA790 MB with 2 NICS. Proc is an AMD Phenom II 1090T hex core. For some bizarre reason Network Manager named the first one enp2s0 (higher MAC) and decided this one is the "preferred" connection. The second NIC with the lower MAC, is enp3s0.
Where I came across the error:
oot 4148 0.0 0.0 225724 4772 ? Ss Mar15 0:00 /usr/bin/abrt-watch-log -F BUG: WARNING: at WARNING: CPU: INFO: possible recursive locki
ng 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 Kernel panic - not syncing: 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

was after multiple failed attempts to start enp3s0. The system would initially build the connection and I could go out and browse a web page. After 2-4 minutes, D-BUS or something would decide it doesn't like this, cancels the DHCP request (as opposed to sending an ACK) and proceeds to tear the connection down. Any attempt to start this "non-Preferred connection" results in short up time, followed by D_BUS or something causing Network Manager to tear the connection down.

ar 17 23:26:54 localhost NetworkManager[4270]: <info> [1552883214.6304] device (enp3s0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Mar 17 23:26:54 localhost NetworkManager[4270]: <info> [1552883214.6320] dhcp4 (enp3s0): activation: beginning transaction (timeout in 45 seconds)
Mar 17 23:26:54 localhost NetworkManager[4270]: <info> [1552883214.6431] dhcp4 (enp3s0): dhclient started with pid 30967
Mar 17 23:26:54 localhost kernel: IPv6: ADDRCONF(NETDEV_UP): enp3s0: link is not ready
Mar 17 23:26:54 localhost dhclient[30967]: DHCPREQUEST on enp3s0 to 255.255.255.255 port 67 (xid=0x604176f0)
Mar 17 23:26:57 localhost kernel: r8169 0000:03:00.0 enp3s0: link up
Mar 17 23:26:57 localhost kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp3s0: link becomes ready
Mar 17 23:26:57 localhost NetworkManager[4270]: <info> [1552883217.4909] device (enp3s0): carrier: link connected
Mar 17 23:27:03 localhost dhclient[30967]: DHCPREQUEST on enp3s0 to 255.255.255.255 port 67 (xid=0x604176f0)
Mar 17 23:27:03 localhost dhclient[30967]: DHCPACK from 172.20.20.12 (xid=0x604176f0)
Mar 17 23:27:03 localhost NetworkManager[4270]: <info> [1552883223.0353] dhcp4 (enp3s0): address 172.20.20.20
Mar 17 23:27:03 localhost NetworkManager[4270]: <info> [1552883223.0354] dhcp4 (enp3s0): plen 25 (255.255.255.128)
Mar 17 23:27:03 localhost NetworkManager[4270]: <info> [1552883223.0354] dhcp4 (enp3s0): gateway 172.20.20.1
Mar 17 23:27:03 localhost NetworkManager[4270]: <info> [1552883223.0354] dhcp4 (enp3s0): lease time 43200
Mar 17 23:27:03 localhost NetworkManager[4270]: <info> [1552883223.0355] dhcp4 (enp3s0): hostname 'nottingham.friartuck.us'
Mar 17 23:27:03 localhost NetworkManager[4270]: <info> [1552883223.0355] dhcp4 (enp3s0): nameserver '8.8.8.8'
Mar 17 23:27:03 localhost NetworkManager[4270]: <info> [1552883223.0355] dhcp4 (enp3s0): nameserver '68.94.156.1'
Mar 17 23:27:03 localhost NetworkManager[4270]: <info> [1552883223.0355] dhcp4 (enp3s0): nameserver '68.94.157.1'
Mar 17 23:27:03 localhost NetworkManager[4270]: <info> [1552883223.0356] dhcp4 (enp3s0): domain name 'friartuck.us'
Mar 17 23:27:03 localhost NetworkManager[4270]: <info> [1552883223.0356] dhcp4 (enp3s0): state changed unknown -> bound
Mar 17 23:27:03 localhost NetworkManager[4270]: <info> [1552883223.0388] device (enp3s0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
Mar 17 23:27:03 localhost dhclient[30967]: bound to 172.20.20.20 -- renewal in 20649 seconds.
Mar 17 23:27:03 localhost NetworkManager[4270]: <info> [1552883223.0414] device (enp3s0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed')
Mar 17 23:27:03 localhost NetworkManager[4270]: <info> [1552883223.0423] device (enp3s0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
Mar 17 23:27:03 localhost NetworkManager[4270]: <info> [1552883223.0436] manager: NetworkManager state is now CONNECTED_LOCAL
Mar 17 23:27:03 localhost NetworkManager[4270]: <info> [1552883223.0501] manager: NetworkManager state is now CONNECTED_SITE
Mar 17 23:27:03 localhost NetworkManager[4270]: <info> [1552883223.0505] policy: set 'New Wired Connection' (enp3s0) as default for IPv4 routing and DNS
Mar 17 23:27:03 localhost NetworkManager[4270]: <info> [1552883223.0513] policy: set-hostname: set hostname to 'nottingham.friartuck.us' (from DHCPv4)
Mar 17 23:27:03 localhost NetworkManager[4270]: <info> [1552883223.0584] device (enp3s0): Activation: successful, device activated.
Mar 17 23:27:03 localhost NetworkManager[4270]: <info> [1552883223.0608] manager: NetworkManager state is now CONNECTED_GLOBAL

After the delay....

Mar 17 23:27:03 localhost dbus[4157]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service'
Mar 17 23:27:03 localhost dbus[4157]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service'
Mar 17 23:27:03 localhost systemd: Starting Network Manager Script Dispatcher Service...
Mar 17 23:27:03 localhost systemd: Starting Hostname Service...
Mar 17 23:27:03 localhost dbus[4157]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Mar 17 23:27:03 localhost systemd: Started Network Manager Script Dispatcher Service.
Mar 17 23:27:03 localhost nm-dispatcher: req:1 'up' [enp3s0]: new request (4 scripts)
Mar 17 23:27:03 localhost nm-dispatcher: req:1 'up' [enp3s0]: start running ordered scripts...
Mar 17 23:27:03 localhost nm-dispatcher: req:2 'connectivity-change': new request (4 scripts)
Mar 17 23:27:03 localhost dbus[4157]: [system] Successfully activated service 'org.freedesktop.hostname1'
Mar 17 23:27:03 localhost systemd: Started Hostname Service.
Mar 17 23:27:03 localhost systemd-hostnamed: Changed host name to 'nottingham.friartuck.us'
Mar 17 23:27:03 localhost nm-dispatcher: req:3 'hostname': new request (4 scripts)
Mar 17 23:27:03 localhost systemd: Unit iscsi.service cannot be reloaded because it is inactive.
Mar 17 23:27:03 localhost nm-dispatcher: req:2 'connectivity-change': start running ordered scripts...
Mar 17 23:27:03 localhost nm-dispatcher: req:3 'hostname': start running ordered scripts...
Mar 17 23:30:02 localhost dbus[4157]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service'
Mar 17 23:30:02 localhost systemd: Starting Network Manager Script Dispatcher Service...
Mar 17 23:30:02 localhost NetworkManager[4270]: <info> [1552883402.2105] dhcp4 (enp3s0): canceled DHCP transaction, DHCP client pid 30967
Mar 17 23:30:02 localhost NetworkManager[4270]: <info> [1552883402.2106] dhcp4 (enp3s0): state changed bound -> done
Mar 17 23:30:02 localhost NetworkManager[4270]: <info> [1552883402.2226] manager: NetworkManager state is now DISCONNECTED
Mar 17 23:30:02 localhost NetworkManager[4270]: <info> [1552883402.2268] policy: set-hostname: set hostname to 'localhost.localdomain' (no default device)
Mar 17 23:30:02 localhost dbus[4157]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service'
Mar 17 23:30:02 localhost dbus[4157]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Mar 17 23:30:02 localhost nm-dispatcher: req:1 'connectivity-change': new request (4 scripts)
Mar 17 23:30:02 localhost nm-dispatcher: req:1 'connectivity-change': start running ordered scripts...
Mar 17 23:30:02 localhost nm-dispatcher: req:2 'down' [enp3s0]: new request (4 scripts)

and the connection is gone!

If I activate the preferred connection - enp2s0, the start/stop of enp3s0 becomes recurrsive, just like the ABRT report states. All appearances are that D-BUS just doesn't like the hostname change away from hostname1, so it puts the connection back the way it wants it.

My point - the ABRT pick up of the error isn't something that should be just ignored - it's a real problem that ABRT detected.

Cheers!

Michael Lay
Austin, Texas

You can disagree as much as you like but the process that is running that contains all those strings is NOT a problem. It's the abrt process that is running to check if any of those strings ever gets emitted to the logs.

Your problem has nothing whatsoever to do with that process. The problem is that the DHCP request never gets an answer.