Bug 154802
| Summary: | sendmail timeouts with msgs larger than 100kb+ | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | murray lotnicz <decals74> |
| Component: | sendmail | Assignee: | Thomas Woerner <twoerner> |
| Status: | CLOSED CANTFIX | QA Contact: | David Lawrence <dkl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.0 | CC: | tgl |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-08-21 17:07:04 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
murray lotnicz
2005-04-14 10:28:53 UTC
oops, it's reproducible via: mail -s test me < vacuum.log What are you trying to achieve with your changes? Hi Thomas, i don't understand what you mean by "changes." the sendmail config is untouched, the cf files are unaltered since the installation. do you mean why don't i use 8.11 instead? sorry, i think my description was misleading. the compiled installation of 8.13 is still running on 1 of the servers but there are 8 other rhel_ws3 servers that are exhibiting this same problem, all with sendmail-8.12.11-4.RHEL3.1 and no installations of 8.13. are these the changes that you're referring to? Ok, was there a version which was not affected? yes, 8.11 had no probs sending larger msgs but my company prefers to use recent rpms to keep on top of security vulnerabilities/misc bugfixes. i'm quite surprised that nobody else is reporting similar problems so i wonder if it's a unique combination of things that these servers are doing. they are dual-cpu postgresql machines, typically with a load somewhere between 1-3. they're booting to 2.4.21-27.0.2.ELhugemem kernels and have 16gb ram. there aren't any other significant daemons running on these machines, just ntpd, sshd, kjournald, syslogd... we've discussed rolling back to 8.11 but are reluctant because there is no 8.11 RPM for rhel3 [was there one for rhel3_u1?] and also due to the following: http://www.securityfocus.com/bid/8641 http://www.securityfocus.com/bid/8649 Hi Thomas, i'm assuming that your answer is to revert to sendmail 8.11 since you stopped responding. Thanks for your time, I'll ask sendmail for help. I tried to reproduce your problem, but failed. Are you sure that you have no network problems or problems with ipv6? Please use tcpdump and look at the differences between the 8.11 and 8.12 version. after some more testing it looks like postgres, PGSTAT in particular, is causing some havoc on the loopback interface. PGSTAT creates UDP links from localhost to localhost to pass statistical data. stopping postgres and bouncing sendmail has flushed the clientmqueue on 2 machines. our redhat 7.3 machines that run postgres and sendmail don't exhibit this behavior tho. lemme know if there's any other helpful info i can submit. tcpdump with postgresql running: [root@testmachine root]# tcpdump -i lo tcpdump: listening on lo 17:16:40.783274 localhost.localdomain.32772 > localhost.localdomain.32772: udp 46 (DF) 17:16:40.784061 localhost.localdomain.32772 > localhost.localdomain.32772: udp 262 (DF) 17:16:40.794076 localhost.localdomain.32772 > localhost.localdomain.32772: udp 46 (DF) 17:16:40.794586 localhost.localdomain.32772 > localhost.localdomain.32772: udp 157 (DF) 17:16:40.795419 localhost.localdomain.32772 > localhost.localdomain.32772: udp 46 (DF) 17:16:40.795865 localhost.localdomain.32772 > localhost.localdomain.32772: udp 56 (DF) 17:16:40.796064 localhost.localdomain.32772 > localhost.localdomain.32772: udp 46 (DF) 17:16:40.796519 localhost.localdomain.32772 > localhost.localdomain.32772: udp 131 (DF) I think this bug has to get assigned agains postgresql, it seems to be a logging problem. Um ... I see no evidence here that connects postgres to the mail problem. I'm not saying that there couldn't be a connection, just that being on the same machine at the same time isn't enough connection to justify passing the bug my way ... i switched to postfix over a year ago which got rid of this problem. feel free to close this bug. I'm switching this back to the sendmail component, since I see no evidence that postgres did anything wrong, and closing as CANTFIX because we are unable to reproduce the problem. |