How to find uptime of a linux process
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.
Thanks
linux process grep uptime
add a comment |
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.
Thanks
linux process grep uptime
add a comment |
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.
Thanks
linux process grep uptime
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.
Thanks
linux process grep uptime
linux process grep uptime
asked Jan 20 '12 at 10:05
Mahadevan SreenivasanMahadevan Sreenivasan
413156
413156
add a comment |
add a comment |
6 Answers
6
active
oldest
votes
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 argumentsSTARTED
= the absolute time the process was startedELAPSED
= 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 preferetimes
myself - elapsed time in seconds - so it's machine readable
– Asfand Qazi
Jul 15 '15 at 9:35
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
add a comment |
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
This seems to no longer work on current kernels.
– goertzenator
Jun 23 '17 at 14:55
add a comment |
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
add a comment |
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
pid=$$
# 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)
age=$((now-start))
printf "that process has run for %s secondsn" "$age"
add a comment |
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>
ELAPSED
339521
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>
ELAPSED
76-03:26:15
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}'
339544
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
add a comment |
[root@ip-x-x-x-x ec2-user]# ps -p `pidof java` -o etimes=
266433
pidof java
=> process id for java process
etimes=
=> time in Seconds and '=' is to remove header
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f380520%2fhow-to-find-uptime-of-a-linux-process%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
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 argumentsSTARTED
= the absolute time the process was startedELAPSED
= 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 preferetimes
myself - elapsed time in seconds - so it's machine readable
– Asfand Qazi
Jul 15 '15 at 9:35
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
add a comment |
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 argumentsSTARTED
= the absolute time the process was startedELAPSED
= 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 preferetimes
myself - elapsed time in seconds - so it's machine readable
– Asfand Qazi
Jul 15 '15 at 9:35
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
add a comment |
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 argumentsSTARTED
= the absolute time the process was startedELAPSED
= 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
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 argumentsSTARTED
= the absolute time the process was startedELAPSED
= 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
answered Aug 21 '12 at 14:46
AbdullAbdull
1,23631322
1,23631322
1
Nice. I preferetimes
myself - elapsed time in seconds - so it's machine readable
– Asfand Qazi
Jul 15 '15 at 9:35
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
add a comment |
1
Nice. I preferetimes
myself - elapsed time in seconds - so it's machine readable
– Asfand Qazi
Jul 15 '15 at 9:35
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
1
1
Nice. I prefer
etimes
myself - elapsed time in seconds - so it's machine readable– Asfand Qazi
Jul 15 '15 at 9:35
Nice. I prefer
etimes
myself - elapsed time in seconds - so it's machine readable– Asfand Qazi
Jul 15 '15 at 9:35
the question was about stat time in milliseconds
– yohann.martineau
Nov 15 '17 at 12:53
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
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
add a comment |
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
This seems to no longer work on current kernels.
– goertzenator
Jun 23 '17 at 14:55
add a comment |
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
This seems to no longer work on current kernels.
– goertzenator
Jun 23 '17 at 14:55
add a comment |
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
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
answered Jul 14 '15 at 16:33
goertzenatorgoertzenator
31537
31537
This seems to no longer work on current kernels.
– goertzenator
Jun 23 '17 at 14:55
add a comment |
This seems to no longer work on current kernels.
– goertzenator
Jun 23 '17 at 14:55
This seems to no longer work on current kernels.
– goertzenator
Jun 23 '17 at 14:55
This seems to no longer work on current kernels.
– goertzenator
Jun 23 '17 at 14:55
add a comment |
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
add a comment |
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
add a comment |
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
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
answered Nov 15 '17 at 13:01
yohann.martineauyohann.martineau
25612
25612
add a comment |
add a comment |
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
pid=$$
# 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)
age=$((now-start))
printf "that process has run for %s secondsn" "$age"
add a comment |
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
pid=$$
# 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)
age=$((now-start))
printf "that process has run for %s secondsn" "$age"
add a comment |
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
pid=$$
# 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)
age=$((now-start))
printf "that process has run for %s secondsn" "$age"
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
pid=$$
# 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)
age=$((now-start))
printf "that process has run for %s secondsn" "$age"
answered Mar 3 '17 at 9:35
PeterPeter
31429
31429
add a comment |
add a comment |
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>
ELAPSED
339521
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>
ELAPSED
76-03:26:15
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}'
339544
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
add a comment |
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>
ELAPSED
339521
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>
ELAPSED
76-03:26:15
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}'
339544
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
add a comment |
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>
ELAPSED
339521
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>
ELAPSED
76-03:26:15
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}'
339544
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>
ELAPSED
339521
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>
ELAPSED
76-03:26:15
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}'
339544
answered Aug 27 '18 at 11:57
George IvanovGeorge Ivanov
1311
1311
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
add a comment |
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
This is a really nice way of doing it on the older systems, thanks :)
– RobotJohnny
Sep 11 '18 at 10:53
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
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
add a comment |
[root@ip-x-x-x-x ec2-user]# ps -p `pidof java` -o etimes=
266433
pidof java
=> process id for java process
etimes=
=> time in Seconds and '=' is to remove header
add a comment |
[root@ip-x-x-x-x ec2-user]# ps -p `pidof java` -o etimes=
266433
pidof java
=> process id for java process
etimes=
=> time in Seconds and '=' is to remove header
add a comment |
[root@ip-x-x-x-x ec2-user]# ps -p `pidof java` -o etimes=
266433
pidof java
=> process id for java process
etimes=
=> time in Seconds and '=' is to remove header
[root@ip-x-x-x-x ec2-user]# ps -p `pidof java` -o etimes=
266433
pidof java
=> process id for java process
etimes=
=> time in Seconds and '=' is to remove header
edited Jan 7 at 23:08
Nordlys Jeger
783417
783417
answered Jan 7 at 21:58
RohitRohit
11
11
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f380520%2fhow-to-find-uptime-of-a-linux-process%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown