So it's not a bug in PHP. Thanks & Closing...

I'm seeing this problem on Slackware 8.0, when upgrading 
from the original mod_php.tgz package (PHP 4.0.5) to the 
updated version (PHP 4.1.2).

I already checked, there is no 'session_mm.sem' file to 
remove (stopping apache automatically removes the file).  
So my question is, what is going on, and how do I fix it?

Can you try a snapshot from snaps.php.net? It might be fixed, if not we need feedback on that branch anyways.

regards,
Derick

An other alternative would be to use use 'strace' on the apache process (make sure you start apache with -X switch), maybe you can gather where it has failed, e.g.

strace -e trace=file -o output /usr/sbin/apache -X

and see in file 'output' what fails.

Thanks to mfischer@php.net, I found the problem using strace.  I had 'session.save_path' set to '/dev/null'.  

Why does 4.1.2 not handle this gracefully like 4.0.5, and is there any way to get a more helpful error message in this case?

In case you're interested in the exact errors, I've included the errors from the strace below:

unlink("/dev/null/session_mm_apache0.sem") = -1 ENOTDIR (Not a directory)
open("/dev/null/session_mm_apache0.sem", O_RDWR|O_CREAT, 0600) = -1 ENOTDIR (Not a directory)
unlink("/dev/null/session_mm_apache0.sem") = -1 ENOTDIR (Not a directory)

Ah .. interesting ...

Did you set the save path explicitely to '/dev/null' ? (And if so, why?)

All I know at the moment is that serveral session issues are adressed at the moment. Marking this as analyzed until one of our session gurus can answer this more accurat.

Yes, I had the save path explicitly set to '/dev/null' in php.ini since I first installed version 4.0.5;  I haven't been using sessions, so I wouldn't have noticed if sessions were not working.  However, after the upgrade, I sure noticed something was wrong, since apache wouldn't start.

As for why it was setup that way... I have the server setup so each virtual host uses its own 'tmp' directory, and as I recall, I didn't want PHP to store anything in '/tmp'.

I'm experiencing a similar problem after updating to php 4.1.0-104 (from the SUSE 8.0 Distro). Whenever i try to call php as a cgi ftp server i now get this:

Content-type: text/html

PHP Fatal error:  Unable to start session mm module in Unknown on line 0 

i did a locate .sem and it showed one file at /var/lib/httpd/mm.1257.sem. Deleting that didn't help.

The ftp loader worked perfect with the previous version (4.0something), and the trouble with the new version appears only when calling php as cgi.

Any ideas?

Sorry,
i forgot to mention my settings:
session handler is 'files', location for those /tmp- my php.ini is completely unchanged from the defaults sessionwise.

I get 

fstat64(3, {st_mode=S_IFREG|0644, st_size=1748, ...}) = 0
unlink("/tmp/session_mm_apache0.sem")   = -1 ENOENT (No such file or directory)

before it dies, any idea? (using debian linux)

This is most likely fixed in the latest version. Please reopen if PHP 4.2.1 doesn't fix the problem.

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.

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

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...

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.

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

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).

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