At 12:20 PM -0500 12/4/06, James Olin Oden wrote: >> >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. >The problem is with the first statement. You can't enforce that no >one will run yum for instance while your cron job is running. I know that it is impossible to for me to enforce, and I should have been more clear. You are both saying that I should not compound the issue of multiple concurrent RPM clients by adding another one. >You can >on the other hand look for a semaphore file or a mutex, and provide a >way to set said semaphore, such that it is possible to play nice with >your script. That said, if your script became somewhat standard then >most would not be aware that this was needed (kind of like I had to >figure out to turn off the cron job that came as standard part of all >RedHat distributions I've used since RH 9). If RPM starts doing this on its own, as Jeff has been working toward in recent patches, my script would serve no purpose and I won't push for its wide adoption. >All this said RPM is supposed to support concurrent access. Yes, and I understand the difficulty of getting it completely right, and the difficulty of tracking down the failures, especially when failure is so serious that having a tiny fraction of installations fail in a year is too much. I see that Jeff is moving forward on the issue, by making new ways to provoke the problems with concurrent access that might produce enough data to find and fix them. -- ____________________________________________________________________ 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
