Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

extract from syslog:

CRON[pid]: (user) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -
execdir fuser -s {} 2>/dev/null \; -delete)

My CPU has been stuck at 99% for a few hours now, and I'm assuming it's because of this. Would anyone happen to know what this is, how it started and how to stop it?

EDIT: I tried top -n1 and I see this in return multiple times:

PID user      20   0     0    0    0 Z 99.9  0.0   0:00.00 fuser <defunct>

this line repeats about 8 times.



user SMP Tue Feb 14 13:27:41 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux`
lsb_release -a:
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 11.10
Release:    11.10
Codename:   code


After reboot, the system went back to the same 99% cpu usage and the same top -n1 result.

share|improve this question
There's a bug in that command. The stderr output of fuser is being sent to /dev/null, as designed. But so is the stderr output of find, which probably was not. (Because -execdir actually doesn't launch the command via the shell, so the 2>/dev/null is being processed by the shell directly invoked by cron). However, while this may be concealing relevant symptoms, the positioning of the 2>/dev/null is not the cause of your CPU usage. – James Youngman Jun 26 '12 at 0:36
This is very weird: a zombie process should not be using CPU time (it doesn't even have code to execute). You have either a bug in process reporting tools or in your kernel. What OS is this (version, kernel, etc.)? Is there any virtualization? What is the output of uname -a and lsb_release -a? – Gilles Jun 26 '12 at 0:50
The fuser command is probably very short lived. It spends its time using up CPU time (system time, not user time) generating /proc data that it (trivially) consumes. Each instance of fuser probably finishes very quickly. But it is probably being run many times since there are, I suppose, many session files in there. The 99.9% figure probably just means that that instance of fuser used CPU intensively before it died. find probably isn't very agressive about reaping children; it will likely call waitpid again only when leaving a directory or running fuser again. – James Youngman Jun 26 '12 at 0:55
uname-a: user SMP Tue Feb 14 13:27:41 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux lsb_release -a: No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 11.10 Release: 11.10 Codename: code – Jack Jun 26 '12 at 0:56
Oops, correction: for -execdir ... \; the wait should be immediate, since the return code is needed as the result of the predicate (I was mixing this up with -execdir ...+ which always returns true, I think). – James Youngman Jun 26 '12 at 1:00

This is a cron job that cleans up old session files from /var/lib/php5/ . If it hangs on 99% you should perhaps check out the destination folder ( /var/lib/php5/) for an excessive amount of files or perhaps even filesystem corruption.

The process is started from crontab. See the crontab listings (described here). You kan kill the process and remove it from crontab, but it's more likely that you have an underlying problem such as an excessive amount of files that needs to be fixed.

share|improve this answer
If you end up with multiple cleanup processes running, they may interfere with each other by generating locks on the directory when they delete files. Try temporarily removing it from the crontab until the load clears. Then add it with a longer interval between runs. You may want to move it to a script with a locking mechanism to ensure only one instance is running. Kill off any multiple instances of the command for now. – BillThor Jun 26 '12 at 1:28
up vote 2 down vote accepted

Found the answer here: http://www.flynsarmy.com/2011/11/fuser-using-100-cpu-in-ubuntu-11-10/

in /etc/cron.d/php5 on Ubuntu 11.10:

09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] &amp;&amp; [ -d /var/lib/php5 ] &amp;&amp; find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2&gt;/dev/null \; -delete

09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] &amp;&amp; [ -d /var/lib/php5 ] &amp;&amp; find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) -delete

share|improve this answer
This worked, the issue seems to be solved. – Jack Jun 28 '12 at 0:37

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.