PHP :: Bug #14870 :: Some modules break SIGUSR1 and SIGHUP

Bug #14870

Some modules break SIGUSR1 and SIGHUP

Submitted:

2002-01-05 09:00 UTC

Modified:

2003-08-26 00:57 UTC

Votes:	2
Avg. Score:	5.0 ± 0.0
Reproduced:	2 of 2 (100.0%)
Same Version:	2 (100.0%)
Same OS:	1 (50.0%)

From:

msopacua at idg dot nl

Assigned:

Status:

No Feedback

Package:

Dynamic loading

PHP Version:

4.0CVS-2002-10-16

OS:

BSDi 4.x

Private report:

CVE-ID:

None

View Developer Edit

[2002-01-05 09:00 UTC] msopacua at idg dot nl

First some details:
gd version: 2.0.1, using custom Makefile (will send it seperately to the php-dev list).
Tested OS: BSDi 4.2, but bug exists in elder versions of all components (OS/PHP/GD)

When apache receives a SIGUSR1, the childs start cycling, eating CPU power and causing a load of appr. 3 per apache child.

A SIGHUP doesn't work correctly:
[Sat Jan  5 13:52:57 2002] [notice] caught SIGTERM, shutting down
[Sat Jan  5 13:55:56 2002] [notice] Apache/1.3.22 (Unix) PHP/4.2.0-dev mod_perl/1.26 configured -- resuming normal operations
[Sat Jan  5 13:55:56 2002] [notice] Accept mutex: flock (Default: flock)
[Sat Jan  5 13:56:00 2002] [warn] child process 18897 did not exit, sending another SIGHUP
[Sat Jan  5 13:56:00 2002] [warn] child process 18898 did not exit, sending another SIGHUP
[Sat Jan  5 13:56:00 2002] [warn] child process 18899 did not exit, sending another SIGHUP
[Sat Jan  5 13:56:00 2002] [warn] child process 18900 did not exit, sending another SIGHUP
[Sat Jan  5 13:56:00 2002] [warn] child process 18901 did not exit, sending another SIGHUP
[Sat Jan  5 13:56:02 2002] [warn] child process 18897 still did not exit, sending a SIGTERM
[Sat Jan  5 13:56:02 2002] [warn] child process 18898 still did not exit, sending a SIGTERM
[Sat Jan  5 13:56:02 2002] [warn] child process 18899 still did not exit, sending a SIGTERM
[Sat Jan  5 13:56:02 2002] [warn] child process 18900 still did not exit, sending a SIGTERM
[Sat Jan  5 13:56:02 2002] [warn] child process 18901 still did not exit, sending a SIGTERM
[Sat Jan  5 13:56:06 2002] [error] child process 18897 still did not exit, sending a SIGKILL
[Sat Jan  5 13:56:06 2002] [error] child process 18898 still did not exit, sending a SIGKILL
[Sat Jan  5 13:56:06 2002] [error] child process 18899 still did not exit, sending a SIGKILL
[Sat Jan  5 13:56:06 2002] [error] child process 18900 still did not exit, sending a SIGKILL
[Sat Jan  5 13:56:06 2002] [error] child process 18901 still did not exit, sending a SIGKILL
[Sat Jan  5 13:56:06 2002] [notice] SIGHUP received.  Attempting to restart
[Sat Jan  5 13:56:06 2002] [notice] Apache/1.3.22 (Unix) PHP/4.2.0-dev mod_perl/1.26 configured -- resuming normal operations
[Sat Jan  5 13:56:06 2002] [notice] Accept mutex: flock (Default: flock)

All this disappears, when eliminating gd from the equasion.

I think the cause lies in the linking of the library. Even though I have configured php to use the shared version:
        --with-gd=shared,/weblib/local \
        --with-freetype-dir=/weblib/local

gd is linked into libphp4.so:
$ ldd libphp4.so
        ./libphp4.so => ./libphp4.so (0x4805b000)
        libdl.so => /shlib/libdl.so (0x481f9000)
        libm.so => /shlib/libm.so.0.0 (0x481fd000)
        libsablot.so.0 => /weblib/local/lib/libsablot.so.0 (0x4820e000)
        libexpat.so.0 => /weblib/local/lib/libexpat.so.0 (0x482b6000)
        libmysqlclient.so.10 => /weblib/local/lib/mysql/libmysqlclient.so.10 (0x482d7000)
        libiconv.so.2 => /weblib/local/lib/libiconv.so.2 (0x482f4000)
        libgd.so.2 => /weblib/local/lib/libgd.so.2 (0x483c9000)
        libfreetype.so.6 => /weblib/local/lib/libfreetype.so.6 (0x483fc000)
        libssl.so.0.9.6 => /weblib/local/lib/libssl.so.0.9.6 (0x48430000)
        libcrypto.so.0.9.6 => /weblib/local/lib/libcrypto.so.0.9.6 (0x484e6000)
        libc.so.2 => /shlib/libc.so.2 (0x485a8000)
        libgcc.so.1 => /shlib/libgcc.so.1 (0x48674000)
        libz.so => /usr/lib/libz.so (0x48681000)
        libpng.so.2 => /weblib/local/lib/libpng.so.2 (0x48690000)

