Bug #14870 Updated: GD breaks SIGUSR1 and SIGHUP

From: 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

« previous php.bugs (#13460) next »