At 12:26 PM -0500 12/4/06, Jeff Johnson wrote: >On Dec 4, 2006, at 12:03 PM, Tony Nelson wrote: > >> >>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. > >Well that's perhaps overly strict. > >All I'm really trying to say is that more players in the rpmdb concurrency >mix impose stricter demands on the implementation which is already hard to >debug. > >cron started programs can lead to surprises. Yes, I see issues that turn out to be that often enough on fedora-list. >And there is no reason why I know of why all this debugging and fixing and >testing and verifying of an rpmdb needs to be done with "production" users. Aside from the current flap with yum, of course. My feeling is that something should be safely checking such an important set of files on a regular basis. Even with your new changes, I don't think my own personal failed database would be fixed, as RPM wasn't normally having trouble with it, even during yum updates. (And the corruption happened under FC5.) I had to either do just the right thing to get RPM to complain in normal use, or run "rpm --verifydb". My thought is that there could be corruption that RPM / Berekely DB don't notice that leads to more corruption as time goes on, as I have seen happen in the past with other file formats. >One should approach "production" deployments carefully and conservatively, >not just throw some change into rawhide and assume "works". I agree. (I don't and can't put anything into Rawhide.) >By all means try and run multiple RPM clients, and test the concurrency >thoroughly. Just not on every user's FC6 box until thoroughly tested >elsewhere. Ehh, probably there are bunches of users out there now with boxes upgraded from earlier FCs that have more than one yum updating thing running automatically. There was the old daily cron thing, and there's the new yumupdatesd (sp?) that runs, I think, hourly. There's the daily RPM package listing. There's probably even more. Any daily script I write could easily run at the same time as one or more of those. Even if it works perfectly under such stress as I can provide, I can't feel assured that it will work everywhere in the face of your experience. >AFAIK, read concurrency is well tested since RHL9, and write serialization >within a concurrency environment is mostly well tested (there's an >additional fcntl lock taken to ensure write serialization Just In Case). > >The implicit assumption in the above is that a database environment exists >continuously through process executions. All that the Berkeley DB locks in >a concurrent access model guarantee is "multiple readers or single writer". > >The new wrinkle introduced by the "del ts" in yum is re-establishing a >database environment several orders of magnitude more often than >previously. And that "mostly works" afaict, or all rpmdb's would have >suffered total meltdown by now. As I say in my other reply, I think that the "del ts" is a red herring, unrelated in operation to the actual closing of the database. The destructor only calls it when its object goes away, which would drop the reference to the ts in any case, which I expect would already close the database when its last reference is lost. So, if the destructor were removed, the database would still close in all the same places. Its that closing and reopening that triggers the problems. Destructors are a subtle area of Python which are normally not needed and whose use is discouraged. I haven't written any myself. The rpmlib Python bindings, in C, will be doing a destructor thing when the ts loses its last reference, but its being done by the comptetent C programmers writing the Python binding module for rpmlib, not by some mere Python coder. -- ____________________________________________________________________ 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