The shared lib in lib/php/20010901-debug only links itself and the standard c libs:
$ ldd libgd.so
        ./libgd.so => ./libgd.so (0x4805b000)
        libc.so.2 => /shlib/libc.so.2 (0x48070000)
        libgcc.so.1 => /shlib/libgcc.so.1 (0x4813c000)

If I compare this to pg for instance, it is not in the php4 lib and it shows proper linking with the pg native libs:
$ ldd libpgsql.so
        ./libpgsql.so => ./libpgsql.so (0x4805b000)
        libpq.so.2 => /pgsql/lib/libpq.so.2 (0x48069000)
        libc.so.2 => /shlib/libc.so.2 (0x48079000)
        libgcc.so.1 => /shlib/libgcc.so.1 (0x48145000)
        libssl.so.0.9.6 => /weblib/local/lib/libssl.so.0.9.6 (0x48152000)
        libcrypto.so.0.9.6 => /weblib/local/lib/libcrypto.so.0.9.6 (0x48208000)
        libdl.so => /shlib/libdl.so (0x482ca000)

The reason I need a custom Makefile for gd, is because the standard gd library Makefile, creates a libgd.so, which generates a crash on startup of apache, and ldd on this library, doesn't even detect any dependancies, nor does it give 'statically linked' - just a blank line.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

[2002-06-28 05:40 UTC] sniper@php.net

Is this still happening with latest CVS checkout?

[2002-06-28 06:14 UTC] msopacua at idg dot nl

Well,
over time this started to happen with other extensions as well. So right now, I'm not even trying to compile a dynamic version anymore.

I'll do this over the weekend though. Would you prefer to know the bundled gd results or the external?

[2002-06-28 06:19 UTC] sniper@php.net

Ah, I missed that 'shared' point here. Reclassified..
If it happens with other extensions too..well, then
it's bit bigger issue.

btw. Why would you send apache a 'SIGUSR1'? And SIGHUP
hasn't ever worked when PHP is compiled as DSO, you should
stop/start instead of 'restart'. 

--Jani

[2002-06-28 06:37 UTC] msopacua at idg dot nl

SIGUSR1: to keep status info, for /server-status and not to piss off users, downloading stuff around midnight, while we are rotating the logs.

SIGHUP normally works ok, when php is compiled as DSO. And 'stop and start' is just not an option.

I have two hunches, developed by trying about every compilation scheme I could think of:
1) non-libtool compiled libs are problematic, openssl being the one that comes to mind instantly.

2) php as a dso is ok, even shared modules, as long as those shared modules don't contain other shared modules, which are not part of the 'extension', like gd, needing libjpeg/libz or  libcurl needing openssl. Strangely enough, sablot/expat combination is fine again.

[2002-07-07 21:50 UTC] sniper@php.net

Just a status update: does this happen with today's CVS checkout?

[2002-07-24 17:42 UTC] msopacua at idg dot nl

Tried again today. Problem persists.

Updated version.

[2002-09-30 20:44 UTC] iliaa@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

[2002-10-16 08:03 UTC] msopacua@php.net

