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 b
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) p
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
"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 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.
Also,
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
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 0m
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 cleani
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 "$save_path:$gc_ma
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 php
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 p
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 14.10
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 ses
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
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
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/ be a better location for scripts?
--
You rece
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
Se
I prefer option #1 - sourcing the sessionclean scripts from
/usr/lib/php5/sapi/* or perhaps /usr/lib/php5/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 should d
19 matches
Mail list logo