public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
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... :)


  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