Re: CPU Spike caused by semanage commands

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

 



Dan,

Thanks for your response.

Why would semanage perform a recompile of the policies. Is it possible to
enforce semanage not to recompile the policies in order to prevent the
spike.

Thanks,
Anamitra

On 11/21/12 2:13 AM, "Daniel J Walsh" <dwalsh@xxxxxxxxxx> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On 11/20/2012 06:02 PM, Anamitra Dutta Majumdar (anmajumd) wrote:
>> 
>> We are in the process of upgrading our product to RHEL6 os. And during
>> setting of SELinux contexts using semanage commands we see 100 % CPU
>>usage 
>> as below
>> 
>> top - 19:22:33 up  1:00,  1 user,  load average: 1.25, 1.15, 1.58 Tasks:
>> 171 total,   2 running, 169 sleeping,   0 stopped,   0 zombie Cpu(s):
>> 24.7%us,  0.2%sy,  0.0%ni, 75.2%id,  0.0%wa,  0.0%hi,  0.0%si, 0.0%st
>>Mem:
>> 6113004k total,  5841096k used,   271908k free,    22600k buffers Swap:
>> 2047992k total,        0k used,  2047992k free,  5078044k cached
>> 
>> PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>> 
>> 
>> 4189 root      20   0  575m 410m 3296 R 100.0  6.9   0:08.17 semanage
>> 
>> 
>> 21 root      20   0     0    0    0 S  0.3  0.0   0:00.48 events/2
>> 
>> 
>> 60 root      39  19     0    0    0 S  0.3  0.0   0:00.41 khugepaged
>> 
>> 
>> 3337 root      20   0 15088 1396 1020 R  0.3  0.0   0:01.29 top
>> 
>> 
>> 11471 root      39  19     0    0    0 S  0.3  0.0   0:14.53 kipmi0
>> 
>> 
>> 1 root      20   0 19396 1532 1208 S  0.0  0.0   0:01.10 init.real
>> 
>> 
>> 2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd
>> 
>> 
>> 3 root      RT   0     0    0    0 S  0.0  0.0   0:00.03 migration/0
>> 
>> 
>> 4 root      20   0     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/0
>> 
>> 
>> 5 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0
>> 
>> 
>> 6 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/0
>> 
>> 
>> 7 root      RT   0     0    0    0 S  0.0  0.0   0:00.09 migration/1
>> 
>> 
>> 8 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/1
>> 
>> 
>> 9 root      20   0     0    0    0 S  0.0  0.0   0:00.04 ksoftirqd/1
>> 
>> 
>> 10 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/1
>> 
>> 
>> 11 root      RT   0     0    0    0 S  0.0  0.0   0:00.04 migration/2
>> 
>> 
>> 12 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/2
>> 
>> 
>> 13 root      20   0     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/2
>> 
>> 
>> 14 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/2
>> 
>> 
>> 15 root      RT   0     0    0    0 S  0.0  0.0   0:00.05 migration/3
>> 
>> 
>> 16 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/3
>> 
>> 
>> 17 root      20   0     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/3
>> 
>> 
>> 18 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/3
>> 
>> 
>> 19 root      20   0     0    0    0 S  0.0  0.0   0:00.00 events/0
>> 
>> 
>> 20 root      20   0     0    0    0 S  0.0  0.0   0:00.03 events/1
>> 
>> 
>> 22 root      20   0     0    0    0 S  0.0  0.0   0:00.89 events/3
>> 
>> 
>> 23 root      20   0     0    0    0 S  0.0  0.0   0:00.00 cpuset
>> 
>> 
>> 24 root      20   0     0    0    0 S  0.0  0.0   0:00.00 khelper
>> 
>> 
>> 25 root      20   0     0    0    0 S  0.0  0.0   0:00.00 netns
>> 
>> 
>> 26 root      20   0     0    0    0 S  0.0  0.0   0:00.00 async/mgr
>> 
>> 
>> 27 root      20   0     0    0    0 S  0.0  0.0   0:00.00 pm
>> 
>> 
>> 28 root      20   0     0    0    0 S  0.0  0.0   0:00.02 sync_supers
>> 
>> 
>> 29 root      20   0     0    0    0 S  0.0  0.0   0:00.01 bdi-default
>> 
>> 
>> 30 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kintegrityd/0
>> 
>> 
>> 31 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kintegrityd/1
>> 
>> 
>> 32 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kintegrityd/2
>> 
>> 
>> 33 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kintegrityd/3
>> 
>> 
>> You have new mail in /var/spool/mail/root [root@vos-cm144 ~]# ps -efZ |
>> grep semanage system_u:system_r:initrc_t:s0   root      4189  4188 96
>>19:22
>> ? 00:00:12 /usr/bin/python -Es /usr/sbin/semanage user -a -P user -R
>> sysadm_r system_r specialuser_u
>> 
>> Is this an expected behavior .
>> 
>> Thanks, Anamitra
>> 
>> 
>> 
>> -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx
>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>> 
>semanage is performing a recompile of policy which is causing the spike.
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.12 (GNU/Linux)
>Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
>iEYEARECAAYFAlCsqUcACgkQrlYvE4MpobN6hQCgmMOIX7t4oLddImoUwhnByIWm
>SVUAn24d4y61FnMD++L9DGnHUy0cG6pl
>=FWuT
>-----END PGP SIGNATURE-----

--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux



[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux