On 03/22/2017 04:00 PM, Kartik Subbarao wrote:

On 03/22/2017 03:11 PM, Howard Chu wrote:

...

...

A recent 2.4.44 package build failed on a VM due to the following timing dependency between the lockout and expiration tests in test022-ppolicy.

Clocks on VMs are notoriously unstable, which is why we have always used such large margins in these tests. Shaving things down to "1 second more than needed" will probably break in multiple build environments.

Just to make sure we're understanding each other clearly -- are you saying that you've seen VMs where "sleep 10" won't sleep for at *least* 10 actual seconds? I haven't come across this, [...]

Hmm, the more I think about this, the harder it is for me to envision the kind of failure scenario you seem to be implying. Let me spell out my thought process and you can point out where I'm going wrong:

Assumption: An "unstable" clock on a VM is one that doesn't advance at one second per second of real-world time, but at least monotonically increases over time (ignoring DST exceptions and rare things like that). If it's *not* monotonically increasing, then I don't see how all kinds of things wouldn't break on the system -- like cron running duplicate jobs, etc. OpenLDAP tests would be the least of someone's worries in that situation :-)

Given this assumption, then "sleep 10" on a VM should always sleep for at *least* 10 seconds as marked by the VM's system clock. It doesn't matter how that compares to 10 seconds in the real world, since everything running on the VM is calculated relative to the VM clock. In particular, both the slapd process and the test shell script are relying on the same VM clock. So I don't see how sleeping for "1 second more than needed" -- which in this case would be 16 seconds and 31 seconds for each section -- could cause anything to break in this particular script.

What am I missing?

Thanks,

-Kartik