In order to measure a user's total CPU time, I'm using the "utime" field out of /proc/[pid]/stat:

utime %lu   Amount of time that this process has been scheduled in user
            mode, measured in clock ticks (divide by
            sysconf(_SC_CLK_TCK).  This includes guest time, guest_time
            (time spent running a virtual CPU, see below), so that
            applications that are not aware of the guest time field do
            not lose that time from their calculations.

(from man proc (5))

So, my "user utime" is the sum of the utime of all PIDs this user is running.

I'm hoping this will give me an accurate value for the number of CPU seconds this user has spent. Am I on the right track?

Some of the things I don't understand or take into account yet:

  • Each PID also has a parent PID (or zero). But I'm counting every PID, not just the ones with a ppid of 0. Is this correct?
  • There are, in addition to utime, stime, cutime and cstime. Do I need to worry about those? I'm assuming that utime is the total number of cpu seconds for a PID, not counting the parent.

If I calculate the system's total cpu time using /proc/uptime, this value is fairly close to my sum for all users, but the difference is significant. For instance (in minutes):

system cpu_time:         96.13
sum of users_cputime:   111.45


I get "sensible looking" values for all kinds of things. At the moment I'm using the sum of utime, stime, cutime and cstime. And it reports values that, while I don't understand them, correlate very well with measurements from time.

If I am completely on the wrong track, there's another question:

  • /proc/cputime doesn't have any information about the time spent by the CPUs executing processes, so I'm puzzled what your “system cpu_time” calculation is. If you're doing something with the second number, it's the time spent by the idle task; I don't know exactly what that means in practice. Commented Feb 24, 2012 at 19:24
  • 1
    Your “user time” would have to add the utime values from all dead processes as well. How do you take those into account? Commented Feb 24, 2012 at 19:27
  • Mhh. What I call "system cpu time" is merely the first value from /proc/uptime, "system seconds". I would've thought this was too high, as it also counts kernel threads, but as you can see the sum of all "utime" values is still higher than the system time from /proc/utime. Your link, as far as I can tell, explains why. Though to be clear: I'm not interested in that number really. I'm interested in "per-user cpu time". Commented Feb 24, 2012 at 19:31
  • As for the second comment: For the moment, I was planning on measuring this periodically (say every second), which would ignore short-lived processes. Commented Feb 24, 2012 at 19:32
  • So your system cpu time calculation is ($1-$2/$number_of_cups) where $1 and $2 are the values from /proc/uptime? Then I guess the I/O attributed to the idle task would explain the difference. I don't know anything about the topic, so I suspect I'm missing something major: I wouldn't expect so much to happen in the idle task, especially considering that your sum of users cputime is likely missing a lot of short-lived processes. Commented Feb 24, 2012 at 19:57

1 Answer 1


The traditional way to log and track user CPU time is process accounting. On Linux, install the GNU accounting utilities, typically provided by a package called acct. I'm not sure how accurate it will be at keeping track of the time spent in very short-lived processes, but it'll at least list all the processes ever executed.

Run lastcomm to get a list of all the commands executed by any user and the time spent in each (rounded to ~10ms for short-lived processes, expect to see a lot of 0.00). Run sa to display various sums and statistics. In particular, sa -m displays per-user totals. The statistics accumulated by sa run from the last rotation of the accounting logs (typically located in /var/log/account/).

Note that you aren't going to catch all processes by sampling at intervals, not by a far cry. You'll miss almost all short-lived processes and the last few seconds of long processes. Process accounting does list all past processes.

In /proc/$pid/stat, the user time is the time spent doing computation, as opposed to the system time spent doing I/O. Which one to count depends on what you want to do with the information.

Counting all the PIDs is right. I don't know what the parent PID has to do with this.

On the system side, your description of /proc/uptime seems wrong. Wikipedia has it right as I write. The first field is the real time elapsed since the system booted, minus any time spent suspended or hibernating. The second field is the cumulated time spent in the idle task on all CPUs. I'm not sure what that really means; it's certainly not the total idle time on my machine. In the kernel, the value is summed in uptime_proc_show from variables updated in account_idle_time.

  • What about very long running processes? Does sa wait for the process to quit before reporting it's cpu time? Commented Feb 25, 2012 at 11:48
  • @StefanoPalazzo Yes, accounting data is written when a process dies. That also means you get no data for processes that were running after a system crash, as far as I know. Commented Feb 25, 2012 at 20:09
  • That's a problem - it means I can't use it, as we'll have a lot of long-running processes. Commented Feb 26, 2012 at 13:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .