[Users] Re: Bug#636463: vzctl: /etc/vz/dists/scripts/postcreate.sh randomises run-times in /etc/crontab, but not cron.d

Tim Small tim at seoss.co.uk
Tue Aug 9 05:27:15 EDT 2011

cc'ing openvz users mailing list, as this has been discussed there recently.

On 04/08/11 06:36, Ola Lundqvist wrote:

> This is certainly an interesting problem. The patch is a good start but
> as we can foresee problems already now we need to find out a solution
> to that before it is applied.

I agree.

> There is also one other problem. It is just a very limited number of
> files that are actually installed during the initial install when
> postcreate.sh is executing. Actually on my computer it was only anacron
> that hold a file in that directory (that I have not created myself or installed
> post initial install).

This I suppose depends on the particular site's style of working - if
you have "fat" VZ templates it's likely to be OK?  Or maybe I've
misunderstood when this script gets called.

> All other applications will have the same problem as before.
> I can see two solutions:
> 1) postcreate.sh go through only the files that are actually created
>  on initial install and touch them in a similar way as your patch.
> 2) A new tool is introduced that should be run by the system administrator.
> Do you have any opinion about this?

Difficult to see the best answer here, and indeed it's a problem which
is not OpenVZ-specific of course - it's equally valid across any
virtualised instance of Debian - which is becoming more and more the
normal way to deploy servers.

For that matter, you can definitely see when cron.daily fires off by
default at 6.25 every morning on this traffic graph for
ftp.uk.debian.org - http://www.hands.com/mrtg/free.eth0.html - and I've
experienced problems with jobs like backups running all-at-the-same-time
via default crontab setups on networks of non-virtualised servers.

As virtualised instances of Debian become more and more common, maybe
it's something that needs to be solved for the general case at package
install time?  Crontabs installed by packages could have meta-info
included to indicate whether the crontab entries should be perturbed,
and if-so, by how much?

This is obviously not a small change, but having thought about it for a
while, other possible approaches probably have the possibility of
breaking the packages which they alter, and not fixing things in the
general case?

I suppose it's something that could be prototyped in OpenVZ (e.g. by
shipping the meta-data separately from the packages initially, and only
perturbing crontabs which are "opt-in") - in our experience it was only
a small subset of crontabs which caused the problem (mysql and logcheck
were the biggest ones, if I remember correctly).


p.s. a quick bit of research seems to show up the problem coming up
again and again...




etc. etc.

South East Open Source Solutions Limited
Registered in England and Wales with company number 06134732.  
Registered Office: 2 Powell Gardens, Redhill, Surrey, RH1 1TQ
VAT number: 900 6633 53  http://seoss.co.uk/ +44-(0)1273-808309

More information about the Users mailing list