| Re: Bug#636463: vzctl: /etc/vz/dists/scripts/postcreate.sh randomises run-times in /etc/crontab, but [message #43214] |
Tue, 09 August 2011 09:27  |
Tim Small
Messages: 24
Registered: April 2011
|
Junior Member |
|
|
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).
Tim.
p.s. a quick bit of research seems to show up the problem coming up
again and again...
https://bugs.launchpad.net/debian/+source/cron/+bug/672303
http://projects.puppetlabs.com/projects/1/wiki/Cron_Patterns
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=373152
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
|
|
|
|
| Re: Bug#636463: vzctl: /etc/vz/dists/scripts/postcreate.sh randomises run-times in /etc/crontab, but [message #43231 is a reply to message #43214] |
Wed, 10 August 2011 04:47  |
Ola Lundqvist
Messages: 15
Registered: April 2006
|
Junior Member |
|
|
Hi Tim
On Tue, Aug 09, 2011 at 10:27:15AM +0100, Tim Small wrote:
> 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.
Yes you are right. For "fat" VZ templates it would be more likely to
be ok.
> > 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.
Even across any virtualize unix system using cron. :-)
> 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.
I have experienced this myself so I fully trust you. I mean there is a reason
why the cron config is rewritten.
> 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?
That would be a way. Or even the package could randomize it on itself.
I mean the same thing happens on physical servers as well if you have
many of them.
> 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).
I'm leaning on submitting wishlist bug requests on packages that can
cause a load on external functions (network or similar) to randomize
their cron file.
Best regards,
// Ola
> Tim.
>
> p.s. a quick bit of research seems to show up the problem coming up
> again and again...
>
> https://bugs.launchpad.net/debian/+source/cron/+bug/672303
>
> http://projects.puppetlabs.com/projects/1/wiki/Cron_Patterns
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=373152
>
> 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
>
>
--
--- Inguza Technology AB --- MSc in Information Technology ----
/ ola@inguza.com Annebergsslingan 37 \
| opal@debian.org 654 65 KARLSTAD |
| http://inguza.com/ Mobile: +46 (0)70-332 1551 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
------------------------------------------------------------ ---
|
|
|
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
