ID: 13595
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Session related
Operating System: Debian Sid
PHP Version: 4.0.6
New Comment:
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
Previous Comments:
------------------------------------------------------------------------
[2003-01-27 15:26:56] [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
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] [EMAIL PROTECTED]
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
------------------------------------------------------------------------
[2002-06-18 09:19:23] [EMAIL PROTECTED]
Hi y'all,
This 'bug' is solved long time ago.
1 Upgrade to php 4.2.1
2 see /tmp for a session_mm.sem and remove it.
------------------------------------------------------------------------
[2002-06-18 04:00:23] [EMAIL PROTECTED]
This is most likely fixed in the latest version. Please reopen if PHP
4.2.1 doesn't fix the problem.
------------------------------------------------------------------------
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
