Re: The value of direct inspection (was: Re: --initdb)

["James Olin Oden" <james oden gmail com>]

> >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.  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).

All this said RPM is supposed to support concurrent access.

...james