On Wed, 2006-09-06 at 17:17 +0100, John Horne wrote: > > > I get the feeling that something is wrong here. I have restarted SA, and > grepped the log file. It shows: > > ======================================================================= > prefork: child states: BI > prefork: child states: BB > prefork: child states: BBB > prefork: child states: BBBB > prefork: child states: BBBBS > prefork: child states: BBBBII > prefork: child states: IBBBII > prefork: child states: IIBBIK > prefork: child states: IIIBKK > prefork: child states: IIKIKK > prefork: child states: IBKKKK > prefork: child states: IIKKKK > prefork: child states: BBKKKK > prefork: child states: BBKKKKB > [snipped]
I investigated this further last night when our server was less busy. Below is the message I sent to Justin Mason explaining what I think is happening. The problem lies with SElinux. Under FC4 I cannot see anything I can turn on/off in selinux to resolve this, so we will need to run the server with selinux disabled. I suspect selinux needs a little tweak to allow both SA and selinux to run. > Hello, > > I noticed that always the first 2 child processes started remained > working okay. I assume that these 2 were related to the --min-children > and --min-spare options. All the children options, except > --max-children, are default in our configuration. However, any > subsequent child process started falls in to the 'K' state and seems > to remain there. > > Our servers are quieter at this time of night (midnight!), so I > straced the master process after killing all the children again. The > spamd maillog shows (using tail -f maillog|grep 'spawned child'): > > ============================================================ > Sep 7 00:20:42 tracy spamd[1666]: spamd: server successfully spawned > child process, pid 16267 > Sep 7 00:20:42 tracy spamd[1666]: spamd: server successfully spawned > child process, pid 16268 > Sep 7 00:21:36 tracy spamd[1666]: spamd: server successfully spawned > child process, pid 16341 > > ============================================================ > > The attached log shows, for pid 16341, that the kill call gives an > error - Operation not permitted. This explains why the child is not > killed, but not as to why the op is not permitted. > > The server is running Fedora Core 4 Linux, and has SElinux enabled. I > temporarily disabled selinux, and that seems to have resolved the > problem. An strace at the time (not attached) shows: > > [pid 1666] kill(19990, SIGINT) = 0 > > No error message. Also the maillog shows: > > =============================================================== > Sep 7 00:46:07 tracy spamd[1666]: prefork: child states: BB > Sep 7 00:46:07 tracy spamd[1666]: prefork: child states: BBI > Sep 7 00:46:09 tracy spamd[1666]: prefork: child states: IBI > Sep 7 00:46:09 tracy spamd[1666]: prefork: child states: III > Sep 7 00:46:09 tracy spamd[1666]: prefork: child states: II > =============================================================== > > As can be seen the new children process is successfully killed off. > > So I guess now I need to see what it actually is in selinux that is > stopping the master process from killing of its child processes. That > can wait till tomorrow. John. -- --------------------------------------------------------------- John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914 E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 233839
