Reindl Harald wrote:
Am 18.12.2012 19:41, schrieb Ken Smith:
Hi All, I have a Centos 5.8 system with relatively little memory, that runs in rl3, where yum has decided not to work any more.
{snip}
Any ideas where to look - I'm a bit stumped
at least with "dmesg" and in /var/log/messages where ANY useful information will be found if problems happening
Indeed. Nothing is getting logged to messages.
Here are the last few system calls logged by running yum via strace
open("/usr/lib/python2.4/_socketmodule.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.4/_socket.py", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.4/_socket.pyc", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) stat64("/usr/lib/python2.4/plat-linux2/_socket", 0xbfdb3954) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.4/plat-linux2/_socket.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.4/plat-linux2/_socketmodule.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.4/plat-linux2/_socket.py", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.4/plat-linux2/_socket.pyc", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) stat64("/usr/lib/python2.4/lib-tk/_socket", 0xbfdb3954) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.4/lib-tk/_socket.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.4/lib-tk/_socketmodule.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.4/lib-tk/_socket.py", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.4/lib-tk/_socket.pyc", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) stat64("/usr/lib/python2.4/lib-dynload/_socket", 0xbfdb3954) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.4/lib-dynload/_socket.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.4/lib-dynload/_socketmodule.so", O_RDONLY|O_LARGEFILE) = 7 fstat64(7, {st_mode=S_IFREG|0555, st_size=49268, ...}) = 0 open("/usr/lib/python2.4/lib-dynload/_socketmodule.so", O_RDONLY) = 8 read(8, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240\33\0\0004\0\0\0"..., 512) = 512 fstat64(8, {st_mode=S_IFREG|0555, st_size=49268, ...}) = 0 mmap2(NULL, 48008, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 8, 0) = 0xdcc000 mmap2(0xdd5000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 8, 0x9) = 0xdd5000 close(8) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++
whereas on a good system, albeit 64 bit, it proceds beyond that point, as follows...
open("/usr/lib64/python2.4/lib-dynload/_socketmodule.so", O_RDONLY) = 7 fstat(7, {st_mode=S_IFREG|0555, st_size=52152, ...}) = 0 open("/usr/lib64/python2.4/lib-dynload/_socketmodule.so", O_RDONLY) = 8 read(8, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`.\0\0\0\0\0\0"..., 832) = 832 fstat(8, {st_mode=S_IFREG|0555, st_size=52152, ...}) = 0 mmap(NULL, 2147440, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 8, 0) = 0x2ae0a0858000 mprotect(0x2ae0a0862000, 2093056, PROT_NONE) = 0 mmap(0x2ae0a0a61000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 8, 0x9000) = 0x2ae0a0a61000 close(8) = 0 mmap(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ae0a0a65000 close(7) = 0
On both the faulty system and a good one, yum appears to hunt for various versions of python files.
Anyone with more knowledge that I have of system calls, is there a clue in here?
Thanks
Ken
Ken Smith wrote:
On both the faulty system and a good one, yum appears to hunt for various versions of python files.
Anyone with more knowledge that I have of system calls, is there a clue in here?
You could try flushing the file system cache:
echo 3 > /proc/sys/vm/drop_caches
(or reboot) and try again ?
James Pearson
James Pearson wrote:
Ken Smith wrote:
On both the faulty system and a good one, yum appears to hunt for various versions of python files.
Anyone with more knowledge than I have of system calls, is there a clue in here?
You could try flushing the file system cache:
echo 3> /proc/sys/vm/drop_caches
(or reboot) and try again ?
James Pearson
Hi James, brilliant "echo 3 > /proc/sys/vm/drop_caches" worked. So does that mean that there wasn't enough free memory for yum to run?
Thanks
Ken
Ken Smith wrote:
Hi James, brilliant "echo 3 > /proc/sys/vm/drop_caches" worked. So does that mean that there wasn't enough free memory for yum to run?
No, it might mean that there was a 'corruption' of the in-memory copy of 'something' used by yum/python
The above command flushes the file system cache - so the 'something' has to be read back into memory from disk again (I have no idea what this 'something' is ...)
I guess this 'corruption' (if it is indeed a corruption) shouldn't happen - but I have noticed this with yum before - and flushing the cache in this way generally 'fixes' the issue for me
James Pearson
James Pearson wrote:
Ken Smith wrote:
Hi James, brilliant "echo 3 > /proc/sys/vm/drop_caches" worked. So does that mean that there wasn't enough free memory for yum to run?
No, it might mean that there was a 'corruption' of the in-memory copy of 'something' used by yum/python
I had wondered about memory integrity so I had run a memory test - that passed. Oh well.
Thanks
Ken