From: Wietse Venema on
Nataraj:
> Thank you everyone for your helpful responses. I've narrowed the problem
> down further, though it is not solved yet. It does not appear to be
> specific to postfix. I've written a simple program with a select
> statement that delays 10 seconds when run on any of my own computers,
> but when run on the virtual machine hosting my mailserver it returns
> immediately. I'm suspecting a vmware related problem, but I don't know
> yet...

Accurate time keeping is one of the dirty secrets of virtualization.

Wietse

http://www.vmware.com/pdf/vmware_timekeeping.pdf

From: Nataraj on
Wietse Venema wrote:
> Nataraj:
>
>> Thank you everyone for your helpful responses. I've narrowed the problem
>> down further, though it is not solved yet. It does not appear to be
>> specific to postfix. I've written a simple program with a select
>> statement that delays 10 seconds when run on any of my own computers,
>> but when run on the virtual machine hosting my mailserver it returns
>> immediately. I'm suspecting a vmware related problem, but I don't know
>> yet...
>>
>
> Accurate time keeping is one of the dirty secrets of virtualization.
>
> Wietse
>
> http://www.vmware.com/pdf/vmware_timekeeping.pdf
>
Thank you Wietse, I needed something to lighten my day... Perhaps I'm
having an experience of time converging to 0. Now, if I could only get
everything done in that timeframe....

Nataraj

From: Nataraj on
Nataraj wrote:
> Hi,
>
> I would appreciate any suggestions anyone can offer on the following
> problem that I'm having with postfix...
>
> I'm running postfix+pgsql-2.3.3-2.1.el5_2 on a CentOS 5.4 server. I
> see what looks likes a server in stress mode as described in
> http://www.postfix.org/STRESS_README.html except the odd think about
> it is that the server is not heavily loaded and I sure can't see where
> it's exceeding any process limits. What's even odder is it doesn't
> appear that the stress code is implemented in this version.
>
> If I telnet to port 25 I get an immediate SMTP greeting followed in 10
> seconds by
> 421 4.4.2 mymail.com Error: timeout exceeded
> and the connection being closed.
> The following maillog entry is logged:
> May 3 16:44:06 mymail postfix/smtpd[22573]: timeout after CONNECT from
> 173-12-149-200.client.myisp.com[173.12.149.200]
>
> This is like this constantly. I see 0-4 smtpd processes on the server
> at any one time (I'm not sure if it's limited at 4, I just haven't
> seen more). There are a similar number of policy daemons. There is a
> "-" in the maxproc field for smtpd in master.cf. From everything I
> can tell the default is a limit of 100. I do run a policy daemon
> (vpostmaster). I've changed its maxproc field to 0 per the
> recommendation in the STRESS_README (and restarted postfix). It's
> master.cf entry looks like this...
> vpm-pfpolicy unix - n n - 0 spawn
> user=vpostmaster argv=/usr/lib/vpostmaster/postfix/vpm-pfpolicy
>
> I also get lots of log entries like this for timeouts on the policy
> daemon:
> May 2 05:36:20 aspen postfix/spawn[6003]: warning:
> /usr/lib/vpostmaster/postfix/vpm-pfpolicy: process id 6004: command
> time limit exceeded
>
>
>
>
This problem is solved. The problem was caused when my hosted VM was
migrated from a VMware 3.5 to a VMware 4 server and the vmware config
for my VM had the OS configured to Ubuntu instead of redhat. Well in
vmware ESXI 4.0 it appears that they are more clever about how the
clocking interfaces with options that are set in the kernel (Centos 5.4
does not use a TICKLESS kernel, but current UBUNTU releases do). After
the vmware config was changed my mail server problems disappeared.

Thank you,
nataraj