ID: 13595
Comment by: shawn dot m at microcore dot net
Reported By: plafundum at yahoo dot com
Status: Closed
Bug Type: Session related
Operating System: Debian Sid
PHP Version: 4.0.6
New Comment:
kernel.shmmax=63484230
If you look at the changelog for libmm, it say's right in it.
*
We've made this configurable now, defaulting to 32MB, but before
you increase it note that some applications might just plainly
allocate a maximum sized segment, like the php interpreter does
when it calls mm_create with size=0.
*
What does this mean? mm will error since php wants 64 meg, and shmmax
is setup by default of only 32 meg.
It's a php problem, php needs to be fixed to where it dosn't do
this...
SuSE 8.1 Pro
mod_php4-core-4.2.2-168
mod_php4-4.2.2-168
apache-1.3.26-57
mm-1.2.1-28
Previous Comments:
------------------------------------------------------------------------
[2003-02-18 04:49:38] wjblack at yahoo dot com
Boy, did I feel silly once I got this working.
libmm seems to puke heavily if you have no swap enabled, claiming no
memory. I was getting ENOMEM errors, despite upping shmmax (to 64MB,
just to be sure) and having 120MB free core. As soon as I ran swapon
/dev/hda2 and retried, everything was fine.
My setup was Debian Woody on a Cobalt Raq 3 (kernel 2.4.18).
------------------------------------------------------------------------
[2003-02-04 09:06:25] stevenbalthazor at hotmail dot com
This bug has been fixed in the php-4.1.2-7.3.6 distributed by redhat in
rpm form, sort of. When php is run from the commandline (e.g.
/usr/bin/php -q something.php) php creates a file:
/tmp/session_mm_cgi###.sem where ### is the uid of the user running the
script. This bug was fixed by making each individual user get their
own .sem file.
The problem I have and which others may have is if you run multiple
scripts at the same time from a cron job with the same user you will
get the error: "PHP Fatal error: Unable to start session mm module in
Unknown on line 0". This is basically the same problem that was
causing this bug but slightly different. This bug was fixed by giving
each user its own .sem file; however the case where a user would need
more than 1 .sem file was not fixed. My primative understanding of how
this works is that the first script creates the session_mm_cgi###.sem
file; then when the second script comes along it can't create the file
because the file is already created. It would appear that the path
used for the session_mm_cgi###.sem is the session.save_path specified
in the php.ini file; however changing this value in the script using
either ini_set or session_save_path has no impact on the location of
the session_mm_cgi###.sem file.
Two workarounds exist that I have figured out if you must run multiple
php commandline scripts at the same time:
1. run the scripts as different users; that way you will get different
session_mm_cgi###.sem files
2. use a custom php.ini file for each script and specify a different
session.save_path in each php.ini file
It would be nice if the path where the mm_cgi###.sem file was saved
could be set at run time but there are probably dynamics at work which
prevent this.
You can see what session_mm_cgi###.sem file is created by running your
script:
strace -e trace=file -o output /usr/bin/php -q something.php
then open the created output file and do a search for sem
------------------------------------------------------------------------
[2003-01-27 15:26:56] wouter at nucleus dot be
Hello,
I'm still having problems with this.
PHP 4.1.2
Redhat 7.2
latest updates and fixes from Redhat are installed
Already checkec everything mentioned above, nothing works for me. I
don't get it all the time. It happens only when PHP is used at the
command line or in cronjobs...
Already searched google etc, no solution found so far.
Thanks.
------------------------------------------------------------------------
[2002-08-09 14:24:32] kasper at 303 dot nu
I'm also using debian sid, and the same happens. PHP 4.2.1, nothing in
/tmp. The first time it happened I removed php4, and re-installed it,
and the problem was gone. And when it occured 15 minutes ago I tried
removing php4-cgi, which I also had installed, and the problem is gone
now. So there might be a kind of clash between php4 and php4-cgi?
But anyway, it would be very nice to have a more descriptive output
from php4...
------------------------------------------------------------------------
[2002-07-30 22:49:50] jal at jal dot org
So, following this thread, I'm still not having any luck.
I'm running debian-woodie, and upgraded to the 4.2.1 package for it. I
checked my php.ini for weird paths, checked /tmp and (because someone
mentioned it) /etc for session_mm files, and the problem still
persists. Here's what I get out of strace:
open("/usr/lib/apache/1.3/libphp4.so", O_RDONLY) = 4
[...]
open("/usr/lib/libmm.so.11", O_RDONLY) = 4
[...]
open("./php.ini", O_RDONLY|O_LARGEFILE) = 5
getcwd("/etc/php4/apache", 4096) = 17
lstat("/etc/php4/apache/php.ini", {st_mode=S_IFREG|0644, st_size=26777,
...}) = 0
open("/etc/ld.so.cache", O_RDONLY) = 5
open("/lib/libnss_db.so.2", O_RDONLY) = 5
open("/lib/libnss_files.so.2", O_RDONLY) = 5
open("/usr/lib/libdb3.so.3", O_RDONLY) = 5
open("/var/lib/misc/protocols.db", O_RDWR|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
open("/var/lib/misc/protocols.db", O_RDONLY|O_LARGEFILE) = -1 ENOENT
(No such file or directory)
open("/etc/protocols", O_RDONLY) = 5
open("/var/lib/misc/protocols.db", O_RDWR|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
open("/var/lib/misc/protocols.db", O_RDONLY|O_LARGEFILE) = -1 ENOENT
(No such file or directory)
open("/etc/protocols", O_RDONLY) = 5
unlink("/tmp/session_mm_apache0.sem") = -1 ENOENT (No such file or
directory)
I left in some cruft, because I have no idea what's going on.
If anyone has any thoughts...
-j
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/13595
--
Edit this bug report at http://bugs.php.net/?id=13595&edit=1
