Linux: Getting date & time of system startup












43















I know that uptime prints the time a machine has been up and running, but is there an easier (reliable) way to get the date of the start up than counting down from this output?



I tried looking around /proc, but didn't find anything of relevance. There's also a line like this on my dmesg: [ 0.673492] rtc_cmos rtc_cmos: setting system clock to 2011-03-14 14:26:52 UTC (1300112812), but I'm wondering if this method is distribution and kernel version agnostic.










share|improve this question























  • What's unreliable or hard about uptime?

    – Bobby
    Mar 28 '11 at 11:25






  • 2





    @Bobby: Nothing about the command or its function per se, but as said I want to get the date and time of last system boot, not how long it's been up since. uptime returns a string like "up 13 days, 21:01", and you'd need to count it from that.

    – jho
    Mar 28 '11 at 11:29






  • 4





    It's trivial to count back from the uptime value. If you want reliable, you want /proc/uptime.

    – sam hocevar
    Mar 28 '11 at 14:29
















43















I know that uptime prints the time a machine has been up and running, but is there an easier (reliable) way to get the date of the start up than counting down from this output?



I tried looking around /proc, but didn't find anything of relevance. There's also a line like this on my dmesg: [ 0.673492] rtc_cmos rtc_cmos: setting system clock to 2011-03-14 14:26:52 UTC (1300112812), but I'm wondering if this method is distribution and kernel version agnostic.










share|improve this question























  • What's unreliable or hard about uptime?

    – Bobby
    Mar 28 '11 at 11:25






  • 2





    @Bobby: Nothing about the command or its function per se, but as said I want to get the date and time of last system boot, not how long it's been up since. uptime returns a string like "up 13 days, 21:01", and you'd need to count it from that.

    – jho
    Mar 28 '11 at 11:29






  • 4





    It's trivial to count back from the uptime value. If you want reliable, you want /proc/uptime.

    – sam hocevar
    Mar 28 '11 at 14:29














43












43








43


10






I know that uptime prints the time a machine has been up and running, but is there an easier (reliable) way to get the date of the start up than counting down from this output?



I tried looking around /proc, but didn't find anything of relevance. There's also a line like this on my dmesg: [ 0.673492] rtc_cmos rtc_cmos: setting system clock to 2011-03-14 14:26:52 UTC (1300112812), but I'm wondering if this method is distribution and kernel version agnostic.










share|improve this question














I know that uptime prints the time a machine has been up and running, but is there an easier (reliable) way to get the date of the start up than counting down from this output?



I tried looking around /proc, but didn't find anything of relevance. There's also a line like this on my dmesg: [ 0.673492] rtc_cmos rtc_cmos: setting system clock to 2011-03-14 14:26:52 UTC (1300112812), but I'm wondering if this method is distribution and kernel version agnostic.







linux uptime






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Mar 28 '11 at 11:15









jhojho

608169




608169













  • What's unreliable or hard about uptime?

    – Bobby
    Mar 28 '11 at 11:25






  • 2





    @Bobby: Nothing about the command or its function per se, but as said I want to get the date and time of last system boot, not how long it's been up since. uptime returns a string like "up 13 days, 21:01", and you'd need to count it from that.

    – jho
    Mar 28 '11 at 11:29






  • 4





    It's trivial to count back from the uptime value. If you want reliable, you want /proc/uptime.

    – sam hocevar
    Mar 28 '11 at 14:29



















  • What's unreliable or hard about uptime?

    – Bobby
    Mar 28 '11 at 11:25






  • 2





    @Bobby: Nothing about the command or its function per se, but as said I want to get the date and time of last system boot, not how long it's been up since. uptime returns a string like "up 13 days, 21:01", and you'd need to count it from that.

    – jho
    Mar 28 '11 at 11:29






  • 4





    It's trivial to count back from the uptime value. If you want reliable, you want /proc/uptime.

    – sam hocevar
    Mar 28 '11 at 14:29

















What's unreliable or hard about uptime?

– Bobby
Mar 28 '11 at 11:25





What's unreliable or hard about uptime?

– Bobby
Mar 28 '11 at 11:25




2




2





@Bobby: Nothing about the command or its function per se, but as said I want to get the date and time of last system boot, not how long it's been up since. uptime returns a string like "up 13 days, 21:01", and you'd need to count it from that.

– jho
Mar 28 '11 at 11:29





@Bobby: Nothing about the command or its function per se, but as said I want to get the date and time of last system boot, not how long it's been up since. uptime returns a string like "up 13 days, 21:01", and you'd need to count it from that.

– jho
Mar 28 '11 at 11:29




4




4





It's trivial to count back from the uptime value. If you want reliable, you want /proc/uptime.

– sam hocevar
Mar 28 '11 at 14:29





It's trivial to count back from the uptime value. If you want reliable, you want /proc/uptime.

– sam hocevar
Mar 28 '11 at 14:29










11 Answers
11






active

oldest

votes


















37














I found some commands here. Try who -b or last reboot | head -1.
who gives numeric dates, while last reboot returns abbreviated day / month names.






share|improve this answer
























  • how about if we only want the date and nothing else?

    – T0xicCode
    May 8 '12 at 3:00






  • 4





    who -b | cut -d' ' -f13 returns date only (-f14 returns time)

    – charlesbridge
    May 8 '12 at 11:15






  • 2





    Warning: last reboot did not give me the correct date ! who -b did.

    – qwertzguy
    Sep 18 '13 at 18:08











  • last reboot gave me an incorrect date too, wtmp seemed to have been rotated first day of the month

    – golimar
    Feb 17 '15 at 15:54



















21














This queries the uptime from the kernel and displays it in the local timezone:



date -d "`cut -f1 -d. /proc/uptime` seconds ago"


Be careful about other options. The last command will stop working as soon as wtmp has been rotated. The who command depends on the availability and integrity of utmp. And /proc/1 might have the current date instead of the boot time date, and could even be unavailable on a hardened system. Edit: dmesg only has a fixed-length back buffer, so it is unrealiable, too. The kernel logs may be in /var/log but most distributions only keep 8 weeks of them.






share|improve this answer





















  • 1





    Interestingly, this disagrees with who -b by a minute or two on my 210-days-uptime system. Looks like who -b reports a time stamp, while this counting is somehow affected by clock drifts, even if these are periodically corrected by a running ntpd.

    – Ruslan
    Aug 27 '14 at 9:11








  • 2





    After reviewing all the alternate answers, settled on: date -d "`cut -f1 -d. /proc/uptime` seconds ago" -u (which has time/date in UTC)

    – david6
    Jan 14 '16 at 22:32













  • Phenomenal answer. If the kernel don't know, nobody knows- it's the Source of Truth for the system. The seconds make it easy to perform time calculations (I stumbled on this because I want to know "Which of my hosts didn't reboot within the last day [86,400 seconds]?")

    – Mike S
    Jun 3 '18 at 3:13



















14














I stumbled on this question while looking for a way to get a consistent, parseable boot time, as opposed to time since boot which changes on every call.



It appears that uptime -s will do the trick on most linux systems.






share|improve this answer
























  • uptime -s outputs e.g. 2017-08-09 01:23:45. This is best, by being simplest. This command is included in the package "procps".

    – teika kazura
    Apr 8 '18 at 12:34











  • The uptime in CentOS 6 (procps version 3.2.8) does not seem to support this, sadly.

    – mwfearnley
    Dec 3 '18 at 10:43



















10














I found the btime line in /proc/stat when poking around a bit



cat /proc/stat | grep btime | awk '{ print $2 }'


and after a quick search, I found this page: /proc/stat explained, which outlines the "Various pieces of information about kernel activity that are available in the
/proc/stat file."




The "btime" line gives the time at which the system booted, in seconds since
the Unix epoch.







