I have reproduced the below problem with the DomU in question having SE Linux disabled. The symptom of a process taking maximum CPU time and then killing the system if it was stopped was occurring with Apache and ejabberd processes. I rebooted the DomU about 6 times and had the problem occur each time. The evidence seems quite clear that it was not a SE Linux problem. It was suggested that the problem could be related to dodgey RAM, a memtest86+ run for 6 hours did not find any errors. While this is not conclusive evidence of a lack of a problem, it's a strong indication that when a problem is reproducable quickly and easily when running a kernel but not over the course of 6 hours of memtest86+ then it's not faulty RAM. The DomU in question is now running a CentOS (2.6.18) kernel with no problems. http://etbe.coker.com.au/2008/10/22/upgrading-a-server-to-64bit-xen/ The machine in question is not entirely a standard configuration. I am running a CentOS 5 kernel with Debian user-space as described in the above blog post. On Tuesday 28 October 2008 14:10, Russell Coker <russell@xxxxxxxxxxxx> wrote: > Below are the syslog messages from a kernel panic when running 2.6.26. To > trigger it I ran "semodule -i sendmail.pp" on a machine with the exim > policy loaded (not something that you expect people to do - but not > something you expect to cause a problem either) and load_policy went into > an infinite loop (100% CPU use - strace reported no syscalls being made). > At that > stage "kill -9" seemed like the right solution, killing load_policy gave > the following result. -- Russell Coker <russell@xxxxxxxxxxxx> http://etbe.coker.com.au/ My Blog http://etbe.coker.com.au/category/security/ My Security blog posts http://www.coker.com.au/selinux/play.html My Play Machine, root PW "SELINUX" -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
