For a while I had semanage coredumping about one in 20 runs. Now the problem
seems to have gone away. I got this coredumpctl as the only evidence of it
happening. I'll send in a policy patch for systemd-coredump soon.
Storage: /var/lib/systemd/coredump/core.semodule.
0.8727799a8e0b44f1885f1>
Message: Process 2096 (semodule) of user 0 dumped core.
Stack trace of thread 2096:
#0 0x00007faab782c9d3 n/a (libc.so.6 + 0x9c9d3)
#1 0x00007faab7a0cce1 n/a (libsepol.so.1 + 0x77ce1)
#2 0x00007faab7a0cff9 n/a (libsepol.so.1 + 0x77ff9)
#3 0x00007faab7a0d063 n/a (libsepol.so.1 + 0x78063)
#4 0x00007faab7a0d18e n/a (libsepol.so.1 + 0x7818e)
#5 0x00007faab7a0d42f n/a (libsepol.so.1 + 0x7842f)
#6 0x00007faab7a11808 n/a (libsepol.so.1 + 0x7c808)
#7 0x00007faab7a12dec n/a (libsepol.so.1 + 0x7ddec)
#8 0x00007faab7a12d51 n/a (libsepol.so.1 + 0x7dd51)
#9 0x00007faab7a12e39 n/a (libsepol.so.1 + 0x7de39)
#10 0x00007faab7a12d51 n/a (libsepol.so.1 + 0x7dd51)
#11 0x00007faab7a0e98d n/a (libsepol.so.1 + 0x7998d)
#12 0x00007faab79e3424 cil_compile (libsepol.so.1 + 0x4e424)
#13 0x00007faab79699b9 n/a (libsemanage.so.1 + 0x169b9)
#14 0x00007faab796ee2e semanage_commit (libsemanage.so.1 +
0x1b>
#15 0x00005642ec66e1f4 n/a (semodule + 0x31f4)
#16 0x00007faab77b6e0b __libc_start_main (libc.so.6 + 0x26e0b)
#17 0x00005642ec66e71a n/a (semodule + 0x371a)
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
On 4/8/20 7:05 AM, Russell Coker wrote:
> For a while I had semanage coredumping about one in 20 runs. Now the problem
> seems to have gone away. I got this coredumpctl as the only evidence of it
> happening. I'll send in a policy patch for systemd-coredump soon.
>
> Storage: /var/lib/systemd/coredump/core.semodule.
> 0.8727799a8e0b44f1885f1>
> Message: Process 2096 (semodule) of user 0 dumped core.
>
> Stack trace of thread 2096:
> #0 0x00007faab782c9d3 n/a (libc.so.6 + 0x9c9d3)
> #1 0x00007faab7a0cce1 n/a (libsepol.so.1 + 0x77ce1)
> #2 0x00007faab7a0cff9 n/a (libsepol.so.1 + 0x77ff9)
> #3 0x00007faab7a0d063 n/a (libsepol.so.1 + 0x78063)
> #4 0x00007faab7a0d18e n/a (libsepol.so.1 + 0x7818e)
> #5 0x00007faab7a0d42f n/a (libsepol.so.1 + 0x7842f)
> #6 0x00007faab7a11808 n/a (libsepol.so.1 + 0x7c808)
> #7 0x00007faab7a12dec n/a (libsepol.so.1 + 0x7ddec)
> #8 0x00007faab7a12d51 n/a (libsepol.so.1 + 0x7dd51)
> #9 0x00007faab7a12e39 n/a (libsepol.so.1 + 0x7de39)
> #10 0x00007faab7a12d51 n/a (libsepol.so.1 + 0x7dd51)
> #11 0x00007faab7a0e98d n/a (libsepol.so.1 + 0x7998d)
> #12 0x00007faab79e3424 cil_compile (libsepol.so.1 + 0x4e424)
> #13 0x00007faab79699b9 n/a (libsemanage.so.1 + 0x169b9)
> #14 0x00007faab796ee2e semanage_commit (libsemanage.so.1 +
> 0x1b>
> #15 0x00005642ec66e1f4 n/a (semodule + 0x31f4)
> #16 0x00007faab77b6e0b __libc_start_main (libc.so.6 + 0x26e0b)
> #17 0x00005642ec66e71a n/a (semodule + 0x371a)
I haven't seen this. The main SELinux mail list would be a better choice than
refpolicy.
--
Chris PeBenito