share|improve this answer





















  • 1





    Seems a lot easier to write awk '/btime/{print $2}' /proc/stat

    – William Pursell
    Jun 12 '17 at 14:07











  • @WilliamPursell easiest is always what you already know. I am no awk wizard. :P

    – Oddstr13
    Jun 12 '17 at 19:37











  • Good point. However, you used cat gratuitously. Just grep from the file.

    – Mike S
    Jun 3 '18 at 3:18











  • @MikeS correct – however, I still stand by my original command chain as a clear representation of where the information is found, even 7 years after my answer.

    – Oddstr13
    Jun 3 '18 at 8:20



















7
















  • good: uptime -s, who -b or parsing /proc/uptime


  • bad: ls -ld /proc/1 and variants.


Don't use ls -ld /proc/1 for this purpose. It's sometimes updated after s2disk or s2ram.



In my case, who -b said:



system boot May 2 09:51



While ls -ld /proc/1:



dr-xr-xr-x 7 root root 0 May 3 13:09 /proc/1



ls -ld for /proc or /sys seem to persist after resuming, but it's implementation dependent, and may change in future, so don't use such methods. And if your system clock is in localtime, not UTC, they have negative offset.



(I don't have the privilege to comment to answers yet, so opened a new answer. Sorry.)



EDIT: uptime -s was first answered in this answer by mikegreiling






share|improve this answer

































    2














    The simplest way is to look to see when /sbin/init started (that's always the first process to be started after the kernel loads):



    # ls -ld /proc/1
    dr-xr-xr-x 7 root root 0 2011-03-27 23:54 /proc/1


    So I can see that my machine booted up at 6 minutes to midnight on the 27th of March 2011.



    If you want to use it in scripting you can use the stat command instead:



    # stat --printf='%Y' /proc/1
    1301266491


    The %Y specifies the time since the directory was last changed (process creation time) in seconds since the epoch (1/1/70) and is a standard unix timestamp.






    share|improve this answer



















    • 1





      Unfortunately this doesn't work: the mtime on those folders can change for other reasons (I have a system here that has a 5 day uptime and the mtime of /proc/1 is 25 minutes ago)

      – kdt
      Dec 18 '12 at 13:10






    • 1





      It's not reliable, as explained in my answer

      – teika kazura
      Feb 13 '15 at 5:46





















    1














    In Linux,



    ls -ld /proc


    seems to give me what I need. The post above is odd. /proc/uptime does not contain a date value – it would have to be subtracted from the current time. Maybe he meant:



    date -d @$(( $(date +%s) - $(cut -f1 -d. /proc/uptime) ))





    share|improve this answer


























    • uptime -s provides a date value

      – mikegreiling
      Nov 1 '14 at 20:56



















    1














    Under Bash, without pipes nor other processes; just text:





    $ REPLY="$(</proc/uptime)"
    $ REPLY="${REPLY%%.*}"
    $ echo "$REPLY"
    31207


    (Just reused the REPLY default variable, but you can choose whatever you need)






    share|improve this answer
























    • Sure, Why not? Kinda clever use of variable substringiness. Cool. +1. Thanks for the idea!

      – Mike S
      Jun 3 '18 at 3:24



















    0














    date -d @$(sed -n '/^btime /s///p' /proc/stat)


    (yet another way to do this, which is useful in certain circumstances)






    share|improve this answer































      0














      Command:



      (echo ' Currently:' | tr "n" ' ' ; date +"%Y-%m-%d %k:%M:%S" ; echo '  Up Since:' | tr 'n' ' ' ; uptime -s ; echo '  Duration:' | tr 'n' ' ' ; uptime -p)


      Output:



       Currently: 2016-05-09  9:06:29
      Up Since: 2016-05-04 12:56:04
      Duration: up 4 days, 20 hours, 10 minutes





      share|improve this answer

































        0














        Clear and concise with tuptime command:



        # tuptime -t
        No. Startup Date Uptime Shutdown Date End Downtime

        1 09:43:39 AM 08/08/2017 41 days, 0 hours, 51 minutes and 2 seconds 10:34:41 AM 09/18/2017 OK 10 seconds
        2 10:34:51 AM 09/18/2017 1 minute and 16 seconds 10:36:07 AM 09/18/2017 OK 1 second
        3 10:36:08 AM 09/18/2017 13 minutes and 20 seconds 10:49:28 AM 09/18/2017 OK 3 seconds
        4 10:49:31 AM 09/18/2017 45 days, 0 hours, 1 minute and 20 seconds 09:50:51 AM 11/02/2017 OK 4 seconds
        5 09:50:55 AM 11/02/2017 27 minutes and 25 seconds 10:18:20 AM 11/02/2017 OK 4 seconds
        6 10:18:24 AM 11/02/2017 9 seconds 10:18:33 AM 11/02/2017 OK 9 seconds
        7 10:18:42 AM 11/02/2017 4 days, 5 hours, 41 minutes and 47 seconds 04:00:29 PM 11/06/2017 OK 44 seconds
        8 04:01:13 PM 11/06/2017 15 days, 17 hours, 33 minutes and 48 seconds 09:35:01 AM 11/22/2017 BAD 10 minutes and 40 seconds
        9 09:45:41 AM 11/22/2017 8 hours, 9 minutes and 20 seconds 05:55:01 PM 11/22/2017 BAD 7 minutes and 8 seconds
        10 06:02:09 PM 11/22/2017 1 hour, 7 minutes and 54 seconds 07:10:03 PM 11/22/2017 BAD 11 minutes and 30 seconds
        11 07:21:33 PM 11/22/2017 1 hour, 58 minutes and 32 seconds 09:20:05 PM 11/22/2017 OK 5 seconds
        12 09:20:10 PM 11/22/2017 14 minutes and 52 seconds 09:35:02 PM 11/22/2017 BAD 5 minutes and 52 seconds
        13 09:40:54 PM 11/22/2017 4 minutes and 6 seconds 09:45:00 PM 11/22/2017 BAD 4 minutes and 51 seconds
        14 09:49:51 PM 11/22/2017 11 hours, 15 minutes and 10 seconds 09:05:01 AM 11/23/2017 BAD 7 minutes and 20 seconds
        15 09:12:21 AM 11/23/2017 3 days, 2 hours, 17 minutes and 40 seconds 11:30:01 AM 11/26/2017 BAD 27 minutes and 44 seconds
        16 11:57:45 AM 11/26/2017 109 days, 19 hours, 12 minutes and 37 seconds 07:10:22 AM 03/16/2018 OK 17 seconds
        17 07:10:39 AM 03/16/2018 25 days, 3 hours, 55 minutes and 59 seconds 12:06:38 PM 04/10/2018 OK 3 seconds
        18 12:06:41 PM 04/10/2018 8 days, 19 hours, 3 minutes and 20 seconds 07:10:01 AM 04/19/2018 BAD 3 minutes and 52 seconds
        19 07:13:53 AM 04/19/2018 77 days, 9 hours, 44 minutes and 39 seconds





        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%2f263486%2flinux-getting-date-time-of-system-startup%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          11 Answers
          11






          active

          oldest

          votes








          11 Answers
          11






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          37














          I found some commands here. Try who -b or last reboot | head -1.
          who gives numeric dates, while last reboot returns abbreviated day / month names.






          share|improve this answer
























          • how about if we only want the date and nothing else?

            – T0xicCode
            May 8 '12 at 3:00






          • 4





            who -b | cut -d' ' -f13 returns date only (-f14 returns time)

            – charlesbridge
            May 8 '12 at 11:15






          • 2





            Warning: last reboot did not give me the correct date ! who -b did.

            – qwertzguy
            Sep 18 '13 at 18:08











          • last reboot gave me an incorrect date too, wtmp seemed to have been rotated first day of the month

            – golimar
            Feb 17 '15 at 15:54
















          37














          I found some commands here. Try who -b or last reboot | head -1.
          who gives numeric dates, while last reboot returns abbreviated day / month names.






          share|improve this answer
























          • how about if we only want the date and nothing else?

            – T0xicCode
            May 8 '12 at 3:00






          • 4





            who -b | cut -d' ' -f13 returns date only (-f14 returns time)

            – charlesbridge
            May 8 '12 at 11:15






          • 2





            Warning: last reboot did not give me the correct date ! who -b did.

            – qwertzguy
            Sep 18 '13 at 18:08











          • last reboot gave me an incorrect date too, wtmp seemed to have been rotated first day of the month

            – golimar
            Feb 17 '15 at 15:54














          37












          37








          37







          I found some commands here. Try who -b or last reboot | head -1.
          who gives numeric dates, while last reboot returns abbreviated day / month names.






          share|improve this answer













          I found some commands here. Try who -b or last reboot | head -1.
          who gives numeric dates, while last reboot returns abbreviated day / month names.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Mar 28 '11 at 11:24









          charlesbridgecharlesbridge

          1,056712




          1,056712













          • how about if we only want the date and nothing else?

            – T0xicCode
            May 8 '12 at 3:00






          • 4





            who -b | cut -d' ' -f13 returns date only (-f14 returns time)

            – charlesbridge
            May 8 '12 at 11:15






          • 2





            Warning: last reboot did not give me the correct date ! who -b did.

            – qwertzguy
            Sep 18 '13 at 18:08











          • last reboot gave me an incorrect date too, wtmp seemed to have been rotated first day of the month

            – golimar
            Feb 17 '15 at 15:54



















          • how about if we only want the date and nothing else?

            – T0xicCode
            May 8 '12 at 3:00






          • 4





            who -b | cut -d' ' -f13 returns date only (-f14 returns time)

            – charlesbridge
            May 8 '12 at 11:15






          • 2





            Warning: last reboot did not give me the correct date ! who -b did.

            – qwertzguy
            Sep 18 '13 at 18:08











          • last reboot gave me an incorrect date too, wtmp seemed to have been rotated first day of the month

            – golimar
            Feb 17 '15 at 15:54

















          how about if we only want the date and nothing else?

          – T0xicCode
          May 8 '12 at 3:00





          how about if we only want the date and nothing else?

          – T0xicCode
          May 8 '12 at 3:00




          4




          4





          who -b | cut -d' ' -f13 returns date only (-f14 returns time)

          – charlesbridge
          May 8 '12 at 11:15





          who -b | cut -d' ' -f13 returns date only (-f14 returns time)

          – charlesbridge
          May 8 '12 at 11:15




          2




          2





          Warning: last reboot did not give me the correct date ! who -b did.

          – qwertzguy
          Sep 18 '13 at 18:08





          Warning: last reboot did not give me the correct date ! who -b did.

          – qwertzguy
          Sep 18 '13 at 18:08













          last reboot gave me an incorrect date too, wtmp seemed to have been rotated first day of the month

          – golimar
          Feb 17 '15 at 15:54





          last reboot gave me an incorrect date too, wtmp seemed to have been rotated first day of the month

          – golimar
          Feb 17 '15 at 15:54













          21














          This queries the uptime from the kernel and displays it in the local timezone:



          date -d "`cut -f1 -d. /proc/uptime` seconds ago"


          Be careful about other options. The last command will stop working as soon as wtmp has been rotated. The who command depends on the availability and integrity of utmp. And /proc/1 might have the current date instead of the boot time date, and could even be unavailable on a hardened system. Edit: dmesg only has a fixed-length back buffer, so it is unrealiable, too. The kernel logs may be in /var/log but most distributions only keep 8 weeks of them.






          share|improve this answer





















          • 1





            Interestingly, this disagrees with who -b by a minute or two on my 210-days-uptime system. Looks like who -b reports a time stamp, while this counting is somehow affected by clock drifts, even if these are periodically corrected by a running ntpd.

            – Ruslan
            Aug 27 '14 at 9:11








          • 2





            After reviewing all the alternate answers, settled on: date -d "`cut -f1 -d. /proc/uptime` seconds ago" -u (which has time/date in UTC)

            – david6
            Jan 14 '16 at 22:32













          • Phenomenal answer. If the kernel don't know, nobody knows- it's the Source of Truth for the system. The seconds make it easy to perform time calculations (I stumbled on this because I want to know "Which of my hosts didn't reboot within the last day [86,400 seconds]?")

            – Mike S
            Jun 3 '18 at 3:13
















          21














          This queries the uptime from the kernel and displays it in the local timezone:



          date -d "`cut -f1 -d. /proc/uptime` seconds ago"


          Be careful about other options. The last command will stop working as soon as wtmp has been rotated. The who command depends on the availability and integrity of utmp. And /proc/1 might have the current date instead of the boot time date, and could even be unavailable on a hardened system. Edit: dmesg only has a fixed-length back buffer, so it is unrealiable, too. The kernel logs may be in /var/log but most distributions only keep 8 weeks of them.






          share|improve this answer





















          • 1





            Interestingly, this disagrees with who -b by a minute or two on my 210-days-uptime system. Looks like who -b reports a time stamp, while this counting is somehow affected by clock drifts, even if these are periodically corrected by a running ntpd.

            – Ruslan
            Aug 27 '14 at 9:11








          • 2





            After reviewing all the alternate answers, settled on: date -d "`cut -f1 -d. /proc/uptime` seconds ago" -u (which has time/date in UTC)

            – david6
            Jan 14 '16 at 22:32













          • Phenomenal answer. If the kernel don't know, nobody knows- it's the Source of Truth for the system. The seconds make it easy to perform time calculations (I stumbled on this because I want to know "Which of my hosts didn't reboot within the last day [86,400 seconds]?")

            – Mike S
            Jun 3 '18 at 3:13














          21












          21








          21







          This queries the uptime from the kernel and displays it in the local timezone:



          date -d "`cut -f1 -d. /proc/uptime` seconds ago"


          Be careful about other options. The last command will stop working as soon as wtmp has been rotated. The who command depends on the availability and integrity of utmp. And /proc/1 might have the current date instead of the boot time date, and could even be unavailable on a hardened system. Edit: dmesg only has a fixed-length back buffer, so it is unrealiable, too. The kernel logs may be in /var/log but most distributions only keep 8 weeks of them.






          share|improve this answer















          This queries the uptime from the kernel and displays it in the local timezone:



          date -d "`cut -f1 -d. /proc/uptime` seconds ago"


          Be careful about other options. The last command will stop working as soon as wtmp has been rotated. The who command depends on the availability and integrity of utmp. And /proc/1 might have the current date instead of the boot time date, and could even be unavailable on a hardened system. Edit: dmesg only has a fixed-length back buffer, so it is unrealiable, too. The kernel logs may be in /var/log but most distributions only keep 8 weeks of them.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Mar 28 '11 at 14:31

























          answered Mar 28 '11 at 12:37









          sam hocevarsam hocevar

          1,196814




          1,196814








          • 1





            Interestingly, this disagrees with who -b by a minute or two on my 210-days-uptime system. Looks like who -b reports a time stamp, while this counting is somehow affected by clock drifts, even if these are periodically corrected by a running ntpd.

            – Ruslan
            Aug 27 '14 at 9:11








          • 2





            After reviewing all the alternate answers, settled on: date -d "`cut -f1 -d. /proc/uptime` seconds ago" -u (which has time/date in UTC)

            – david6
            Jan 14 '16 at 22:32













          • Phenomenal answer. If the kernel don't know, nobody knows- it's the Source of Truth for the system. The seconds make it easy to perform time calculations (I stumbled on this because I want to know "Which of my hosts didn't reboot within the last day [86,400 seconds]?")

            – Mike S
            Jun 3 '18 at 3:13














          • 1





            Interestingly, this disagrees with who -b by a minute or two on my 210-days-uptime system. Looks like who -b reports a time stamp, while this counting is somehow affected by clock drifts, even if these are periodically corrected by a running ntpd.

            – Ruslan
            Aug 27 '14 at 9:11








          • 2





            After reviewing all the alternate answers, settled on: date -d "`cut -f1 -d. /proc/uptime` seconds ago" -u (which has time/date in UTC)

            – david6
            Jan 14 '16 at 22:32













          • Phenomenal answer. If the kernel don't know, nobody knows- it's the Source of Truth for the system. The seconds make it easy to perform time calculations (I stumbled on this because I want to know "Which of my hosts didn't reboot within the last day [86,400 seconds]?")

            – Mike S
            Jun 3 '18 at 3:13








          1




          1





          Interestingly, this disagrees with who -b by a minute or two on my 210-days-uptime system. Looks like who -b reports a time stamp, while this counting is somehow affected by clock drifts, even if these are periodically corrected by a running ntpd.

          – Ruslan
          Aug 27 '14 at 9:11







          Interestingly, this disagrees with who -b by a minute or two on my 210-days-uptime system. Looks like who -b reports a time stamp, while this counting is somehow affected by clock drifts, even if these are periodically corrected by a running ntpd.

          – Ruslan
          Aug 27 '14 at 9:11






          2




          2





          After reviewing all the alternate answers, settled on: date -d "`cut -f1 -d. /proc/uptime` seconds ago" -u (which has time/date in UTC)

          – david6
          Jan 14 '16 at 22:32







          After reviewing all the alternate answers, settled on: date -d "`cut -f1 -d. /proc/uptime` seconds ago" -u (which has time/date in UTC)

          – david6
          Jan 14 '16 at 22:32















          Phenomenal answer. If the kernel don't know, nobody knows- it's the Source of Truth for the system. The seconds make it easy to perform time calculations (I stumbled on this because I want to know "Which of my hosts didn't reboot within the last day [86,400 seconds]?")

          – Mike S
          Jun 3 '18 at 3:13





          Phenomenal answer. If the kernel don't know, nobody knows- it's the Source of Truth for the system. The seconds make it easy to perform time calculations (I stumbled on this because I want to know "Which of my hosts didn't reboot within the last day [86,400 seconds]?")

          – Mike S
          Jun 3 '18 at 3:13











          14














          I stumbled on this question while looking for a way to get a consistent, parseable boot time, as opposed to time since boot which changes on every call.



          It appears that uptime -s will do the trick on most linux systems.






          share|improve this answer
























          • uptime -s outputs e.g. 2017-08-09 01:23:45. This is best, by being simplest. This command is included in the package "procps".

            – teika kazura
            Apr 8 '18 at 12:34











          • The uptime in CentOS 6 (procps version 3.2.8) does not seem to support this, sadly.

            – mwfearnley
            Dec 3 '18 at 10:43
















          14














          I stumbled on this question while looking for a way to get a consistent, parseable boot time, as opposed to time since boot which changes on every call.



          It appears that uptime -s will do the trick on most linux systems.






          share|improve this answer
























          • uptime -s outputs e.g. 2017-08-09 01:23:45. This is best, by being simplest. This command is included in the package "procps".

            – teika kazura
            Apr 8 '18 at 12:34











          • The uptime in CentOS 6 (procps version 3.2.8) does not seem to support this, sadly.

            – mwfearnley
            Dec 3 '18 at 10:43














          14












          14








          14







          I stumbled on this question while looking for a way to get a consistent, parseable boot time, as opposed to time since boot which changes on every call.



          It appears that uptime -s will do the trick on most linux systems.






          share|improve this answer













          I stumbled on this question while looking for a way to get a consistent, parseable boot time, as opposed to time since boot which changes on every call.



          It appears that uptime -s will do the trick on most linux systems.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 1 '14 at 20:52









          mikegreilingmikegreiling

          24124




          24124













          • uptime -s outputs e.g. 2017-08-09 01:23:45. This is best, by being simplest. This command is included in the package "procps".

            – teika kazura
            Apr 8 '18 at 12:34











          • The uptime in CentOS 6 (procps version 3.2.8) does not seem to support this, sadly.

            – mwfearnley
            Dec 3 '18 at 10:43



















          • uptime -s outputs e.g. 2017-08-09 01:23:45. This is best, by being simplest. This command is included in the package "procps".

            – teika kazura
            Apr 8 '18 at 12:34











          • The uptime in CentOS 6 (procps version 3.2.8) does not seem to support this, sadly.

            – mwfearnley
            Dec 3 '18 at 10:43

















          uptime -s outputs e.g. 2017-08-09 01:23:45. This is best, by being simplest. This command is included in the package "procps".

          – teika kazura
          Apr 8 '18 at 12:34





          uptime -s outputs e.g. 2017-08-09 01:23:45. This is best, by being simplest. This command is included in the package "procps".

          – teika kazura
          Apr 8 '18 at 12:34













          The uptime in CentOS 6 (procps version 3.2.8) does not seem to support this, sadly.

          – mwfearnley
          Dec 3 '18 at 10:43





          The uptime in CentOS 6 (procps version 3.2.8) does not seem to support this, sadly.

          – mwfearnley
          Dec 3 '18 at 10:43











          10














          I found the btime line in /proc/stat when poking around a bit



          cat /proc/stat | grep btime | awk '{ print $2 }'


          and after a quick search, I found this page: /proc/stat explained, which outlines the "Various pieces of information about kernel activity that are available in the
          /proc/stat file."




          The "btime" line gives the time at which the system booted, in seconds since
          the Unix epoch.







          share|improve this answer





















          • 1





            Seems a lot easier to write awk '/btime/{print $2}' /proc/stat

            – William Pursell
            Jun 12 '17 at 14:07











          • @WilliamPursell easiest is always what you already know. I am no awk wizard. :P

            – Oddstr13
            Jun 12 '17 at 19:37











          • Good point. However, you used cat gratuitously. Just grep from the file.

            – Mike S
            Jun 3 '18 at 3:18











          • @MikeS correct – however, I still stand by my original command chain as a clear representation of where the information is found, even 7 years after my answer.

            – Oddstr13
            Jun 3 '18 at 8:20
















          10














          I found the btime line in /proc/stat when poking around a bit



          cat /proc/stat | grep btime | awk '{ print $2 }'


          and after a quick search, I found this page: /proc/stat explained, which outlines the "Various pieces of information about kernel activity that are available in the
          /proc/stat file."




          The "btime" line gives the time at which the system booted, in seconds since
          the Unix epoch.







          share|improve this answer





















          • 1





            Seems a lot easier to write awk '/btime/{print $2}' /proc/stat

            – William Pursell
            Jun 12 '17 at 14:07











          • @WilliamPursell easiest is always what you already know. I am no awk wizard. :P

            – Oddstr13
            Jun 12 '17 at 19:37











          • Good point. However, you used cat gratuitously. Just grep from the file.

            – Mike S
            Jun 3 '18 at 3:18











          • @MikeS correct – however, I still stand by my original command chain as a clear representation of where the information is found, even 7 years after my answer.

            – Oddstr13
            Jun 3 '18 at 8:20














          10












          10








          10







          I found the btime line in /proc/stat when poking around a bit



          cat /proc/stat | grep btime | awk '{ print $2 }'


          and after a quick search, I found this page: /proc/stat explained, which outlines the "Various pieces of information about kernel activity that are available in the
          /proc/stat file."




          The "btime" line gives the time at which the system booted, in seconds since
          the Unix epoch.







          share|improve this answer















          I found the btime line in /proc/stat when poking around a bit



          cat /proc/stat | grep btime | awk '{ print $2 }'


          and after a quick search, I found this page: /proc/stat explained, which outlines the "Various pieces of information about kernel activity that are available in the
          /proc/stat file."




          The "btime" line gives the time at which the system booted, in seconds since
          the Unix epoch.








          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Jul 8 '16 at 22:35

























          answered Aug 30 '11 at 20:30









          Oddstr13Oddstr13

          15127




          15127








          • 1





            Seems a lot easier to write awk '/btime/{print $2}' /proc/stat

            – William Pursell
            Jun 12 '17 at 14:07











          • @WilliamPursell easiest is always what you already know. I am no awk wizard. :P

            – Oddstr13
            Jun 12 '17 at 19:37











          • Good point. However, you used cat gratuitously. Just grep from the file.

            – Mike S
            Jun 3 '18 at 3:18











          • @MikeS correct – however, I still stand by my original command chain as a clear representation of where the information is found, even 7 years after my answer.

            – Oddstr13
            Jun 3 '18 at 8:20














          • 1





            Seems a lot easier to write awk '/btime/{print $2}' /proc/stat

            – William Pursell
            Jun 12 '17 at 14:07











          • @WilliamPursell easiest is always what you already know. I am no awk wizard. :P

            – Oddstr13
            Jun 12 '17 at 19:37











          • Good point. However, you used cat gratuitously. Just grep from the file.

            – Mike S
            Jun 3 '18 at 3:18











          • @MikeS correct – however, I still stand by my original command chain as a clear representation of where the information is found, even 7 years after my answer.

            – Oddstr13
            Jun 3 '18 at 8:20








          1




          1





          Seems a lot easier to write awk '/btime/{print $2}' /proc/stat

          – William Pursell
          Jun 12 '17 at 14:07





          Seems a lot easier to write awk '/btime/{print $2}' /proc/stat

          – William Pursell
          Jun 12 '17 at 14:07













          @WilliamPursell easiest is always what you already know. I am no awk wizard. :P

          – Oddstr13
          Jun 12 '17 at 19:37





          @WilliamPursell easiest is always what you already know. I am no awk wizard. :P

          – Oddstr13
          Jun 12 '17 at 19:37













          Good point. However, you used cat gratuitously. Just grep from the file.

          – Mike S
          Jun 3 '18 at 3:18





          Good point. However, you used cat gratuitously. Just grep from the file.

          – Mike S
          Jun 3 '18 at 3:18













          @MikeS correct – however, I still stand by my original command chain as a clear representation of where the information is found, even 7 years after my answer.

          – Oddstr13
          Jun 3 '18 at 8:20





          @MikeS correct – however, I still stand by my original command chain as a clear representation of where the information is found, even 7 years after my answer.

          – Oddstr13
          Jun 3 '18 at 8:20











          7
















          • good: uptime -s, who -b or parsing /proc/uptime


          • bad: ls -ld /proc/1 and variants.


          Don't use ls -ld /proc/1 for this purpose. It's sometimes updated after s2disk or s2ram.



          In my case, who -b said:



          system boot May 2 09:51



          While ls -ld /proc/1:



          dr-xr-xr-x 7 root root 0 May 3 13:09 /proc/1



          ls -ld for /proc or /sys seem to persist after resuming, but it's implementation dependent, and may change in future, so don't use such methods. And if your system clock is in localtime, not UTC, they have negative offset.



          (I don't have the privilege to comment to answers yet, so opened a new answer. Sorry.)



          EDIT: uptime -s was first answered in this answer by mikegreiling






          share|improve this answer






























            7
















            • good: uptime -s, who -b or parsing /proc/uptime


            • bad: ls -ld /proc/1 and variants.


            Don't use ls -ld /proc/1 for this purpose. It's sometimes updated after s2disk or s2ram.



            In my case, who -b said:



            system boot May 2 09:51



            While ls -ld /proc/1:



            dr-xr-xr-x 7 root root 0 May 3 13:09 /proc/1



            ls -ld for /proc or /sys seem to persist after resuming, but it's implementation dependent, and may change in future, so don't use such methods. And if your system clock is in localtime, not UTC, they have negative offset.



            (I don't have the privilege to comment to answers yet, so opened a new answer. Sorry.)



            EDIT: uptime -s was first answered in this answer by mikegreiling






            share|improve this answer




























              7












              7








              7









              • good: uptime -s, who -b or parsing /proc/uptime


              • bad: ls -ld /proc/1 and variants.


              Don't use ls -ld /proc/1 for this purpose. It's sometimes updated after s2disk or s2ram.



              In my case, who -b said:



              system boot May 2 09:51



              While ls -ld /proc/1:



              dr-xr-xr-x 7 root root 0 May 3 13:09 /proc/1



              ls -ld for /proc or /sys seem to persist after resuming, but it's implementation dependent, and may change in future, so don't use such methods. And if your system clock is in localtime, not UTC, they have negative offset.



              (I don't have the privilege to comment to answers yet, so opened a new answer. Sorry.)



              EDIT: uptime -s was first answered in this answer by mikegreiling






              share|improve this answer

















              • good: uptime -s, who -b or parsing /proc/uptime


              • bad: ls -ld /proc/1 and variants.


              Don't use ls -ld /proc/1 for this purpose. It's sometimes updated after s2disk or s2ram.



              In my case, who -b said:



              system boot May 2 09:51



              While ls -ld /proc/1:



              dr-xr-xr-x 7 root root 0 May 3 13:09 /proc/1



              ls -ld for /proc or /sys seem to persist after resuming, but it's implementation dependent, and may change in future, so don't use such methods. And if your system clock is in localtime, not UTC, they have negative offset.



              (I don't have the privilege to comment to answers yet, so opened a new answer. Sorry.)



              EDIT: uptime -s was first answered in this answer by mikegreiling







              share|improve this answer














              share|improve this answer



              share|improve this answer








              edited Apr 8 '18 at 12:29

























              answered May 10 '12 at 7:41









              teika kazurateika kazura

              465510




              465510























                  2














                  The simplest way is to look to see when /sbin/init started (that's always the first process to be started after the kernel loads):



                  # ls -ld /proc/1
                  dr-xr-xr-x 7 root root 0 2011-03-27 23:54 /proc/1


                  So I can see that my machine booted up at 6 minutes to midnight on the 27th of March 2011.



                  If you want to use it in scripting you can use the stat command instead:



                  # stat --printf='%Y' /proc/1
                  1301266491


                  The %Y specifies the time since the directory was last changed (process creation time) in seconds since the epoch (1/1/70) and is a standard unix timestamp.






                  share|improve this answer



















                  • 1





                    Unfortunately this doesn't work: the mtime on those folders can change for other reasons (I have a system here that has a 5 day uptime and the mtime of /proc/1 is 25 minutes ago)

                    – kdt
                    Dec 18 '12 at 13:10






                  • 1





                    It's not reliable, as explained in my answer

                    – teika kazura
                    Feb 13 '15 at 5:46


















                  2














                  The simplest way is to look to see when /sbin/init started (that's always the first process to be started after the kernel loads):



                  # ls -ld /proc/1
                  dr-xr-xr-x 7 root root 0 2011-03-27 23:54 /proc/1


                  So I can see that my machine booted up at 6 minutes to midnight on the 27th of March 2011.



                  If you want to use it in scripting you can use the stat command instead:



                  # stat --printf='%Y' /proc/1
                  1301266491


                  The %Y specifies the time since the directory was last changed (process creation time) in seconds since the epoch (1/1/70) and is a standard unix timestamp.






                  share|improve this answer



















                  • 1





                    Unfortunately this doesn't work: the mtime on those folders can change for other reasons (I have a system here that has a 5 day uptime and the mtime of /proc/1 is 25 minutes ago)

                    – kdt
                    Dec 18 '12 at 13:10






                  • 1





                    It's not reliable, as explained in my answer

                    – teika kazura
                    Feb 13 '15 at 5:46
















                  2












                  2








                  2







                  The simplest way is to look to see when /sbin/init started (that's always the first process to be started after the kernel loads):



                  # ls -ld /proc/1
                  dr-xr-xr-x 7 root root 0 2011-03-27 23:54 /proc/1


                  So I can see that my machine booted up at 6 minutes to midnight on the 27th of March 2011.



                  If you want to use it in scripting you can use the stat command instead:



                  # stat --printf='%Y' /proc/1
                  1301266491


                  The %Y specifies the time since the directory was last changed (process creation time) in seconds since the epoch (1/1/70) and is a standard unix timestamp.






                  share|improve this answer













                  The simplest way is to look to see when /sbin/init started (that's always the first process to be started after the kernel loads):



                  # ls -ld /proc/1
                  dr-xr-xr-x 7 root root 0 2011-03-27 23:54 /proc/1


                  So I can see that my machine booted up at 6 minutes to midnight on the 27th of March 2011.



                  If you want to use it in scripting you can use the stat command instead:



                  # stat --printf='%Y' /proc/1
                  1301266491


                  The %Y specifies the time since the directory was last changed (process creation time) in seconds since the epoch (1/1/70) and is a standard unix timestamp.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Mar 28 '11 at 11:27









                  MajenkoMajenko

                  27.1k34472




                  27.1k34472








                  • 1





                    Unfortunately this doesn't work: the mtime on those folders can change for other reasons (I have a system here that has a 5 day uptime and the mtime of /proc/1 is 25 minutes ago)

                    – kdt
                    Dec 18 '12 at 13:10






                  • 1





                    It's not reliable, as explained in my answer

                    – teika kazura
                    Feb 13 '15 at 5:46
















                  • 1





                    Unfortunately this doesn't work: the mtime on those folders can change for other reasons (I have a system here that has a 5 day uptime and the mtime of /proc/1 is 25 minutes ago)

                    – kdt
                    Dec 18 '12 at 13:10






                  • 1





                    It's not reliable, as explained in my answer

                    – teika kazura
                    Feb 13 '15 at 5:46










                  1




                  1





                  Unfortunately this doesn't work: the mtime on those folders can change for other reasons (I have a system here that has a 5 day uptime and the mtime of /proc/1 is 25 minutes ago)

                  – kdt
                  Dec 18 '12 at 13:10





                  Unfortunately this doesn't work: the mtime on those folders can change for other reasons (I have a system here that has a 5 day uptime and the mtime of /proc/1 is 25 minutes ago)

                  – kdt
                  Dec 18 '12 at 13:10




                  1




                  1





                  It's not reliable, as explained in my answer

                  – teika kazura
                  Feb 13 '15 at 5:46







                  It's not reliable, as explained in my answer

                  – teika kazura
                  Feb 13 '15 at 5:46













                  1














                  In Linux,



                  ls -ld /proc


                  seems to give me what I need. The post above is odd. /proc/uptime does not contain a date value – it would have to be subtracted from the current time. Maybe he meant:



                  date -d @$(( $(date +%s) - $(cut -f1 -d. /proc/uptime) ))





                  share|improve this answer


























                  • uptime -s provides a date value

                    – mikegreiling
                    Nov 1 '14 at 20:56
















                  1














                  In Linux,



                  ls -ld /proc


                  seems to give me what I need. The post above is odd. /proc/uptime does not contain a date value – it would have to be subtracted from the current time. Maybe he meant:



                  date -d @$(( $(date +%s) - $(cut -f1 -d. /proc/uptime) ))





                  share|improve this answer


























                  • uptime -s provides a date value

                    – mikegreiling
                    Nov 1 '14 at 20:56














                  1












                  1








                  1







                  In Linux,



                  ls -ld /proc


                  seems to give me what I need. The post above is odd. /proc/uptime does not contain a date value – it would have to be subtracted from the current time. Maybe he meant:



                  date -d @$(( $(date +%s) - $(cut -f1 -d. /proc/uptime) ))





                  share|improve this answer















                  In Linux,



                  ls -ld /proc


                  seems to give me what I need. The post above is odd. /proc/uptime does not contain a date value – it would have to be subtracted from the current time. Maybe he meant:



                  date -d @$(( $(date +%s) - $(cut -f1 -d. /proc/uptime) ))






                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited May 16 '11 at 18:37









                  slhck

                  160k47444466




                  160k47444466










                  answered May 16 '11 at 17:29









                  gerrygerry

                  111




                  111













                  • uptime -s provides a date value

                    – mikegreiling
                    Nov 1 '14 at 20:56



















                  • uptime -s provides a date value

                    – mikegreiling
                    Nov 1 '14 at 20:56

















                  uptime -s provides a date value

                  – mikegreiling
                  Nov 1 '14 at 20:56





                  uptime -s provides a date value

                  – mikegreiling
                  Nov 1 '14 at 20:56











                  1














                  Under Bash, without pipes nor other processes; just text:





                  $ REPLY="$(</proc/uptime)"
                  $ REPLY="${REPLY%%.*}"
                  $ echo "$REPLY"
                  31207


                  (Just reused the REPLY default variable, but you can choose whatever you need)






                  share|improve this answer
























                  • Sure, Why not? Kinda clever use of variable substringiness. Cool. +1. Thanks for the idea!

                    – Mike S
                    Jun 3 '18 at 3:24
















                  1














                  Under Bash, without pipes nor other processes; just text:





                  $ REPLY="$(</proc/uptime)"
                  $ REPLY="${REPLY%%.*}"
                  $ echo "$REPLY"
                  31207


                  (Just reused the REPLY default variable, but you can choose whatever you need)






                  share|improve this answer
























                  • Sure, Why not? Kinda clever use of variable substringiness. Cool. +1. Thanks for the idea!

                    – Mike S
                    Jun 3 '18 at 3:24














                  1












                  1








                  1







                  Under Bash, without pipes nor other processes; just text:





                  $ REPLY="$(</proc/uptime)"
                  $ REPLY="${REPLY%%.*}"
                  $ echo "$REPLY"
                  31207


                  (Just reused the REPLY default variable, but you can choose whatever you need)






                  share|improve this answer













                  Under Bash, without pipes nor other processes; just text:





                  $ REPLY="$(</proc/uptime)"
                  $ REPLY="${REPLY%%.*}"
                  $ echo "$REPLY"
                  31207


                  (Just reused the REPLY default variable, but you can choose whatever you need)







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Sep 12 '17 at 18:41









                  LuchosteinLuchostein

                  1114




                  1114













                  • Sure, Why not? Kinda clever use of variable substringiness. Cool. +1. Thanks for the idea!

                    – Mike S
                    Jun 3 '18 at 3:24



















                  • Sure, Why not? Kinda clever use of variable substringiness. Cool. +1. Thanks for the idea!

                    – Mike S
                    Jun 3 '18 at 3:24

















                  Sure, Why not? Kinda clever use of variable substringiness. Cool. +1. Thanks for the idea!

                  – Mike S
                  Jun 3 '18 at 3:24





                  Sure, Why not? Kinda clever use of variable substringiness. Cool. +1. Thanks for the idea!

                  – Mike S
                  Jun 3 '18 at 3:24











                  0














                  date -d @$(sed -n '/^btime /s///p' /proc/stat)


                  (yet another way to do this, which is useful in certain circumstances)






                  share|improve this answer




























                    0














                    date -d @$(sed -n '/^btime /s///p' /proc/stat)


                    (yet another way to do this, which is useful in certain circumstances)






                    share|improve this answer


























                      0












                      0








                      0







                      date -d @$(sed -n '/^btime /s///p' /proc/stat)


                      (yet another way to do this, which is useful in certain circumstances)






                      share|improve this answer













                      date -d @$(sed -n '/^btime /s///p' /proc/stat)


                      (yet another way to do this, which is useful in certain circumstances)







                      share|improve this answer












                      share|improve this answer



                      share|improve this answer










                      answered Dec 4 '14 at 14:06









                      AmanicAAmanicA

                      1013




                      1013























                          0














                          Command:



                          (echo ' Currently:' | tr "n" ' ' ; date +"%Y-%m-%d %k:%M:%S" ; echo '  Up Since:' | tr 'n' ' ' ; uptime -s ; echo '  Duration:' | tr 'n' ' ' ; uptime -p)


                          Output:



                           Currently: 2016-05-09  9:06:29
                          Up Since: 2016-05-04 12:56:04
                          Duration: up 4 days, 20 hours, 10 minutes





                          share|improve this answer






























                            0














                            Command:



                            (echo ' Currently:' | tr "n" ' ' ; date +"%Y-%m-%d %k:%M:%S" ; echo '  Up Since:' | tr 'n' ' ' ; uptime -s ; echo '  Duration:' | tr 'n' ' ' ; uptime -p)


                            Output:



                             Currently: 2016-05-09  9:06:29
                            Up Since: 2016-05-04 12:56:04
                            Duration: up 4 days, 20 hours, 10 minutes





                            share|improve this answer




























                              0












                              0








                              0







                              Command:



                              (echo ' Currently:' | tr "n" ' ' ; date +"%Y-%m-%d %k:%M:%S" ; echo '  Up Since:' | tr 'n' ' ' ; uptime -s ; echo '  Duration:' | tr 'n' ' ' ; uptime -p)


                              Output:



                               Currently: 2016-05-09  9:06:29
                              Up Since: 2016-05-04 12:56:04
                              Duration: up 4 days, 20 hours, 10 minutes





                              share|improve this answer















                              Command:



                              (echo ' Currently:' | tr "n" ' ' ; date +"%Y-%m-%d %k:%M:%S" ; echo '  Up Since:' | tr 'n' ' ' ; uptime -s ; echo '  Duration:' | tr 'n' ' ' ; uptime -p)


                              Output:



                               Currently: 2016-05-09  9:06:29
                              Up Since: 2016-05-04 12:56:04
                              Duration: up 4 days, 20 hours, 10 minutes






                              share|improve this answer














                              share|improve this answer



                              share|improve this answer








                              edited May 9 '16 at 14:07

























                              answered May 9 '16 at 13:46









                              LonnieBestLonnieBest

                              58222033




                              58222033























                                  0














                                  Clear and concise with tuptime command:



                                  # tuptime -t
                                  No. Startup Date Uptime Shutdown Date End Downtime

                                  1 09:43:39 AM 08/08/2017 41 days, 0 hours, 51 minutes and 2 seconds 10:34:41 AM 09/18/2017 OK 10 seconds
                                  2 10:34:51 AM 09/18/2017 1 minute and 16 seconds 10:36:07 AM 09/18/2017 OK 1 second
                                  3 10:36:08 AM 09/18/2017 13 minutes and 20 seconds 10:49:28 AM 09/18/2017 OK 3 seconds
                                  4 10:49:31 AM 09/18/2017 45 days, 0 hours, 1 minute and 20 seconds 09:50:51 AM 11/02/2017 OK 4 seconds
                                  5 09:50:55 AM 11/02/2017 27 minutes and 25 seconds 10:18:20 AM 11/02/2017 OK 4 seconds
                                  6 10:18:24 AM 11/02/2017 9 seconds 10:18:33 AM 11/02/2017 OK 9 seconds
                                  7 10:18:42 AM 11/02/2017 4 days, 5 hours, 41 minutes and 47 seconds 04:00:29 PM 11/06/2017 OK 44 seconds
                                  8 04:01:13 PM 11/06/2017 15 days, 17 hours, 33 minutes and 48 seconds 09:35:01 AM 11/22/2017 BAD 10 minutes and 40 seconds
                                  9 09:45:41 AM 11/22/2017 8 hours, 9 minutes and 20 seconds 05:55:01 PM 11/22/2017 BAD 7 minutes and 8 seconds
                                  10 06:02:09 PM 11/22/2017 1 hour, 7 minutes and 54 seconds 07:10:03 PM 11/22/2017 BAD 11 minutes and 30 seconds
                                  11 07:21:33 PM 11/22/2017 1 hour, 58 minutes and 32 seconds 09:20:05 PM 11/22/2017 OK 5 seconds
                                  12 09:20:10 PM 11/22/2017 14 minutes and 52 seconds 09:35:02 PM 11/22/2017 BAD 5 minutes and 52 seconds
                                  13 09:40:54 PM 11/22/2017 4 minutes and 6 seconds 09:45:00 PM 11/22/2017 BAD 4 minutes and 51 seconds
                                  14 09:49:51 PM 11/22/2017 11 hours, 15 minutes and 10 seconds 09:05:01 AM 11/23/2017 BAD 7 minutes and 20 seconds
                                  15 09:12:21 AM 11/23/2017 3 days, 2 hours, 17 minutes and 40 seconds 11:30:01 AM 11/26/2017 BAD 27 minutes and 44 seconds
                                  16 11:57:45 AM 11/26/2017 109 days, 19 hours, 12 minutes and 37 seconds 07:10:22 AM 03/16/2018 OK 17 seconds
                                  17 07:10:39 AM 03/16/2018 25 days, 3 hours, 55 minutes and 59 seconds 12:06:38 PM 04/10/2018 OK 3 seconds
                                  18 12:06:41 PM 04/10/2018 8 days, 19 hours, 3 minutes and 20 seconds 07:10:01 AM 04/19/2018 BAD 3 minutes and 52 seconds
                                  19 07:13:53 AM 04/19/2018 77 days, 9 hours, 44 minutes and 39 seconds





                                  share|improve this answer




























                                    0














                                    Clear and concise with tuptime command:



                                    # tuptime -t
                                    No. Startup Date Uptime Shutdown Date End Downtime

                                    1 09:43:39 AM 08/08/2017 41 days, 0 hours, 51 minutes and 2 seconds 10:34:41 AM 09/18/2017 OK 10 seconds
                                    2 10:34:51 AM 09/18/2017 1 minute and 16 seconds 10:36:07 AM 09/18/2017 OK 1 second
                                    3 10:36:08 AM 09/18/2017 13 minutes and 20 seconds 10:49:28 AM 09/18/2017 OK 3 seconds
                                    4 10:49:31 AM 09/18/2017 45 days, 0 hours, 1 minute and 20 seconds 09:50:51 AM 11/02/2017 OK 4 seconds
                                    5 09:50:55 AM 11/02/2017 27 minutes and 25 seconds 10:18:20 AM 11/02/2017 OK 4 seconds
                                    6 10:18:24 AM 11/02/2017 9 seconds 10:18:33 AM 11/02/2017 OK 9 seconds
                                    7 10:18:42 AM 11/02/2017 4 days, 5 hours, 41 minutes and 47 seconds 04:00:29 PM 11/06/2017 OK 44 seconds
                                    8 04:01:13 PM 11/06/2017 15 days, 17 hours, 33 minutes and 48 seconds 09:35:01 AM 11/22/2017 BAD 10 minutes and 40 seconds
                                    9 09:45:41 AM 11/22/2017 8 hours, 9 minutes and 20 seconds 05:55:01 PM 11/22/2017 BAD 7 minutes and 8 seconds
                                    10 06:02:09 PM 11/22/2017 1 hour, 7 minutes and 54 seconds 07:10:03 PM 11/22/2017 BAD 11 minutes and 30 seconds
                                    11 07:21:33 PM 11/22/2017 1 hour, 58 minutes and 32 seconds 09:20:05 PM 11/22/2017 OK 5 seconds
                                    12 09:20:10 PM 11/22/2017 14 minutes and 52 seconds 09:35:02 PM 11/22/2017 BAD 5 minutes and 52 seconds
                                    13 09:40:54 PM 11/22/2017 4 minutes and 6 seconds 09:45:00 PM 11/22/2017 BAD 4 minutes and 51 seconds
                                    14 09:49:51 PM 11/22/2017 11 hours, 15 minutes and 10 seconds 09:05:01 AM 11/23/2017 BAD 7 minutes and 20 seconds
                                    15 09:12:21 AM 11/23/2017 3 days, 2 hours, 17 minutes and 40 seconds 11:30:01 AM 11/26/2017 BAD 27 minutes and 44 seconds
                                    16 11:57:45 AM 11/26/2017 109 days, 19 hours, 12 minutes and 37 seconds 07:10:22 AM 03/16/2018 OK 17 seconds
                                    17 07:10:39 AM 03/16/2018 25 days, 3 hours, 55 minutes and 59 seconds 12:06:38 PM 04/10/2018 OK 3 seconds
                                    18 12:06:41 PM 04/10/2018 8 days, 19 hours, 3 minutes and 20 seconds 07:10:01 AM 04/19/2018 BAD 3 minutes and 52 seconds
                                    19 07:13:53 AM 04/19/2018 77 days, 9 hours, 44 minutes and 39 seconds





                                    share|improve this answer


























                                      0












                                      0








                                      0







                                      Clear and concise with tuptime command:



                                      # tuptime -t
                                      No. Startup Date Uptime Shutdown Date End Downtime

                                      1 09:43:39 AM 08/08/2017 41 days, 0 hours, 51 minutes and 2 seconds 10:34:41 AM 09/18/2017 OK 10 seconds
                                      2 10:34:51 AM 09/18/2017 1 minute and 16 seconds 10:36:07 AM 09/18/2017 OK 1 second
                                      3 10:36:08 AM 09/18/2017 13 minutes and 20 seconds 10:49:28 AM 09/18/2017 OK 3 seconds
                                      4 10:49:31 AM 09/18/2017 45 days, 0 hours, 1 minute and 20 seconds 09:50:51 AM 11/02/2017 OK 4 seconds
                                      5 09:50:55 AM 11/02/2017 27 minutes and 25 seconds 10:18:20 AM 11/02/2017 OK 4 seconds
                                      6 10:18:24 AM 11/02/2017 9 seconds 10:18:33 AM 11/02/2017 OK 9 seconds
                                      7 10:18:42 AM 11/02/2017 4 days, 5 hours, 41 minutes and 47 seconds 04:00:29 PM 11/06/2017 OK 44 seconds
                                      8 04:01:13 PM 11/06/2017 15 days, 17 hours, 33 minutes and 48 seconds 09:35:01 AM 11/22/2017 BAD 10 minutes and 40 seconds
                                      9 09:45:41 AM 11/22/2017 8 hours, 9 minutes and 20 seconds 05:55:01 PM 11/22/2017 BAD 7 minutes and 8 seconds
                                      10 06:02:09 PM 11/22/2017 1 hour, 7 minutes and 54 seconds 07:10:03 PM 11/22/2017 BAD 11 minutes and 30 seconds
                                      11 07:21:33 PM 11/22/2017 1 hour, 58 minutes and 32 seconds 09:20:05 PM 11/22/2017 OK 5 seconds
                                      12 09:20:10 PM 11/22/2017 14 minutes and 52 seconds 09:35:02 PM 11/22/2017 BAD 5 minutes and 52 seconds
                                      13 09:40:54 PM 11/22/2017 4 minutes and 6 seconds 09:45:00 PM 11/22/2017 BAD 4 minutes and 51 seconds
                                      14 09:49:51 PM 11/22/2017 11 hours, 15 minutes and 10 seconds 09:05:01 AM 11/23/2017 BAD 7 minutes and 20 seconds
                                      15 09:12:21 AM 11/23/2017 3 days, 2 hours, 17 minutes and 40 seconds 11:30:01 AM 11/26/2017 BAD 27 minutes and 44 seconds
                                      16 11:57:45 AM 11/26/2017 109 days, 19 hours, 12 minutes and 37 seconds 07:10:22 AM 03/16/2018 OK 17 seconds
                                      17 07:10:39 AM 03/16/2018 25 days, 3 hours, 55 minutes and 59 seconds 12:06:38 PM 04/10/2018 OK 3 seconds
                                      18 12:06:41 PM 04/10/2018 8 days, 19 hours, 3 minutes and 20 seconds 07:10:01 AM 04/19/2018 BAD 3 minutes and 52 seconds
                                      19 07:13:53 AM 04/19/2018 77 days, 9 hours, 44 minutes and 39 seconds





                                      share|improve this answer













                                      Clear and concise with tuptime command:



                                      # tuptime -t
                                      No. Startup Date Uptime Shutdown Date End Downtime

                                      1 09:43:39 AM 08/08/2017 41 days, 0 hours, 51 minutes and 2 seconds 10:34:41 AM 09/18/2017 OK 10 seconds
                                      2 10:34:51 AM 09/18/2017 1 minute and 16 seconds 10:36:07 AM 09/18/2017 OK 1 second
                                      3 10:36:08 AM 09/18/2017 13 minutes and 20 seconds 10:49:28 AM 09/18/2017 OK 3 seconds
                                      4 10:49:31 AM 09/18/2017 45 days, 0 hours, 1 minute and 20 seconds 09:50:51 AM 11/02/2017 OK 4 seconds
                                      5 09:50:55 AM 11/02/2017 27 minutes and 25 seconds 10:18:20 AM 11/02/2017 OK 4 seconds
                                      6 10:18:24 AM 11/02/2017 9 seconds 10:18:33 AM 11/02/2017 OK 9 seconds
                                      7 10:18:42 AM 11/02/2017 4 days, 5 hours, 41 minutes and 47 seconds 04:00:29 PM 11/06/2017 OK 44 seconds
                                      8 04:01:13 PM 11/06/2017 15 days, 17 hours, 33 minutes and 48 seconds 09:35:01 AM 11/22/2017 BAD 10 minutes and 40 seconds
                                      9 09:45:41 AM 11/22/2017 8 hours, 9 minutes and 20 seconds 05:55:01 PM 11/22/2017 BAD 7 minutes and 8 seconds
                                      10 06:02:09 PM 11/22/2017 1 hour, 7 minutes and 54 seconds 07:10:03 PM 11/22/2017 BAD 11 minutes and 30 seconds
                                      11 07:21:33 PM 11/22/2017 1 hour, 58 minutes and 32 seconds 09:20:05 PM 11/22/2017 OK 5 seconds
                                      12 09:20:10 PM 11/22/2017 14 minutes and 52 seconds 09:35:02 PM 11/22/2017 BAD 5 minutes and 52 seconds
                                      13 09:40:54 PM 11/22/2017 4 minutes and 6 seconds 09:45:00 PM 11/22/2017 BAD 4 minutes and 51 seconds
                                      14 09:49:51 PM 11/22/2017 11 hours, 15 minutes and 10 seconds 09:05:01 AM 11/23/2017 BAD 7 minutes and 20 seconds
                                      15 09:12:21 AM 11/23/2017 3 days, 2 hours, 17 minutes and 40 seconds 11:30:01 AM 11/26/2017 BAD 27 minutes and 44 seconds
                                      16 11:57:45 AM 11/26/2017 109 days, 19 hours, 12 minutes and 37 seconds 07:10:22 AM 03/16/2018 OK 17 seconds
                                      17 07:10:39 AM 03/16/2018 25 days, 3 hours, 55 minutes and 59 seconds 12:06:38 PM 04/10/2018 OK 3 seconds
                                      18 12:06:41 PM 04/10/2018 8 days, 19 hours, 3 minutes and 20 seconds 07:10:01 AM 04/19/2018 BAD 3 minutes and 52 seconds
                                      19 07:13:53 AM 04/19/2018 77 days, 9 hours, 44 minutes and 39 seconds






                                      share|improve this answer












                                      share|improve this answer



                                      share|improve this answer










                                      answered Jul 5 '18 at 15:00









                                      RfraileRfraile

                                      1011




                                      1011






























                                          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%2f263486%2flinux-getting-date-time-of-system-startup%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

                                          How to reconfigure Docker Trusted Registry 2.x.x to use CEPH FS mount instead of NFS and other traditional...

                                          is 'sed' thread safe

                                          How to make a Squid Proxy server?