How do I find the uptime of a given linux process.

ps aux | grep gedit | grep -v grep

gives me a whole lot of information which includes the time at which the process was started. I am specifically looking for switch which returns the uptime of a process in milliseconds.


| |

As "uptime" has several meanings, here is a useful command.

ps -eo pid,comm,lstart,etime,time,args

This command lists all processes with several different time-related columns. It has the following columns:

PID COMMAND                          STARTED     ELAPSED     TIME COMMAND

PID = Process ID
first COMMAND = only the command name without options and without arguments
STARTED = the absolute time the process was started
ELAPSED = elapsed time since the process was started (wall clock time), format [[dd-]hh:]mm:ss TIME = cumulative CPU time, "[dd-]hh:mm:ss" format
second COMMAND = again the command, this time with all its provided options and arguments

| |
  • 1
    Nice. I prefer etimes myself - elapsed time in seconds - so it's machine readable – Asfand Qazi Jul 15 '15 at 9:35
  • 1
    the question was about stat time in milliseconds – yohann.martineau Nov 15 '17 at 12:53
  • unfortunately, busybox 1.29.3 broke the formatting for etime, so do not rely on it for parsing. – Danny Dulai Oct 5 '18 at 16:16

If you have a limited version of ps such as is found in busybox, you can get the process start time by looking at the timestamp of /proc/<PID>. For example, if the pid you want to look at is 55...

# ls -al /proc | grep 55
dr-xr-xr-x    7 root     root             0 May 21 05:53 55

... and then compare it with the current date...

# date
Thu May 22 03:00:47 EDT 2014
| |
  • 1
    This seems to no longer work on current kernels. – goertzenator Jun 23 '17 at 14:55
  • this works where ps -ef ... does not. "4.1.7-15.23.amzn1.x86_64" – pstanton Feb 24 at 22:15
  • can generate the etimes= with proc entries like etime=$(date -d "$(stat -c %y /proc/${pid} | cut -d ' ' -f 1,2)" +%s); echo "$(date +%s) - ${etime}" | bc -l – JGurtz Jul 21 at 1:40

I think you can just run:

$ stat /proc/1234

1234 being the process id.

example with two processes started at the same hour minute seconds but not the same milliseconds:

$ stat /proc/9355
Access: 2017-11-13 17:46:39.778791165 +0100
Modify: 2017-11-13 17:46:39.778791165 +0100
Change: 2017-11-13 17:46:39.778791165 +0100
$ stat /proc/9209
Access: 2017-11-13 17:46:39.621790420 +0100
Modify: 2017-11-13 17:46:39.621790420 +0100
Change: 2017-11-13 17:46:39.621790420 +0100
| |

yes, too old and yet too hard stuff. I tried with the above proposed "stat" method but what if I had "touch"-ed the PID proc dir yesterday? This means my year-old process is shown with yesterday's time stamp. Nah, not what I need :(

In the newer ones, it's simple:

ps -o etimes -p <PID>

as simple as that. Time is present in seconds. Do whatever you need it for. With some older boxes, situation is harder, since there's no etimes. One could rely on:

ps -o etime -p <PID>

which look a "a bit" weird since it's in dd-hh:mm:ss format. Not suitable for further calculation. I would have preferred it in seconds, hence I used this one:

ps -o etime -p <PID> --no-headers | awk -F '(:)|(-)' 'BEGIN{a[4]=1;a[3]=60;a[2]=3600;a[1]=86400;s=0};{for (i=NF;i>=1;i--) s=s+a[i]*$i}END{print s}'
| |
  • This is a really nice way of doing it on the older systems, thanks :) – RobotJohnny Sep 11 '18 at 10:53
  • do not parse the output of etime because busybox 1.29.3 changed the format. use the stat + /proc method instead – Danny Dulai Oct 5 '18 at 16:17

Such a simple thing is not properly answered after 5 years?

I don't think you can accurately get milliseconds. eg. if you see man procfs and see /proc/$$/stat which has field 22 as startime, which is in "clock ticks", you would have something more precise, but clock ticks aren't going at a perfectly constant rate (relative to 'wall clock time') and will be off... sleeping and certain things (ntpd I guess) offset it. For example on a machine running ntpd, with 8 days uptime and has never slept, dmesg -T has the same problem (I think...), and you can see it here:

# date; echo h > /proc/sysrq-trigger; dmesg -T | tail -n1 ; date
Fri Mar  3 10:26:17 CET 2017
[Fri Mar  3 10:26:16 2017] sysrq: SysRq : HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) show-task-states(t) unmount(u) force-fb(V) show-blocked-tasks(w) 
Fri Mar  3 10:26:17 CET 2017

Here's seconds:

# example pid here is just your shell

# current unix time (seconds since epoch [1970-01-01 00:00:00 UTC])
now=$(date +%s)

# process start unix time (also seconds since epoch)
# I'm fairly sure this is the right way to get the start time in a machine readable way (unlike ps)...but could be wrong
start=$(stat -c %Y /proc/"$pid")

# simple subtraction (both are in UTC, so it works)

printf "that process has run for %s seconds\n" "$age"
| |

By process name:

ps -eo pid,comm,lstart,etime,args | grep MyProcessName | cut -b 1-200


  • MyProcessName is the process name.
  • The ps lists all processes.
  • The grep filters by MyProcessName in args.
  • The cut lists the first 200 characters on each line. Useful, as often Java command lines are rather long.

Produces something like this:

 10673 java            Tue Aug 25 12:26:30 2020    19:19:25 /opt/apps/java_home/bin/java -Dservice.name=MyProcessName1
 10908 java            Tue Aug 25 12:26:41 2020    19:19:14 /opt/apps/java_home/bin/java -Dservice.name=MyProcessName2
 11062 java            Tue Aug 25 12:26:52 2020    19:19:03 /opt/apps/java_home/bin/java -Dservice.name=MyProcessName3

We can see that all of the services started on August 26th at 12:26, and none of them have restarted for any reason.

| |
[root@ip-x-x-x-x ec2-user]# ps -p `pidof java` -o etimes=

pidof java => process id for java process

etimes= => time in Seconds and '=' is to remove header

| |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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