Seems like corrupted system -- reinstallation with HDD formatting may
be helpful.
Also, if you interested in details, you may get core dump by setting
of 'ulimit -c unlimited', install of debuginfo packages and examine of
dumped state by gdb:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Developer_Guide/debugging.html
On Wed, Jun 25, 2014 at 7:19 PM, Werf, C.G. van der (Carel)
<[log in to unmask]> wrote:
> Ofcourse, if # rpm -Va is segfaulting, so does #rpm -V libsepol
>
> -----Original Message-----
> From: Oleg Sadov [mailto:[log in to unmask]]
> Sent: woensdag 25 juni 2014 17:13
> To: Werf, C.G. van der (Carel)
> Cc: Pat Riehecky; [log in to unmask]
> Subject: Re: [SCIENTIFIC-LINUX-USERS] yum segfaulting
>
> What about rpm -V libsepol ?
>
> On Wed, Jun 25, 2014 at 6:25 PM, Werf, C.G. van der (Carel) <[log in to unmask]> wrote:
>> # ldd /bin/rpm
>> librpm-4.4.so => /usr/lib64/librpm-4.4.so (0x00000034be400000)
>> librpmdb-4.4.so => /usr/lib64/librpmdb-4.4.so (0x00000034be000000)
>> libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003744000000)
>> librpmio-4.4.so => /usr/lib64/librpmio-4.4.so (0x00000034bdc00000)
>> libpopt.so.0 => /usr/lib64/libpopt.so.0 (0x0000003748c00000)
>> libsqlite3.so.0 => /usr/lib64/libsqlite3.so.0 (0x0000003745000000)
>> libelf.so.1 => /usr/lib64/libelf.so.1 (0x0000003744400000)
>> libm.so.6 => /lib64/libm.so.6 (0x0000003742c00000)
>> libz.so.1 => /usr/lib64/libz.so.1 (0x0000003743800000)
>> libnss3.so => /usr/lib64/libnss3.so (0x00000034bd800000)
>> libnssutil3.so => /usr/lib64/libnssutil3.so (0x00000034bd400000)
>> libplds4.so => /usr/lib64/libplds4.so (0x0000003b82600000)
>> libplc4.so => /usr/lib64/libplc4.so (0x0000003b82a00000)
>> libnspr4.so => /usr/lib64/libnspr4.so (0x0000003b81a00000)
>> libdl.so.2 => /lib64/libdl.so.2 (0x0000003742800000)
>> librt.so.1 => /lib64/librt.so.1 (0x0000003743400000)
>> libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003743000000)
>> libbz2.so.1 => /usr/lib64/libbz2.so.1 (0x0000003757200000)
>> libc.so.6 => /lib64/libc.so.6 (0x0000003742400000)
>> libsepol.so.1 => /lib64/libsepol.so.1 (0x000000319b000000)
>> /lib64/ld-linux-x86-64.so.2 (0x0000003742000000)
>> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003752200000)
>>
>> Looks exactly the same on both systems (the "working" and the
>> "segfaulting" one)
>>
>> Carel
>> -----Original Message-----
>> From: Pat Riehecky [mailto:[log in to unmask]]
>> Sent: woensdag 25 juni 2014 16:20
>> To: Werf, C.G. van der (Carel);
>> [log in to unmask]
>> Subject: Re: [SCIENTIFIC-LINUX-USERS] yum segfaulting
>>
>> Indeed!
>>
>> anything curious on ldd of rpm?
>>
>> Pat
>>
>> On 06/25/2014 09:11 AM, Werf, C.G. van der (Carel) wrote:
>>> Hi Pat,
>>>
>>> # ldd /lib64/libsepol.so.1
>>> libc.so.6 => /lib64/libc.so.6 (0x0000003742400000)
>>> /lib64/ld-linux-x86-64.so.2 (0x0000003742000000)
>>>
>>> # rpm -Va
>>> Segmentation fault
>>>
>>> Ha, that's interesting ... it might be rpm after all ?
>>>
>>>
>>> Carel
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Pat Riehecky [mailto:[log in to unmask]]
>>> Sent: woensdag 25 juni 2014 16:03
>>> To: Werf, C.G. van der (Carel);
>>> [log in to unmask]
>>> Subject: Re: [SCIENTIFIC-LINUX-USERS] yum segfaulting
>>>
>>> I'm a bit curious what does
>>>
>>> ldd /lib64/libsepol.so.1
>>>
>>> report?
>>>
>>> Also, you may want to try:
>>>
>>> rpm -Va
>>>
>>> That will take loads of time, but may report something interesting.
>>>
>>> Pat
>>>
>>> On 06/25/2014 07:44 AM, Werf, C.G. van der (Carel) wrote:
>>>> Running an strace still offers no clues to this problem...
>>>>
>>>>
>>>> When running:
>>>> # strace yum --help 2>&1 | cat > yum-tracelog
>>>>
>>>>
>>>> I see this at the end of the log.
>>>>
>>>> open("/lib64/libsepol.so.1", O_RDONLY) = 6 read(6,
>>>> "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0=\300C7\0\0\0"...,
>>>> 832) = 832 fstat(6, {st_mode=S_IFREG|0755, st_size=247496, ...}) = 0
>>>> mmap(0x3743c00000, 2383136, PROT_READ|PROT_EXEC,
>>>> MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x3743c00000
>>>> mprotect(0x3743c3b000, 2097152, PROT_NONE) = 0 mmap(0x3743e3b000,
>>>> 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x3b000) = 0x3743e3b000 mmap(0x3743e3c000, 40224, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x3743e3c000
>>>> close(6) = 0
>>>> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
>>>> +++ killed by SIGSEGV +++
>>>> <<
>>>>
>>>> So after closing /lib64/libsepol.so.1, the segfault is triggered.
>>>>
>>>> But, since I disabled selinux, why is there a call to libsepol.so.1 ?
>>>>
>>>>
>>>> On a my mirror-server, the same call to # yum --help" does work without segfault.
>>>> An strace in this situation, will show that after closing the /lib64/libespol.so.1 the next commands are traced ...
>>>>
>>>> mprotect(0x319a607000, 4096, PROT_READ) = 0
>>>> access("/etc/selinux/", F_OK) = 0
>>>> open("/etc/selinux/config", O_RDONLY) = 6
>>>> fstat(6, {st_mode=S_IFREG|0644, st_size=511, ...}) = 0 mmap(NULL,
>>>> 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
>>>> 0x2b9d45eb4000 read(6, "# This file controls the state o"..., 4096) = 511
>>>> read(6, "", 4096) = 0
>>>> close(6)
>>>> <
>>>>
>>>> /etc/selinux/config is identical on both systems.
>>>>
>>>>
>>>> Anyone a clue ?
>>>>
>>>> Regards,
>>>> Carel
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Zhi-Wei Lu [mailto:[log in to unmask]]
>>>> Sent: dinsdag 24 juni 2014 14:18
>>>> To: Werf, C.G. van der (Carel); [log in to unmask]
>>>> Subject: RE: yum segfaulting
>>>>
>>>> I had similar problem before, someone changed the stock system libz.so with a newer version libz.so, which yum didn't like it!
>>>>
>>>> Zhi-Wei Lu
>>>> IET-CR-Network Operations Center
>>>> University of California, Davis
>>>> (530) 752-0155
>>>>
>>>> -----Original Message-----
>>>> From: [log in to unmask]
>>>> [mailto:[log in to unmask]] On Behalf Of
>>>> Werf, C.G. van der (Carel)
>>>> Sent: Tuesday, June 24, 2014 12:23 AM
>>>> To: [log in to unmask]
>>>> Subject: yum segfaulting
>>>>
>>>> Hi,
>>>>
>>>> I have two identical SL 5.3 fileservers, who function as a DRBD-pair.
>>>> One of them was recently completely replaced with identical hardware, so I had to image the old one, and install OS-image on "new" server.
>>>>
>>>> But now, when I run yum on the new server, it returns a segmentation fault (even a simple: # yum --help).
>>>>
>>>> Googling this, a lot of pages hint for a memory error. But, running a memtest did not show any error.
>>>>
>>>> So far, only yum returns the segmentation fault.
>>>>
>>>> Does anyone have any clue for this ?
>>>>
>>>> Regards,
>>>> Carel van der Werf
>>>
>>> --
>>> Pat Riehecky
>>>
>>> Scientific Linux developer
>>> http://www.scientificlinux.org/
>>>
>>
>>
>> --
>> Pat Riehecky
>>
>> Scientific Linux developer
>> http://www.scientificlinux.org/
|
