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/
|
