From: Tanstaafl <tanstaafl@libertytrek.org>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Apache died this morning... why?
Date: Mon, 30 Dec 2013 07:25:56 -0500 [thread overview]
Message-ID: <52C16654.1060307@libertytrek.org> (raw)
In-Reply-To: <52C15972.7080103@gmail.com>
On 2013-12-30 6:30 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> To see what's going on, run ldd on:
>
> /usr/lib64/apache2/modules/libphp5.s
Result:
> # ldd /usr/lib64/apache2/modules/libphp5.so
> ldd: warning: you do not have execution permission for `/usr/lib64/apache2/modules/libphp5.so'
> linux-vdso.so.1 (0x00007fffc3cbf000)
> libc-client.so.1 => /usr//lib64/libc-client.so.1 (0x00007f279599d000)
> libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f279577b000)
> libreadline.so.6 => /lib64/libreadline.so.6 (0x00007f2795535000)
> libaspell.so.15 => /usr//lib64/libaspell.so.15 (0x00007f2795263000)
> libm.so.6 => /lib64/libm.so.6 (0x00007f2794f69000)
> libssl.so.1.0.0 => /usr//lib64/libssl.so.1.0.0 (0x00007f2794cff000)
> libcrypto.so.1.0.0 => /usr//lib64/libcrypto.so.1.0.0 (0x00007f279491a000)
> libz.so.1 => /lib64/libz.so.1 (0x00007f2794703000)
> libmcrypt.so.4 => /usr//lib64/libmcrypt.so.4 (0x00007f27944d1000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00007f27942cd000)
> libonig.so.2 => /usr//lib64/libonig.so.2 (0x00007f2794062000)
> libt1.so.5 => /usr//lib64/libt1.so.5 (0x00007f2793e03000)
> libfreetype.so.6 => /usr//lib64/libfreetype.so.6 (0x00007f2793b64000)
> libpng15.so.15 => /usr//lib64/libpng15.so.15 (0x00007f2793939000)
> libjpeg.so.8 => /usr//lib64/libjpeg.so.8 (0x00007f27936e4000)
> libdb-4.8.so => /usr//lib64/libdb-4.8.so (0x00007f279336a000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f279314c000)
> libgdbm.so.3 => /usr//lib64/libgdbm.so.3 (0x00007f2792f46000)
> libcurl.so.4 => /usr//lib64/libcurl.so.4 (0x00007f2792ceb000)
> libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f2792ada000)
> libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f2792873000)
> libxml2.so.2 => /usr//lib64/libxml2.so.2 (0x00007f2792512000)
> libmysqlclient.so.16 => /usr/lib64/mysql/libmysqlclient.so.16 (0x00007f279218b000)
> libnetsnmp.so.30 => /usr//lib64/libnetsnmp.so.30 (0x00007f2791eb0000)
> libc.so.6 => /lib64/libc.so.6 (0x00007f2791b0a000)
> libpam.so.0 => /lib64/libpam.so.0 (0x00007f27918fb000)
> libncurses.so.5 => /lib64/libncurses.so.5 (0x00007f27916d8000)
> libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6 (0x00007f27913d3000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f279681b000)
> librt.so.1 => /lib64/librt.so.1 (0x00007f27911ca000)
> libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f2790f95000)
> libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libgcc_s.so.1 (0x00007f2790d7e000)
and
> /usr//lib64/libcurl.so.4
> # ldd /usr//lib64/libcurl.so.4
> linux-vdso.so.1 (0x00007fffa7bff000)
> libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 (0x00007f510232b000)
> libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x00007f5101f46000)
> libz.so.1 => /lib64/libz.so.1 (0x00007f5101d2f000)
> librt.so.1 => /lib64/librt.so.1 (0x00007f5101b27000)
> libc.so.6 => /lib64/libc.so.6 (0x00007f5101781000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00007f510157c000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f510135f000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f51027fb000)
Doesn't mean anything to me though... ;)
> preserved-rebuild should just take care of all this automagically.
> Do you have preserve-libs in FEATURES?
Nope... is this now recommended? Is it the default on new installs?
> Do a pretend run of revdep-rebuild. I'll bet you end up rebuilding curl
> and/or php, but not apache.
Actually, I did that right after the updates and it didn't recommend
anything (I always do revdep-rebuild -p after any system updates like
gcc, glib/c, etc)...
> Apache is unlikely to be at fault, it loads a dynamic module and use it,
> that module either works or it doesn't.
Ok... so, the question is still why did it die?
This happened by the way when the logs were rotated by logrotate. Maybe
that is significant?
>> The GCC Upgrade guide is a bit outdated (still referring to gcc 3.4 and
>> 4.1, with no mention of newer versions, so I wasn't sure if that was
>> still necessary...
> According to the posted error, this has nothing to do with compiler
> versions, it is linker errors related to glibc
>
> You do not have to rebuild system, world or the known universe. You only
> have to do that when the a gcc upgrade changes the data format on-disk
> that the C++ compiler generates. That has not happened here.
>
> There's an insane amounts of FUD around about rebuilding gcc, all of it
> originating from ricers without a clue. You run strictly stable-only so
> never fear, if a gcc upgrade required a world rebuild you would have
> already been subjected to 12-month long threads about it right here on
> this list
I know, and the GCC upgrade guide is pretty clear on that point, and
since I didn't say anything about rebuilding anything other than
sys-devel/libtool, which it does specifically mention, I'm not sure why
you brought that up in this context.
I just did it (rebuilt libtool) anyway, maybe I should do the same for
curl and/or php...
No worries, apache is only used for local admin stuff anyway, so it
isn't like anyone other than me will notice if it dies... :)
next prev parent reply other threads:[~2013-12-30 12:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-30 10:47 [gentoo-user] Apache died this morning... why? Tanstaafl
2013-12-30 11:30 ` Alan McKinnon
2013-12-30 12:25 ` Tanstaafl [this message]
2013-12-30 12:40 ` Alan McKinnon
2013-12-30 13:44 ` Tanstaafl
2013-12-31 1:35 ` Neil Bothwick
2013-12-31 11:13 ` Tanstaafl
2013-12-31 10:57 ` Alan McKinnon
2013-12-31 11:18 ` Tanstaafl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52C16654.1060307@libertytrek.org \
--to=tanstaafl@libertytrek.org \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox