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.


8 Answers 8


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

  • 2
    Nice. I prefer etimes myself - elapsed time in seconds - so it's machine readable Commented Jul 15, 2015 at 9:35
  • 1
    the question was about stat time in milliseconds Commented Nov 15, 2017 at 12:53
  • unfortunately, busybox 1.29.3 broke the formatting for etime, so do not rely on it for parsing. Commented Oct 5, 2018 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
  • 2
    This seems to no longer work on current kernels. Commented Jun 23, 2017 at 14:55
  • this works where ps -ef ... does not. "4.1.7-15.23.amzn1.x86_64"
    – pstanton
    Commented Feb 24, 2020 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
    Commented Jul 21, 2020 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
  • In rare cases my OpenSuse 15.5 shows future timestamps for /proc/* -- I wish someone could explain this :( Commented Dec 27, 2023 at 20:38

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 :) Commented Sep 11, 2018 at 10:53
  • do not parse the output of etime because busybox 1.29.3 changed the format. use the stat + /proc method instead Commented Oct 5, 2018 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.

  • ps -eo pid,comm,lstart,etime,args -q "`pgrep -f TheCmd`" maybe more effective, and avoid grep in list
    – yurenchen
    Commented Apr 17, 2023 at 15:44

as Systemd got introduced, people who search for this with SystemD distros can use systemctl status option. And get the uptime in the output as depicted here:

● openkm.service - LSB: Start and stop OpenKM
   Loaded: loaded (/etc/rc.d/init.d/openkm; bad; vendor preset: disabled)
   Active: active (exited) since Tue 2021-04-20 09:27:13 CAT; 2 weeks 4 days ago
[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

You must log in to answer this question.

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