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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