Sorry - but I can't retry:
mdev@valygar.idg.nl ~/_src/php4-200210160300
$ gmake install
Installing PHP SAPI module
[activating module `php4' in /apache/conf/httpd.conf]
cp libs/libphp4.so /apache/libexec/libphp4.so
cp: libs/libphp4.so: No such file or directory
apxs:Break: Command failed with rc=1
gmake: *** [install-sapi] Error 1

mdev@valygar.idg.nl ~/_src/php4-200210160300
$ ls libs
libphp4.a       libphp4.la

mdev@valygar.idg.nl ~/_src/php4-200210160300
$ cat configure-cmd.sh
#!/bin/sh

./configure \
        --prefix=/php \
        --with-mysql=/weblib/local \
        --with-zlib-dir=/usr \
        --with-gd=php \
        --with-jpeg-dir=/weblib/local \
        --with-freetype-dir=/weblib/local \
        --enable-sockets \
        --with-apxs=/apache/bin/apxs

[2002-10-16 14:17 UTC] msopacua@php.net

Ok - user error. Jpeg has a libtool from the stoneages. Replacing that with a 1.4 release, correctly builds a shared version, which will then create libs/libphp4.so.

However - the problem with the signals remains.

[2002-10-16 21:07 UTC] sniper@php.net

And I guess you have shared extensions loaded in your php.ini when this happens? And if not, it works fine?

I tried on my machine (linux :) these:

./apachectl restart
./apachectl graceful

And both worked fine. I don't have any shared extensions in my php.ini

[2002-10-17 02:53 UTC] msopacua@php.net

Nope - wrong guess :-).
It is not just GD. When I removed GD from the below configuration, it still didn't work.
The following works correctly:
./configure \
        --prefix=/php \
        --disable-mbstring \
        --with-zlib=/usr \
        --with-zlib-dir=/usr \
        --with-apxs=/apache/bin/apxs

I'll use --disable-all and make a list of extensions that have/expose these problems. Maybe there's a common factor.

[2002-10-17 04:06 UTC] msopacua@php.net

Ok, just a quick status update:
The 'old' gd still exposes the problem. The bundled gd does not, in contradiction to my previous report. This was actually caused because, the bundled MySQL lib, is OK, BUT an external mysql lib (3.23.53) also exposes the problem.

Since I tried both, with the same zlib option, and both MySQL libs have been linked with the same zlib, it cannot be a zlib problem.

[2002-10-20 10:33 UTC] msopacua@php.net

I've created a php script, to test this :-).
Output is as follows:
============================================================
 RESULTS SIGTEST
------------------------------------------------------------
                           Mysql bundled: OK
                          Mysql external: NOT OK
                         Aspell external: NOT OK
                              GD bundled: OK
                             XML Bundled: OK
                            XML external: OK
                           XSLT external: NOT OK
                          Iconv external: OK
                   GNU gettext, external: OK
                        OpenSSL external: NOT OK
              Curl external, without SSL: NOT OK
                 Curl external, with SSL: NOT OK
============================================================

The commonalities seem to be, that the modules which fail, load more than 1 external shared library. MySQL loads zlib, Aspell loads several aspell libs, OpenSSL has -lssl and -lcrypt and curl loads -lssl ("Curl external, without SSL", simply means --with-openssl was not given. -lssl and -lcrypt are still linked in).
The only exceptions to this, are the Bundled GD, which is compiled with libjpeg, libpng, libz and libfreetype and the Bundled MySQL.

The common factors with these is, that libphp4.so doesn't call libgd/libmysqlclient, but has this code built in.

Concluding this goes wrong when there are 2 levels of dynamic loading:
apache -> libphp4 -> libfoo -> libbar

It reminded me of bug in BSD/OS 4.x series, on how symbols are resolved:
http://www.geocrawler.com/archives/3/127/1999/5/0/1795873/

Can somebody experience in this, take a look if it makes any sense in comparison to what PHP is doing?

[2003-07-10 18:33 UTC] sniper@php.net

Not sure whether this has nothing to do with this bug,
but take a look in Apache 1.3.27 sources,  src/main/http_main.c file and look for WORKAROUND_SOLARIS_BUG. You could try defining that and recompile apache (make clean && make) to see if it has any effect?

[2003-07-21 12:23 UTC] msopacua at idg dot nl

Thanx Jani, but it's not the cause. I've tried it regardless and it doesn't help.

It's defenitely a linker issue, although a ktrace doesn't reveal much info.

[2003-08-13 23:23 UTC] sniper@php.net

I tried searching for similar issues in other projects
and found this document:
http://www.pix.net/software/bsdos/elf_faq.html#How%20do%20I%20build%20a%20program%20that%20dynamically%20loads%20a%20shared%20object%20(with%20dlopen(3)

Basically what I read about BSDi's support for dlopen() was
not really promising. 

Could you try compiling PHP as static module in Apache to
see if the problem really is the "double" dlopen:

  Apache-dlopen(PHP-dlopen(curl.so))

(when PHP is build as static module, the first dlopen() is nuked of course :)

[2003-08-18 19:44 UTC] sniper@php.net

Melvyn, your comment got lost due to that db corruption we had..can you please re-add it?

[2003-08-26 00:57 UTC] sniper@php.net

And most likely nothing we can do about anyway. :)

	php.net \| support \| documentation \| report a bug \| advanced search \| search howto \| statistics \| random bug \| login
go to bug id or search bugs for


Copyright © 2001-2024 The PHP Group All rights reserved.	Last updated: Sat Dec 21 13:01:31 2024 UTC