same problem on p4 non-smp box. i upgraded yum and sqlite and now yum hangs while trying to read the xml data. i did a yum clean all and verified nothing was left in /var/cache/yum. i'll try strace/ltrace to see what i can find...

On Thu, 31 Aug 2006, Julio E. Gonzalez P. wrote:

I have the same problem here... Anyone has something to say about this? Thanks. Julio.

Simen Thoresen wrote:

...

CentOS 4.3 (SMP, x86_64, Athlon64 X2) with all pre-4.4 release updates applied.

Since I ran into the Yum issue at the previous upgrade, I first did yum upgrade to get the list of packages (6 to install, 206 to update). I then did yum upgrade yum (which passed without issues) yum upgrade sqlite (which passed without isseus).

Fairly certain that yum now works correctly, I wanted to just do another small upgrade before doing the rest, and did yum upgrade samba

[root@naboens ~]# yum upgrade samba Setting up Upgrade Process Setting up repositories Reading repository metadata in from local files

<no progress>

This seemed to hang, and a look at top showed yum consuming more and more memory, the system starting to swap and bog down and then become unresponsive (all swap exhausted, I was not quick enough to kill yum).

I was able to reproduce this on a different machine (also x86_64, SMP and Athlon64 X2), so it seems to be an actual problem. As I can play around a bit more on this machine, I tried doing a yum upgrade (without specifying samba) and it behaves the same (ie yum consuming increasing amounts of memory while "Reading repository metadata (etc)".

Has anyone else experienced and been able to resolve this?

On Thu, Aug 31, 2006 at 08:24:51AM -0700, Joe Pruett wrote:

it isn't futex. strace shows it going into a brk() loop which explains the huge memory growth. sure looks like a bug in yum or sqlite. time to dive into python debugging...

I notice there's an update to python-sqlite. Does the problem occur if that is upgraded along with or before sqlite itself?

Joe Pruett wrote:

bingo! that seems to fix things.

so for anyone who got themselves in the same state, just: rpm -F python-sqlite-1.1.7-1.2.i386.rpm

and then the world is happy again.

I've just kicked off the process on one of my spare boxes. I manually updated python-sqlite and then sqlite. And am now running a yum update. I should have the answer pretty quickly since it's a very fast multiprocessor box colocated in a carrier hotel. :)

Cheers,

On Thu, Aug 31, 2006 at 08:58:54AM -0700, Joe Pruett wrote:

bingo! that seems to fix things. so for anyone who got themselves in the same state, just: rpm -F python-sqlite-1.1.7-1.2.i386.rpm and then the world is happy again.

I remember a similar problem from when we updated sqlite on our FC4-based systems.

CentOS developers -- any chance of re-issuing the release notes with this added bit of information?

On Thu, Aug 31, 2006 at 11:28:12AM -0500, Johnny Hughes wrote:

Sure ... help me understand the problem better. If you are going to upgrade yum separately first, so it like this: yum update yum sqlite python-sqlite python-urlgrabber python-elementtree then perform the other updates ....

python-sqlite 1.1.7 works with sqlite 3.2.x, but python-sqlite 1.1.6 doesn't work right with sqlite 3.3.x. (It might be nice if the sqlite 3.3.x package had "Conflicts: python-sqlite < 1.1.6, but oh well.) Therefore, I actually think one should do

yum upgrade python-sqlite

before everything else. (And then probably yum and all the other yum deps, to be safe.)

On Thu, Aug 31, 2006 at 11:10:24PM +0200, Simen Thoresen wrote:

I've updated two boxes by doing # yum upgrade yum sqlite python-sqlite and then # yum upgrade If I understand correctly, my problem this time was caused by me trying to be cautious to avoid a problem similar to the last previous major update.

I don't think so -- it happens that the sqlite and python-sqlite updates are simultaneous here.

If I had done # yum upgrade I had not run into the conflict, right?

No, it can happen then, 'cause that can put the new sqlite into place before the new python-sqlite.

Why this causes this particular problem I have no idea.

Should not sqlite depend on python-sqlite if python-sqlite needs to be updated first?

Nope, because sqlite will work fine without the python bindings.

On Fri, Sep 01, 2006 at 01:32:52AM +0100, Karanbir Singh wrote:

...

...

Should not sqlite depend on python-sqlite if python-sqlite needs to be updated first?

Nope, because sqlite will work fine without the python bindings.

python-sqlite-1.1.7 with a requires for the right, newer version of sqlite should resolve this issue..

How so? The problem isn't that python-sqlite 1.1.7 requires sqlite 3.3.x -- it's that sqlite 3.3.x conflicts with python-sqlite 1.1.6.

It doesn't matter if you make python-sqlite 1.1.7 require the new version of sqlite -- in fact, that'll likely make it worse, since it'll make sqlite get updated first, which is the wrong way around.

On Thursday 31 August 2006 21:36, Karanbir Singh wrote:

right, in which case, we either need sqlite to require the newer python-sqlite (!?!) or Conflict the older one (!)

Good luck with versioned Conflicts: directives. I never could get that to work right with the postgresql-server package; I tried to specifically get the newer version to conflict with the older one (and vice-versa) to try to prevent blind upgrades. It didn't work at that time (postgresql version 7.4, the version shipped with CentOS 4).

On Sat, Sep 02, 2006 at 07:42:00AM -0500, Gerald Waugh wrote:

We have a problem with upgrade to 4.4 When we run 'yum update' everything appears to be OK But, if we reboot the server with the new kernel, we get "kernel panic" when the new kernel attempts to load.

This is a different issue. Please start a new thread.

Excuse me, sure looked like a Yum upgrade to 4.4 problem to me.

Looks can be deceiving. You said yum completes successfully. This is not the same as others where yum appears to lock up on them and never completes during the update. (FWIW, yum update yum, THEN running yum update worked fine for me) Your issue is a kernel panic on reboot. This is an entirely separate animal not related to yum, but instead related to the new software you installed. You did hijack the thread, though not intentionally.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Sat, Sep 02, 2006 at 10:19:12AM -0400, chrism@imntv.com wrote:

So we've had a few days of excitement. Have any of the maintainers been able to come up with a recipe for updating that circumvents the issues most (all?) of the time?

For what it's worth, this is working for me:

yum update python-sqlite sqlite yum update reboot

I've been too chicken to try "yum update" all by itself. :)

Well, I only tried "yum update" by itself on one computer, and it worked flawlessly. On all my other computers, using the:

yum update yum python-sqlite sqlite yum update reboot

Worked fine. I had no issues upgrading to 4.4. Then again, I don't use postfix, so I can't tell if there is a safe way on that quarter.

[]s

- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)

On Sat, September 2, 2006 10:24 am, Rodrigo Barbosa wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Sat, Sep 02, 2006 at 10:19:12AM -0400, chrism@imntv.com wrote:

...

So we've had a few days of excitement. Have any of the maintainers been able to come up with a recipe for updating that circumvents the issues most (all?) of the time?

For what it's worth, this is working for me:

yum update python-sqlite sqlite yum update reboot

I've been too chicken to try "yum update" all by itself. :)

Well, I only tried "yum update" by itself on one computer, and it worked flawlessly. On all my other computers, using the:

yum update yum python-sqlite sqlite yum update reboot

Worked fine. I had no issues upgrading to 4.4. Then again, I don't use postfix, so I can't tell if there is a safe way on that quarter.

"up2date -u" works great.