How to find uptime of a linux process












62















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










share|improve this question



























    62















    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










    share|improve this question

























      62












      62








      62


      29






      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










      share|improve this question














      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






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Jan 20 '12 at 10:05









      Mahadevan SreenivasanMahadevan Sreenivasan

      413156




      413156






















          6 Answers
          6






          active

          oldest

          votes


















          104














          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






          share|improve this answer



















          • 1





            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











          • 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





















          9














          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





          share|improve this answer
























          • This seems to no longer work on current kernels.

            – goertzenator
            Jun 23 '17 at 14:55



















          4














          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





          share|improve this answer































            3














            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"





            share|improve this answer































              3














              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





              share|improve this answer
























              • 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



















              -1














              [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






              share|improve this answer

























                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
                });


                }
                });














                draft saved

                draft discarded


















                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









                104














                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






                share|improve this answer



















                • 1





                  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











                • 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


















                104














                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






                share|improve this answer



















                • 1





                  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











                • 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
















                104












                104








                104







                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






                share|improve this answer













                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







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Aug 21 '12 at 14:46









                AbdullAbdull

                1,23631322




                1,23631322








                • 1





                  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











                • 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





                  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











                • 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















                9














                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





                share|improve this answer
























                • This seems to no longer work on current kernels.

                  – goertzenator
                  Jun 23 '17 at 14:55
















                9














                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





                share|improve this answer
























                • This seems to no longer work on current kernels.

                  – goertzenator
                  Jun 23 '17 at 14:55














                9












                9








                9







                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





                share|improve this answer













                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






                share|improve this answer












                share|improve this answer



                share|improve this answer










                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



















                • 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











                4














                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





                share|improve this answer




























                  4














                  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





                  share|improve this answer


























                    4












                    4








                    4







                    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





                    share|improve this answer













                    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






                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Nov 15 '17 at 13:01









                    yohann.martineauyohann.martineau

                    25612




                    25612























                        3














                        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"





                        share|improve this answer




























                          3














                          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"





                          share|improve this answer


























                            3












                            3








                            3







                            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"





                            share|improve this answer













                            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"






                            share|improve this answer












                            share|improve this answer



                            share|improve this answer










                            answered Mar 3 '17 at 9:35









                            PeterPeter

                            31429




                            31429























                                3














                                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





                                share|improve this answer
























                                • 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
















                                3














                                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





                                share|improve this answer
























                                • 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














                                3












                                3








                                3







                                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





                                share|improve this answer













                                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






                                share|improve this answer












                                share|improve this answer



                                share|improve this answer










                                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



















                                • 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











                                -1














                                [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






                                share|improve this answer






























                                  -1














                                  [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






                                  share|improve this answer




























                                    -1












                                    -1








                                    -1







                                    [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






                                    share|improve this answer















                                    [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







                                    share|improve this answer














                                    share|improve this answer



                                    share|improve this answer








                                    edited Jan 7 at 23:08









                                    Nordlys Jeger

                                    783417




                                    783417










                                    answered Jan 7 at 21:58









                                    RohitRohit

                                    11




                                    11






























                                        draft saved

                                        draft discarded




















































                                        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.




                                        draft saved


                                        draft discarded














                                        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





















































                                        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







                                        Popular posts from this blog

                                        Plaza Victoria

                                        Puebla de Zaragoza

                                        Musa