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 ---- / o...@inguza.com Annebergsslingan 37 \ | o...@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 / --------------------------------------------------------------- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
