http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5313
------- Additional Comments From [EMAIL PROTECTED] 2007-03-22 10:28 -------
In regards to the disk I/O, which isn't necessarily the problem ;P.....I have
truss'd the children proccesses and the only things that I can see that seem
"stupid" is the excessive stat'ing that it's doing. Each children currently
attempt to stat the files more than once. I guess, the children don't cache the
initial stat they had done. My comments within '|'.
stat("servers.discovery.lst",0x28171900) ERR#2 'No such file or
directory'
open("/servers.discovery.lst",0x0,0666) ERR#2 'No such file or
directory'
stat("servers.nomination.lst",0x28171900) ERR#2 'No such file or
directory'
open("/servers.nomination.lst",0x0,0666) ERR#2 'No such file or
directory'
stat("servers.catalogue.lst",0x28171900) ERR#2 'No such file or
directory'
open("/servers.catalogue.lst",0x0,0666) ERR#2 'No such file or
directory'
| What exactly are we stat'ing here? |
stat("",0xbfbfea90) ERR#2 'No such file or
directory'
| We just did these. Why are we stat'ing them again? |
stat("servers.catalogue.lst",0x28171900) ERR#2 'No such file or
directory'
stat("servers.catalogue.lst",0x28171900) ERR#2 'No such file or
directory'
stat("servers.discovery.lst",0x28171900) ERR#2 'No such file or
directory'
stat("servers.discovery.lst",0x28171900) ERR#2 'No such file or
directory'
stat("/sbin",0xbfbfe930) = 0 (0x0)
stat("/bin",0xbfbfe930) = 0 (0x0)
stat("/usr/sbin",0xbfbfe930) = 0 (0x0)
stat("/usr/bin",0xbfbfe930) = 0 (0x0)
| Do we really need to stat /usr/games? |
stat("/usr/games",0xbfbfe930) = 0 (0x0)
stat("/usr/local/sbin",0xbfbfe930) = 0 (0x0)
stat("/usr/local/bin",0xbfbfe930) = 0 (0x0)
stat("/root/bin",0xbfbfe930) = 0 (0x0)
Anyways, this is irrelevant, but did want the mention the children do repeat the
above mutiple times before the child process gets destroyed. Again, I really
don't want to turn this problem report into a high I/O spamassassin scenerio as
that is less critical than spamassassin just stopping completely. If the above
is useful, then great, otherwise disregard it altogether.
Thanks Justin
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
