Bug #14870 Updated: GD breaks SIGUSR1 and SIGHUP
| From: | sniper@php.net | Date: | Mon, 08 Jul 2002 01:50:17 +0000 |
| Subject: | Bug #14870 Updated: GD breaks SIGUSR1 and SIGHUP | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-13460@lists.php.net to get a copy of this message | ||
ID: 14870
Updated by: sniper@php.net
Reported By: msopacua@idg.nl
-Status: Open
+Status: Feedback
Bug Type: Dynamic loading
Operating System: BSDi 4.x
PHP Version: 4.0CVS-2002-01-05
New Comment:
Just a status update: does this happen with today's CVS checkout?
Previous Comments:
------------------------------------------------------------------------
[2002-06-28 06:37:38] msopacua@idg.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-06-28 06:19:48] 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:14:39] msopacua@idg.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 05:40:55] sniper@php.net
Is this still happening with latest CVS checkout?
------------------------------------------------------------------------
[2002-01-05 09:00:14] msopacua@idg.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.
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=14870&edit=1