> 1. PROC_NAMES should be defined as proc_names or used as PROC_NAMES
(inconsistent case)

Good catch, fixed.

> 2. printf "%s:%s:%s\n" "$save_path" "$gc_maxlifetime" has 2 arguments but the 
> definition takes 3, I would simplify it to this:
echo "$save_path:$gc_maxlifetime"

Good catch, fixed.

> 3. If apache2filter is installed, $proc_names will contains "apache2
apache2", which, when passed to pidof, will return all the PIDs twice,
so I've uniq'd them by delimiting them with \n and using "sort -u |
xargs pidof".

apache2 and apache2filter cannot be co-installed.

> 4. I'm not entirely sure how "cgi" method would work, but I suppose it means 
> the php command is running on the system by itself, so I've used the 
> following bit to discover that pidof requires "php", not "php5" since that is 
> the real name of the process:
php -r 'sleep(60);echo "Done";' &

The default package config points to /usr/lib/cgi-bin/php5

> 5. We've been using HHVM for a few years for one of our products, and
I could easily add support for that ("hhvm --php -r"...), but things
seem a bit out of order there, mainly, the php.ini is in /etc/hhvm
instead of /etc/php5/hhvm

It's up to the HHVM packages to sort this out. I doubt they will depend
on php5-common at all. So I am skipping changes related to HHVM. It's
start to feel like bikesheding.

> 1. Will PHP 5.6 be the default in Ubuntu 14.10?

Nope, there was a separate bug report about this, and my recommendation
was to stay with 5.5.<latest>

> 2. Will these updated be present in 14.04.x?
> 3. Will these changes be present in PHP 5.5.x?

I will merge these changes to master-5.5 branch in Debian git repo (and
my PPA ppa:ondrej/php5). It's up to Ubuntu maintainer (@racb) to pick
that or not.

> 4. Are you going to be the Debian-side maintainer for the Debian-repo
HHVM package?

Nope, there are some Debian folks from fcbk who wanted to do the work.

> Since the name php5 is ambiguous with /usr/bin/php5, we can pass the
full path to the executable, "/usr/lib/cgi-bin/php5", to pidof.

There's no need to do so. The worst case scenario is when /usr/bin/php5
session would get touched as well.

> it's a lot less expensive since PHP doesn't need to start up with all
of its modules 3 times for each SAPI.

Again it feels like over-optimizing, but I have merged a variant of
this.

> session.save_path can be empty and empty string.

It cannot be an empty string in Debian, since we patch the sources to
have a default to point to /var/lib/php5/sessions/

Ondrej

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1356113

Title:
  PHP5 session clean cron job causes OOM

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1356113/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to