On Sat, 18 May 2019 19:50:27 +0300, Amer Hwitat said:
I have no idea why you sent this to the linux-audit list, as it doesn't seem to
involve the kernel audit subsystem in any way.
I have the following Bugs that crashed my VM, I reported it to RH,
they
didn't answer, and banned my developer account, the Bug is when you disable
the network on RHEL with OSP 14 installed all in one, it crashes the
system, I had a 12GB RAM, with 8 CPUs on the VM, and I found out that this
crash report pissed off someone in RH, because they called me, and said
what do you want from me!!, what I need is a Simple reply, is this a bug or
not.
It's probably a bug. Given that you mention 'RabbitMQ heartbeats'
and the problem happens when you yank the network out from under
RabbitMQ, it's probably a RabbitMQ bug failing to deal gracefully with
the removal of a network device from the configuration.
And no, you probably won't be able to get help from RedHat. Having said that,
it's unclear why your developer account got closed, unless there's more to the
story than you're telling. Were you insisting that RedHat fix a bug in (probably)
RabbitMQ, which isn't a RedHat product?
Note in your screenshot:
"A kernel problem occurred, but your kernel has been tainetd (flags:GL)
Explanation: Kernel maintainers are unable to diagnose tained reports"
The L flag is saying that there was a kernel lockup detected before the panic
happened, which means that when the NMI caused the panic the kernel was already
screwed up. There's a good chance that kcrash was unable to capture useful
data. You need to be lookng at the cause of the softlockup, not the panic.
More troublesome is the G flag, which indicates that proprietary modules have
been loaded. Since source is unavailable, there's no way to debug it without
the assistance of whoever produced the proprietary module.
If you don't already know what module did it, 'dmesg | grep taint' should
reveal the culprit.
Take it up with whoever produced the module Good luck.