Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Command line scripting broken since version 5.2.10 of php

3 views
Skip to first unread message

Henrik Carlqvist

unread,
Nov 7, 2009, 7:21:29 PM11/7/09
to
Php can be used not only with web servers but also for stand alone
command line scripts. However, this functionality seems broken since
version 5.2.10. Maybe my problem in part or fully depends on my installed
platform which is Slackware 12.0. Maybe the problem is not php itself but
how php was built. However, if the error lies within Slackware or how the
Slackware packages were built it would be nice to know how it could be
fixed so a useful bug report could be written.

With the latest php patches for Slackware 12.0 such stand
alone command line scripts gives an annoying warning. Example with a
simple script:

hello.php:
-8<-----------------------------------------
#!/usr/bin/php
<?php

echo "Hello World\n";

?>
-8<-----------------------------------------

$ ./hello.php
Hello World
$ sudo upgradepkg php-5.2.10-i486-1_slack12.0.tgz
$ ./hello.php
PHP Warning: PHP Startup: mm_create(0, /var/lib/php/session_mm_cli10395)
failed, err mm:core: failed to open semaphore file (Permission denied) in
Unknown on line 0
Hello World
$ sudo upgradepkg php-5.2.9-i486-1_slack12.0.tgz
$ ./hello.php
Hello World
$

So reverting back to the patch with version 5.2.9 of php cures the
problem. Upgrading to the patches php-5.2.10-i486-1_slack12.0.tgz or any
more recent version of php brings the problem back.

But where did the problem come from? Some strace with the
problematic 5.2.10:

....
shmctl(1508868104, IPC_64|IPC_SET, 0xbf9d2cc8) = 0
shmctl(1508868104, IPC_64|IPC_RMID, 0) = 0
unlink("/var/lib/php/session_mm_cli10395.sem") = -1 EACCES (Permission denied)
open("/var/lib/php/session_mm_cli10395.sem", O_RDWR|O_CREAT|O_EXCL, 0600) = -1
EACCES (Permission denied)
shmdt(0xb4d48000) = 0
shmctl(1508868104, IPC_64|IPC_RMID, 0) = -1 EINVAL (Invalid argument)
unlink("/var/lib/php/session_mm_cli10395.sem") = -1 EACCES (Permission denied)
write(2, "PHP Warning: PHP Startup: mm_cr"..., 166PHP Warning: PHP Startup:
mm_create(0, /var/lib/php/session_mm_cli10395) failed, err mm:core: failed to
open semaphore file (Permission denied) in Unknown on line 0
) = 166
brk(0x84b3000) = 0x84b3000
brk(0x84d4000) = 0x84d4000
open("/etc/nsswitch.conf", O_RDONLY) = 3
....

A normal user does not have acces to /var/lib/php which is owned by apache.
However, an strace of php 5.2.9 shows the same problem, but 5.2.9 does not
give any warning:

....
shmctl(1508933640, IPC_64|IPC_SET, 0xbfafbde8) = 0
shmctl(1508933640, IPC_64|IPC_RMID, 0) = 0
unlink("/var/lib/php/session_mm_cli10395.sem") = -1 EACCES (Permission denied)
open("/var/lib/php/session_mm_cli10395.sem", O_RDWR|O_CREAT|O_EXCL, 0600) = -1
EACCES (Permission denied)
shmdt(0xb4d4f000) = 0
shmctl(1508933640, IPC_64|IPC_RMID, 0) = -1 EINVAL (Invalid argument)
unlink("/var/lib/php/session_mm_cli10395.sem") = -1 EACCES (Permission denied)
open("/etc/nsswitch.conf", O_RDONLY) = 3
....

Despite the problem with the semaphore file php 5.2.9 seems to work fine with
standalone scripts so on my systems I have now chosen to revert back to 5.2.9.
I don't know why 5.2.10 gives this kind of unwanted warnings, both versions
seem to get their configurations from the same file:

open("/usr/bin/php-cli.ini", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/httpd/php-cli.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/bin/php.ini", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/httpd/php.ini", O_RDONLY) = 3

And that file looks the same with the following line controlling warning
levels:

error_reporting = E_ALL

Has anyone else seen this problem with php 5.2.10 or php 5.2.11? Do you
know of any better workaround than reverting to 5.2.9?

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc3(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

Message has been deleted

Henrik Carlqvist

unread,
Nov 7, 2009, 9:15:02 PM11/7/09
to
ljb <ljb...@pobox.com.nospam> wrote:
> Simple work-around is to make a config file just for the CLI and move the
> session store directory. Wherever your php.ini lives, make php-cli.ini
> and it needs to have: session.save_path="/tmp"

Thanks, that seems like the solution I prefer for now.

0 new messages