Lower memory limit for php5

Bug #148871 reported by Soren Hansen
Affects Status Importance Assigned to Milestone
php5 (Ubuntu)
Soren Hansen

Bug Description

Binary package hint: php5

History: Up until (and including) Edgy, we had a memory_limit for all the php5 variants (libapache2-mod-php5, php5-cli, php5-cgi) of 8MB. Early in the Feisty development cycle, Debian changed the memory_limit for php5-cli to 32MB by doing a s/8M/32M/g on the template for php5-cli's php.ini. We followed suit, but soon after, upstream (i.e. php) changed the default to 128MB. This meant that 128MB was now turned into 1232MB (due to s/8M/32M/) for php.cli, and the limit for the other variant was set to 128M. In Ubuntu we fixed the broken memory_limit mangling (some time during the gutsy dev cycle), so all php5 variants are now have a memory_limit of 128M in Ubuntu.

However, 128M is a *very* high limit for just a single php script. It turns out that php (upstream) used to not enforce memory_limit at all by default, but they do now. So from their perspective, the 128M memory_limit is a conservative choice, actually. We (Ubuntu and Debian), however, have had the limit at 8M for quite a few years, IIRC, and I think it should stay that way. So, for Hardy, we should lower the memory_limit for libapache2-mod-php5 and php5-cgi to 8M and php5-cli to 32M. This bug is here to remind us to do so.

Seeing as Feisty had 1232M for -cli and 128M for the others, and gutsy had 128M for all of them for most of the development cycle, making this change now (two weeks before gutsy releases) is likely to cause problems for anyone who needs a memory_limit > 8M.

Related branches

CVE References

Soren Hansen (soren)
Changed in php5:
assignee: nobody → shawarma
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Daniel Hahler (blueyed) wrote :

Attention: we should not go back to 8M, which would be too low, because the reporting of used memory has changed also. From the changelog of 5.2.0: "Increased default memory limit to 16 megabytes to accommodate for a more accurate memory utilization measurement."

Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (5.2 KiB)

This bug was fixed in the package php5 - 5.2.4-2ubuntu1

php5 (5.2.4-2ubuntu1) hardy; urgency=low

  * Merge from Debian unstable (LP: #176011). Remaining Ubuntu changes:
    - debian/control, debian/rules: Disable a few build dependencies and
      accompanying binary packages which we do not want to support in main:
      + firebird2-dev/php5-interbase (we have a separate php-interbase source)
      + libc-client-dev/php5-imap (we have a separate php-imap source)
      + libmcrypt-dev/php5-mcrypt (separate php-mcrypt source)
    - debian/rules: Correctly mangle PHP5_* macros for lpia
    - debian/control: DebianMaintainerField
  * Builds php5-gmp (LP: #176013)
  * Fixes sybase_ct for MS SQL (LP: #21995)
  * New Ubuntu changes:
    - debian/rules: use 32M memory_limit for CLI and 16M for cgi/libapache
      (LP: #148871)
    - debian/control, debian/rules: Configure CLI with --with-libedit for
      readline support again, now that the libedit issue is fixed.
      Extended debian/patches/027-readline_is_editline.patch (LP: #124846)
    - Force build against db4.4 (by ignoring db4.5 if it is installed),
      debian/patches/use-specific-libdb-version.patch (LP: #165247)

php5 (5.2.4-2) unstable; urgency=low

  [ sean finney ]
  * for posterity revised previous changelog to reference the CVE id's
    of security issues resolved by the latest upstream release.
  * lintian: use debian/compat instead of DH_COMPAT in debian/rules.
  * lintian: use source:Version and binary:Version where appropriate,
    instead of Source-Version
  * lintian: remove a couple pieces of cruft in the changelog that were causing
    false-postive wrong-bug-number-in-closes, but were generally useless

  [ Raphael Geissert ]
  * Using test-results.txt as a target
  * cronjob now checks for existance of /usr/lib/php5/maxlifetime (Closes: #439286)
  * Fixed memory limit of 1232M in php.ini for cli (Closes: #440624)
  * Build the interbase extension using firebird2.0-dev (Closes: #433736)
  * Unapply patches with debian/rules clean

  [ Steve Langasek ]
  * Don't patch configure or php_config.h.in in suhosin.patch, as these are
    auto-generated and including them in the patch results in a race
    condition for the necessary build-time regeneration. Thanks to Daniel
    Schepler for reporting, and to Damyan Ivanov for helping to sort out the
    fix. Closes: #443637.
  * Also remove the modified auto-generated files in the clean target,
    which triggers a warning about disappearing files when building the
    source package but avoids carrying irrelevant diffs to these files
    in the Debian diff.
  * Now that the testsuite is being run at build time, test failures cause
    a bunch of junk files to be left around in the Debian diff. So clean up
    several false-positive failures:
    - 052-phpinfo_no_configure.patch: we're patching the output of phpinfo(),
      so patch the test as well
    - fix_broken_upstream_tests.patch: use a local directory for tests that
      use sessions, skip the phpinfo test after all because it doesn't appear
      to be compatible with current testsuite behavior, and disable the
      moneyformat test if...


Changed in php5:
status: Triaged → Fix Released
Revision history for this message
Krešo Kunjas (deresh) wrote :

but still, in recomended php.ini memory limit is still 128M.

Most of the modern php aplications require higher memory limit than 16M that is now default in ubuntu. This may be a problem for some less experienced php developers that choose ubuntu as dev platform.

for them php is broken because their application doesn't work on ubuntu and does work on for example windows.

i to think that 128M is a bit much but i think 32M is a minumum nowdays.

i'm using some of then new php5 RAD tools like Propel, Doctrine, Cake, Symfony and their memory requirement is above default 16M.

Revision history for this message
Ondřej Surý (ondrej) wrote :

Is it really that hard to change configuration value in one config file? I don't think so.

16M is safe default for web application if you don't want php to eat all your memory.

Nevertheless this bug is about having 1232M memory limit in CLI and not about raising memory limit. If you wish you can open new wishlist bug for this issue, but I don't think it should be changed nowadays.

Revision history for this message
Krešo Kunjas (deresh) wrote :

no it isn't hard, but that's not the issue here, but for some more inexperienced users this could be a problem.

Revision history for this message
Daniel Hahler (blueyed) wrote :

I've just created a new wishlist bug for a better/increased default: bug 196806.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers