That does seem more appropriate than putting all the SAPI methods in
php-common. The HHVM guys (Paul Tarjan, etc) gave me the green light to
do the session cleanup bit, so I'll take care of it once we settle on a
script.
Wouldn't /usr/lib/php5/sapi/sapi be a better location for scripts?
--
You
Btw, if we go the route of separate sapi folders inside
/usr/lib/php5/sapi/ we should also move php5-fpm-checkconf into
/usr/lib/php5/sapi/fpm/ (I used fpm instead of php5-fpm here since
that how it is in /etc/php5/).
--
You received this bug notification because you are a member of Ubuntu
I prefer option #1 - sourcing the sessionclean scripts from
/usr/lib/php5/sapi/* or perhaps /usr/lib/php5/sapi/sapi/sessionclean
so we can make room for more sapi-specific scripts should the need
arise.
If we keep the logic in php-common, a con is that we can't use it for HHVM (not
that HHVM
That does seem more appropriate than putting all the SAPI methods in
php-common. The HHVM guys (Paul Tarjan, etc) gave me the green light to
do the session cleanup bit, so I'll take care of it once we settle on a
script.
Wouldn't /usr/lib/php5/sapi/sapi be a better location for scripts?
--
You
Btw, if we go the route of separate sapi folders inside
/usr/lib/php5/sapi/ we should also move php5-fpm-checkconf into
/usr/lib/php5/sapi/fpm/ (I used fpm instead of php5-fpm here since
that how it is in /etc/php5/).
--
You received this bug notification because you are a member of Ubuntu
Bugs,
I prefer option #1 - sourcing the sessionclean scripts from
/usr/lib/php5/sapi/* or perhaps /usr/lib/php5/sapi/sapi/sessionclean
so we can make room for more sapi-specific scripts should the need
arise.
If we keep the logic in php-common, a con is that we can't use it for HHVM (not
that HHVM
Indeed, I think we've passed the 80/20 mark on this one. I'll test your
updated one today and we should be good.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to php5 in Ubuntu.
https://bugs.launchpad.net/bugs/1356113
Title:
PHP5
Issue on line 8:
echo -e $SAPIS | \
The -e is ending up in the output (perhaps dash's echo has no -e) resulting
in this error:
./sessionclean: 10: [: /etc/php5/-e: unexpected operator
I've removed the -e as our input is clean anyway.
Also, I've run this to normalize the spacing:
sed -i
Thanks Ondřej, no apology needed, this was indeed a constructive thread.
Sometimes us open source geeks get all too used to being in charge and
we forget how to communicate effectively. If I'm up in your neck of the
woods some time I'll look you up and we can grab a beer :)
Also, I'll do a PR on
Indeed, I think we've passed the 80/20 mark on this one. I'll test your
updated one today and we should be good.
--
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
Issue on line 8:
echo -e $SAPIS | \
The -e is ending up in the output (perhaps dash's echo has no -e) resulting
in this error:
./sessionclean: 10: [: /etc/php5/-e: unexpected operator
I've removed the -e as our input is clean anyway.
Also, I've run this to normalize the spacing:
sed -i
Thanks Ondřej, no apology needed, this was indeed a constructive thread.
Sometimes us open source geeks get all too used to being in charge and
we forget how to communicate effectively. If I'm up in your neck of the
woods some time I'll look you up and we can grab a beer :)
Also, I'll do a PR on
Thanks, this is looking better now. Here are some notes:
1. PROC_NAMES should be defined as proc_names or used as PROC_NAMES
(inconsistent case)
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
I've added HHVM support and discovered another issue along the way:
session.save_path can be empty and empty string. This is actually the
default in stock PHP and HHVM. The PHP docs imply that an empty string
is equal to /tmp
(http://php.net/manual/en/session.configuration.php#ini.session.save-
It seems likely that HHVM will find its way into the Debian repo, so I'm
going to see if they will set the session.save_path to /var/lib/php5:
https://github.com/hhvm/packaging/pull/67
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to
I have a feeling the CGI-mode process name is php5-cgi. I've installed
it, but I haven't been able to get Apache 2.4 and mod_actions to play
nice with it yet, so I haven't confirmed it.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to
I noticed that you changed the default session.save_path to
/var/lib/php5/sessions, which I think is a great idea (I have no idea
what the modules/ dir is for).
In order to align the HHVM packaging with the Debian PHP packaging I
have some questions:
1. Will PHP 5.6 be the default in Ubuntu
Thanks, this is looking better now. Here are some notes:
1. PROC_NAMES should be defined as proc_names or used as PROC_NAMES
(inconsistent case)
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
I've added HHVM support and discovered another issue along the way:
session.save_path can be empty and empty string. This is actually the
default in stock PHP and HHVM. The PHP docs imply that an empty string
is equal to /tmp
(http://php.net/manual/en/session.configuration.php#ini.session.save-
It seems likely that HHVM will find its way into the Debian repo, so I'm
going to see if they will set the session.save_path to /var/lib/php5:
https://github.com/hhvm/packaging/pull/67
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I have a feeling the CGI-mode process name is php5-cgi. I've installed
it, but I haven't been able to get Apache 2.4 and mod_actions to play
nice with it yet, so I haven't confirmed it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I noticed that you changed the default session.save_path to
/var/lib/php5/sessions, which I think is a great idea (I have no idea
what the modules/ dir is for).
In order to align the HHVM packaging with the Debian PHP packaging I
have some questions:
1. Will PHP 5.6 be the default in Ubuntu
Thanks Ondřej, this is a much better script, and I agree that the lack
of session.save_path support was rather annoying. This is still not
optimal for high-performance servers, but it seems to be a good
compromise for general use. Also, the fact that is honors SAPI-specific
settings helps.
What do you think about running this for each SAPI? It's actually *way*
more efficient:
for pid in $(pidof $sapi); do
find /proc/$pid/fd -lname $session_save_path/* -exec touch {} \;
done
That will iterate all the PIDs of the running SAPI (we'll need to
iterate them as well), then find
It just occurred to me that I was timing sudo in my last post, so here
are the sudo-less numbers:
root@steve-ubuntu:~# time for pid in $(pidof apache2); do find /proc/$pid/fd
-lname /var/lib/php5/* -print -exec touch {} \; ; done
/proc/30005/fd/21
real0m0.042s
user0m0.016s
sys
Ok, sorry for the repeated spamming tonight.
One problem with the solution you linked to is that it is extracting the
gx_maxlifetime in seconds, then putting that in find's -cmin which
expects minutes.
I've attached a script that incorporates the improvements of SAPI-
specific session file
Thanks Ondřej, this is a much better script, and I agree that the lack
of session.save_path support was rather annoying. This is still not
optimal for high-performance servers, but it seems to be a good
compromise for general use. Also, the fact that is honors SAPI-specific
settings helps.
What do you think about running this for each SAPI? It's actually *way*
more efficient:
for pid in $(pidof $sapi); do
find /proc/$pid/fd -lname $session_save_path/* -exec touch {} \;
done
That will iterate all the PIDs of the running SAPI (we'll need to
iterate them as well), then find
It just occurred to me that I was timing sudo in my last post, so here
are the sudo-less numbers:
root@steve-ubuntu:~# time for pid in $(pidof apache2); do find /proc/$pid/fd
-lname /var/lib/php5/* -print -exec touch {} \; ; done
/proc/30005/fd/21
real0m0.042s
user0m0.016s
sys
Ok, sorry for the repeated spamming tonight.
One problem with the solution you linked to is that it is extracting the
gx_maxlifetime in seconds, then putting that in find's -cmin which
expects minutes.
I've attached a script that incorporates the improvements of SAPI-
specific session file
Thanks for the completely non-constructive message. Google me if you
want. Anyway, my point (and apparently your subpoint) is that the
current script is not safe for production use. My improvements make it
slightly more suitable out of the box.
--
You received this bug notification because
You can improve things even when not using the argument from
authority. I totally agree, I was just trying to make a point that I
know what I'm talking about, as opposed to being a passive observer.
You also know what you're talking about, and I can respect that as well.
If you seriously think
Thanks for the completely non-constructive message. Google me if you
want. Anyway, my point (and apparently your subpoint) is that the
current script is not safe for production use. My improvements make it
slightly more suitable out of the box.
--
You received this bug notification because
You can improve things even when not using the argument from
authority. I totally agree, I was just trying to make a point that I
know what I'm talking about, as opposed to being a passive observer.
You also know what you're talking about, and I can respect that as well.
If you seriously think
Public bug reported:
The php5 file-based session cleaner script /var/lib/php5/sessionclean is
extremely expensive, taking over 10 seconds to run on my laptop, even
when no PHP file-based session storage is enabled and the system is
idle. My servers, on the other hand, are completely overwhelmed
On another note, why would we possibly need to run lsof every time we
need to cleanup sessions? This is a very inefficient and expensive
process. If someone knows how it came to be that this code was added, I
would be very curious. Also, I see that recent versions of Ubuntu
(14.04 for example)
Public bug reported:
The php5 file-based session cleaner script /var/lib/php5/sessionclean is
extremely expensive, taking over 10 seconds to run on my laptop, even
when no PHP file-based session storage is enabled and the system is
idle. My servers, on the other hand, are completely overwhelmed
On another note, why would we possibly need to run lsof every time we
need to cleanup sessions? This is a very inefficient and expensive
process. If someone knows how it came to be that this code was added, I
would be very curious. Also, I see that recent versions of Ubuntu
(14.04 for example)
There was a fairly significant bugfix in HAProxy v 1.4.15, April 2011
that prevents DOS attacks and HAProxy crashes. I've built a .deb for it
with the same config options as the existing version (TCP Splicing, Full
Transparent Proxy, PCRE). Networking is listed as a startup dependency,
so it
39 matches
Mail list logo
