Ofcourse, if # rpm -Va is segfaulting, so does #rpm -V libsepol -----Original Message----- From: Oleg Sadov [mailto:[email protected]] Sent: woensdag 25 juni 2014 17:13 To: Werf, C.G. van der (Carel) Cc: Pat Riehecky; [email protected] 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) <[email protected]> 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:[email protected]] > Sent: woensdag 25 juni 2014 16:20 > To: Werf, C.G. van der (Carel); > [email protected] > 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:[email protected]] >> Sent: woensdag 25 juni 2014 16:03 >> To: Werf, C.G. van der (Carel); >> [email protected] >> 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:[email protected]] >>> Sent: dinsdag 24 juni 2014 14:18 >>> To: Werf, C.G. van der (Carel); '[email protected]' >>> 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: [email protected] >>> [mailto:[email protected]] On Behalf Of >>> Werf, C.G. van der (Carel) >>> Sent: Tuesday, June 24, 2014 12:23 AM >>> To: '[email protected]' >>> 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/
