Any ETA on a port to Debian-ARM?
Currently using Linux version 4.1.15+ (dc4@dc4-XPS13-9333) (gcc
version 4.8.3 20140303 (prerelease) (crosstool-NG linaro-1.13.1+bzr2650
- Linaro GCC 2014.03) ) #830 Tue Dec 15 16:58:28 GMT 2015
Thanks.
Jeff Anttila
--
You received this bug notification
AFAICT, a fix to this has not yet been committed to Debian VCS so I have
nothing to track or cherry-pick in Ubuntu yet. Is this accurate or have
I missed something?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to php5 in Ubuntu.
@racb did you check the master-5.6 branch? I am quite sure that Debian
jessie already has the new sessionclean script.
--
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:
Ah sorry, thanks. I looked again. I saw the commits but assumed that
2014-08 was too old, but the comments do actually date from them.
So I think that Wily contains the new script, but Trusty will need it
cherry-picked. Setting bug tasks accordingly.
** Tags added: server-next
** Also affects:
I just noticed 800+ processes on my raspberry pi 2 ubuntu 14.04, all
were spawns from this cron.
Although cron script is bad in terms of cpu use, I see it's set to run
every 30 minutes. So I am also thinking something else is also going on,
probably some hanging with lsof anyways.
This script
My 14.10 laptop just froze at the moment when the cron.d job kicked in
(9 minutes past the hour). There was not much else running at the time.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to php5 in Ubuntu.
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: php5 (Ubuntu)
Status: New = Confirmed
--
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
Sorry for the late reply. I've been out for the last couple of weeks.
On Tue, Aug 19, 2014 at 08:13:55AM -, Ondřej Surý wrote:
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
There's one more improvement the packages could do:
Each SAPI could drop it's session snippet to /var/lib/php5/sapi/sapi
and the sessionclean script would read those snippets and clean the
directory according to really installed snippets.
That would make the sessionclean script SAPI agnostic and
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
Wouldn't /usr/lib/php5/sapi/sapi be a better location for scripts?
Yup...
--
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 session clean cron job causes OOM
To
Either
```
for sapi in /usr/lib/php5/sapi/*; do
. $sapi
```
and have the /usr/lib/php5/sapi/sapi contain shell snippet with
definitions
or
```
cat /usr/lib/php5/sapi/* | while IFS=: read -r VAR1 VAR2 VAR3 VAR4; do
```
and keep the current format...
--
You received this bug notification
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
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
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
Issue on line 8:
Missed this in all the cruft generated by sh -x, and since the other
output looked ok...
Thanks for noticing that...
Also thank you for the feedback, this was very valuable after all.
I probably owe you an apology, so please accept my apology I should have
been more calm from
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
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.
Good catch. The code was there, but it got deleted accidentally.
What do you think about running this for each SAPI?
I am still not sure
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 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
I was just trying to make a point
You did make a point, but totally different from the one intended.
Also your proposed fix is incomplete...
# sed -n -e
's/^[[:space:]]*session.save_handler[[:space:]]*=[[:space:]]*\([[:alnum:]]\+\).*$/\1/p'
/etc/php5/fpm/php.ini
# php5 -c
Try this updated script that now requires php5-cli to be installed:
http://anonscm.debian.org/cgit/pkg-php/php.git/tree/debian/sessionclean
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to php5 in Ubuntu.
Steve, thank you for your report and for your time in helping to make
Ubuntu better.
I'm not really sure how to respond here. Ondřej is the Debian maintainer
for PHP, and Ubuntu's packaging is derived from Debian's packaging, so
his opinion matters. I appreciate Ondřej's participation in Ubuntu's
Thanks everyone for working on this.
--
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 session clean cron job causes OOM
To manage notifications about this bug go
As an *expert* you surely heard of rm /etc/cron.d/php5 or even sed -i
-e s/^/#/ /etc/cron.d/php5...
--
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 session clean
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
Should I be in awe or what? You can improve things even when not using
the argument from authority.
My point is that the default cron job works and is perfectly safe for
most deployments and it's documented in README.Debian that you need to
tweak the session cleanup if you do modification to
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
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)
38 matches
Mail list logo
