Ticket #228 (closed defect: wontfix)

Opened 4 years ago

Last modified 10 months ago

var cache doesn't work for php cli

Reported by: binBASH Owned by: moo
Priority: critical Milestone: undecided
Component: cacher Version: 1.3.1
Keywords: Cc: vitalif@…
Blocked By: PHP Version: 5.3.3
Application: Need User Feedback: no
Other Exts: SAPI: Others
Probability: Always Blocking:

Description

I'm getting notices like this:
PHP Warning: xcache_isset(): xcache.var_size is either 0 or too small to enable var data caching in /srv/httpd/www.livenue.ch

Tried to adjust the var cache variables, but nothing changes.
In phpinfo it says xcache is enabled.

/opt/www/php/bin/php -v output shows:
PHP 5.3.0 (cli) (built: Sep 17 2009 15:25:16)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies

with XCache v1.3.0, Copyright (c) 2005-2009, by mOo

I dunno if the opcode cacher works as well.
When I run xcache admin scripts with php cli the tables are empty.

Tried to do a print_r($cacheinfos); but the array was empty.

uname -a output:
Linux stopovr 2.6.18-128.2.1.el5.028stab064.7 #1 SMP Wed Aug 26 15:47:17 MSD 2009 x86_64 x86_64 x86_64 GNU/Linux

Change History

Changed 4 years ago by moo

  • status changed from new to closed
  • resolution set to invalid

cli is not supported by XCache. admin scripts is run from httpserver/htdocs, not from cli

Changed 3 years ago by laph

  • status changed from closed to reopened
  • resolution invalid deleted

Is there any chance to have a XCache Version that works with CLI in the (not so far) future?
We've a Zend Framework based project using Zend's Caching classes and would like to use XCache as (so-called) Backend.
But since we (have to) use our Stuff (Models) in CLI and FCGI Mode, we cannot use XCache as backend for Zend_Cache. Our app loads (and parses) dozends of XML-Files which are stored in Memcached after processing.
Well, I'd prefer XCache's Variable Cache over Memcached, since we use the Opcode Cacher anyway.

Changed 3 years ago by JayPea

I'd vote for this, too.
It worked in xcache 1.2.2 and php 5.2.6
now in xcache 1.3.0 with php 5.3.2 it doesn't work anymore.

I need this for unit-testing (phpunit) my applications which use xcache as backend.
how would i test my xcache-backend without being able to use xcache on the CLI ?
i can't even use hudson build-server since it calles phpunit on the commandline.

Changed 2 years ago by vitalif

  • cc vitalif@… added

+1, I also confirm this issue.

Debian squeeze, php 5.3.2-2, xcache 1.3.0-7.

If cli is not supported by XCache, then XCache should print "CLI IS NOT SUPPORTED BY XCACHE", and should not give strange errors like "xcache.var_size is either 0 or too small to enable var data caching" despite of it is not really 0.

Changed 2 years ago by moo

  • status changed from reopened to closed
  • resolution set to wontfix

error is not printed because most ppl tends to use same single php.ini for all sapi and most ppl don't know if and how they can separate php ini for each sapi

Changed 22 months ago by georgyo

  • status changed from closed to reopened
  • version changed from 1.3.0 to 1.3.1
  • resolution wontfix deleted

I am going to re-open this ticket because I think the message should not be printed at all for the CLI, or at least have some way to disable it, besides a blind 2>/dev/null.

Here is a case example of why. Ubuntu drops the xcache.ini into /etc/php5/conf.d/. This directory is sym-linked to apache2, cli, cgi, and fpm. This is desired case for almost everything. It allows you to easily load modules, and modified their config in the main php.ini file if necessary.

Mediawiki has a series of maintenance scripts, that are extremely useful for maintaining it. However, because of this error, all the scripts just spam the warning repeatedly; making the output of the script completely unreadable. Again, while it is possible to just redirect this errors, it is not ideal.

OK, so now I could recreate this conf.d folder for the cli, and now have to manage other wise universal config in two places for an error that is cryptic and incorrect. Also this error doesn't even affect the code in anyway, xcache just passes. Also, other xcache functions ARE working. So, to keep those enabled, I would need to rewrite all of mediawiki caching functions to test to see if both xcache and cli are being used.

Also, it should be noted again that error was introduced in 1.3.

At the very least the error should output something remotely correct for the CLI. It should also be downgraded from a WARNING message to an NOTICE message. A NOTICE is the more closely fits the error levels as described by:  http://www.php.net/manual/en/errorfunc.constants.php

I hope you will at least consider some of this.

Changed 18 months ago by ckujau

  • phpversion changed from 5.3.0 to 5.3.3

+1 from me: if xcache is not available for php-cli, so be it. But listing it in phpinfo() and then complaining that xcache.var_size is set to 0 when used seems to be the wrong approach, IHMO.

$ php -r 'phpinfo();' | grep var.size
xcache.var_size => 256K => 256K

$ php -v
PHP 5.3.3-7+squeeze3 with Suhosin-Patch (cli) (built: Jun 28 2011 08:24:40)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies

with XCache v1.3.0, Copyright (c) 2005-2009, by mOo
with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins? GmbH

Changed 14 months ago by moo

  • milestone changed from 1.3.3 to undecided

it's up to end user to have separate ini for cli and other php sapi. simply slient everything in xcache+cli confuse some user trying to do it

Changed 10 months ago by moo

  • status changed from reopened to closed
  • resolution set to wontfix

XCache is useless with CLI. What you wanted is to share between different group of PHP which is unsupported by XCache. memcached come in handy for this case

Note: See TracTickets for help on using tickets.