At 7:31 AM -0500 12/4/06, James Olin Oden wrote: >> >With fewer players, concurrent access in rpmdb is likelier to be >> >"stable" because updates are like daily, not every second. >> >> I think you're saying that cron scripts for RPM are bad because 1) they >> often tempt fate by running at the same time and 2) when they get stuck >> usually it it >> isn't noticed for a long time. >> >Yes, he is. OK, got it. >I've actually experienced this in the RH 9 time frame, >when rpm had many more issues with dead locks. Basically, I was >getting calls where an "upgrade" was hung at around 4:00 in the >morning. I finally made the correlation (well really someone hit me >with a clue bat) that that was the same time the "rpm -qa" cron job >was running. In minutes I had a reproducer. My solution was to turn >off cron during our upgrades (which is reasonable since you don't want >random stuff kicking off in the middle of your upgrade). > >All that said, what I would take from this if I was going to write a >cron job that examined the rpm database in anyway, is wire in some way >of disabling the behavior, and wire in some way to actually tell that >its doing the query right now. This allows someone to say, "don't >look right now", and to tell if the message was received. Then they >can merrily do whatever they need to do, without worrying about >another party accessing the db concurrently. Don't allow more than one RPM client to run at a time. Especially don't /schedule/ two to run at the same time. OK, thanks. -- ____________________________________________________________________ TonyN.:' The Great Writ <mailto:tonynelson@xxxxxxxxxxxxxxxxx> ' is no more. <http://www.georgeanelson.com/> _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
