Because Ubuntu Trusty reached End of Standard Support I am unsubscribing
ubuntu-server from this bug.
--
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
** Tags removed: server-next
--
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
Hello all, I have provided a testbuild for this bug at:
https://launchpad.net/~nacc/+archive/ubuntu/lp1356113. Please test this
version of the script (sessionclean) and report back results.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubunt
** Changed in: php5 (Ubuntu Trusty)
Assignee: (unassigned) => Nish Aravamudan (nacc)
--
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 mana
You might try the script I use in ppa:ondrej/php:
http://anonscm.debian.org/cgit/pkg-
php/php.git/tree/debian/sessionclean?h=master-5.5
--
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:
P
Any fix to 14.04 yet? This bug is still causing me to manually reboot my
server every week otherwise it would be too many processes to process
any requests.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bug
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 becaus
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: p
@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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1356113
Title:
PHP5 session clean
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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad
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 can
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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1356113
Tit
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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1356113
Title:
PHP5
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
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
Bu
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
Either
```
for sapi in /usr/lib/php5/sapi/*; do
. $sapi
```
and have the /usr/lib/php5/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 because
> Wouldn't /usr/lib/php5/sapi/ be a better location for scripts?
Yup...
--
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
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
There's one more improvement the packages could do:
Each SAPI could drop it's session snippet to /var/lib/php5/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 coul
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
> 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 fr
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
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 cron
> 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.
>
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
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.
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.
ht
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-
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
> 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 sur
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
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
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
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,
Thanks everyone for working on this.
--
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.l
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
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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1356113
Title
> 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 /etc/php5/fpm/php.in
"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
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 sessi
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
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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1356113
Title:
PHP5 session clean cron job cau
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
44 matches
Mail list logo
