hello!
thanks for your interest! my characterization of the bug in fuser is
wrong, you are right.
ccing also craig, the maintainer of psmisc
but i have experienced many times this week all the daemons on our
server being killed due to OOM (i guess) because of the php5 cron job.
this leaves a machine with linux and an ip address, but no apache or
ssh, only access is physically trough console. the databases indexes and
even some tables got corrupted in the process too. max load was 400.
what i can confirm from investigation is that version 22.14-1 of fuser
uses many times more resources - cpu and ram - than the stable version.
why this is, i don't know. but used in the find for clearing php
sessions it has a big impact. perhaps find spawns all these fuser
commands in parallel, eating all ram? is that what causes all the
defunct processes?
milci:~/php5-common# aptitude install psmisc/stable
The following packages will be DOWNGRADED:
psmisc
...
Setting up psmisc (22.11-1) ...
milci:~/php5-common# ls /var/lib/php5 | wc
203 203 7714
(not too many session really)
milci:~/php5-common# time find /var/lib/php5/ -depth -mindepth 1
-maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser
-s {} 2>/dev/null \;
real 0m4.808s
user 0m1.468s
sys 0m3.348s
milci:~/php5-common# aptitude install psmisc
The following packages will be upgraded:
psmisc
...
Setting up psmisc (22.14-1) ...
milci:~/php5-common# time find /var/lib/php5/ -depth -mindepth 1
-maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser
-s {} 2>/dev/null \;
(...waiting, waiting... got fed up)
^C
real 0m47.717s
user 0m2.676s
sys 0m22.585s
milci:~/php5-common# uptime (load rises quickly!)
23:28:24 up 6:57, 5 users, load average: 1.36, 0.85, 0.49
so there is trouble brewing here, for sure. but might not be as simple
as i thought...
LF
Dne 17. 07. 2011 21:44, piše Ondřej Surý:
Hi,
have you tested it yourself or have you just made conclusion on a blog post?
howl:/# dpkg -l psmisc
ii psmisc 22.14-1
utilities that use the proc
file system
howl:/# fuser /bin/bash; echo $?
/bin/bash: 1398m
0
howl:/# fuser -s /bin/bash; echo $?
0
howl:/# fuser /tmp/foobar; echo $?
1
howl:/# fuser -s /tmp/foobar; echo $?
1
It seems to me that the fuser works as it should. If you don't think
so, please provide a clear test case.
Regards,
Ondrej
On Sun, Jul 17, 2011 at 20:20,<l...@mail.ljudmila.org> wrote:
hello!
this issue is real and pretty dangerous to the stability of the system.
fuser -s in version 22.14-1 has a bug, returning the wrong output value.
look at the blog post of maintainer here:
http://enc.com.au/2011/06/psmisc-22-14-released/
because of this the cron job in php5-common fails to delete old sessions.
after a few hours, this can lead to meltdown of server by running out of
memory and countless defunct fuser processes in process list
these processes aditionally cause extra logging by atop daemon, which can
fill the /tmp partition quickly
best,
LF
_______________________________________________
pkg-php-maint mailing list
pkg-php-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-maint
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
