Linux: Getting date & time of system startup
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
add a comment |
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
What'sunreliable or hard
aboutuptime
?
– 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
add a comment |
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
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
linux uptime
asked Mar 28 '11 at 11:15
jhojho
608169
608169
What'sunreliable or hard
aboutuptime
?
– 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
add a comment |
What'sunreliable or hard
aboutuptime
?
– 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
add a comment |
11 Answers
11
active
oldest
votes
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.
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
add a comment |
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.
1
Interestingly, this disagrees withwho -b
by a minute or two on my 210-days-uptime system. Looks likewho -b
reports a time stamp, while this counting is somehow affected by clock drifts, even if these are periodically corrected by a runningntpd
.
– 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
add a comment |
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.
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
Theuptime
in CentOS 6 (procps version 3.2.8
) does not seem to support this, sadly.
– mwfearnley
Dec 3 '18 at 10:43
add a comment |
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.
1
Seems a lot easier to writeawk '/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
add a comment |
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
add a comment |
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.
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
add a comment |
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) ))
uptime -s
provides a date value
– mikegreiling
Nov 1 '14 at 20:56
add a comment |
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)
Sure, Why not? Kinda clever use of variable substringiness. Cool. +1. Thanks for the idea!
– Mike S
Jun 3 '18 at 3:24
add a comment |
date -d @$(sed -n '/^btime /s///p' /proc/stat)
(yet another way to do this, which is useful in certain circumstances)
add a comment |
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
add a comment |
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
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%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
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
1
Interestingly, this disagrees withwho -b
by a minute or two on my 210-days-uptime system. Looks likewho -b
reports a time stamp, while this counting is somehow affected by clock drifts, even if these are periodically corrected by a runningntpd
.
– 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
add a comment |
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.
1
Interestingly, this disagrees withwho -b
by a minute or two on my 210-days-uptime system. Looks likewho -b
reports a time stamp, while this counting is somehow affected by clock drifts, even if these are periodically corrected by a runningntpd
.
– 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
add a comment |
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.
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.
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 withwho -b
by a minute or two on my 210-days-uptime system. Looks likewho -b
reports a time stamp, while this counting is somehow affected by clock drifts, even if these are periodically corrected by a runningntpd
.
– 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
add a comment |
1
Interestingly, this disagrees withwho -b
by a minute or two on my 210-days-uptime system. Looks likewho -b
reports a time stamp, while this counting is somehow affected by clock drifts, even if these are periodically corrected by a runningntpd
.
– 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
add a comment |
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.
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
Theuptime
in CentOS 6 (procps version 3.2.8
) does not seem to support this, sadly.
– mwfearnley
Dec 3 '18 at 10:43
add a comment |
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.
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
Theuptime
in CentOS 6 (procps version 3.2.8
) does not seem to support this, sadly.
– mwfearnley
Dec 3 '18 at 10:43
add a comment |
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.
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.
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
Theuptime
in CentOS 6 (procps version 3.2.8
) does not seem to support this, sadly.
– mwfearnley
Dec 3 '18 at 10:43
add a comment |
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
Theuptime
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
add a comment |
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.
1
Seems a lot easier to writeawk '/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
add a comment |
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.
1
Seems a lot easier to writeawk '/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
add a comment |
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.
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.
edited Jul 8 '16 at 22:35
answered Aug 30 '11 at 20:30
Oddstr13Oddstr13
15127
15127
1
Seems a lot easier to writeawk '/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
add a comment |
1
Seems a lot easier to writeawk '/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
add a comment |
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
add a comment |
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
add a comment |
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
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
edited Apr 8 '18 at 12:29
answered May 10 '12 at 7:41
teika kazurateika kazura
465510
465510
add a comment |
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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) ))
uptime -s
provides a date value
– mikegreiling
Nov 1 '14 at 20:56
add a comment |
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) ))
uptime -s
provides a date value
– mikegreiling
Nov 1 '14 at 20:56
add a comment |
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) ))
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) ))
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
add a comment |
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
add a comment |
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)
Sure, Why not? Kinda clever use of variable substringiness. Cool. +1. Thanks for the idea!
– Mike S
Jun 3 '18 at 3:24
add a comment |
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)
Sure, Why not? Kinda clever use of variable substringiness. Cool. +1. Thanks for the idea!
– Mike S
Jun 3 '18 at 3:24
add a comment |
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)
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)
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
add a comment |
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
add a comment |
date -d @$(sed -n '/^btime /s///p' /proc/stat)
(yet another way to do this, which is useful in certain circumstances)
add a comment |
date -d @$(sed -n '/^btime /s///p' /proc/stat)
(yet another way to do this, which is useful in certain circumstances)
add a comment |
date -d @$(sed -n '/^btime /s///p' /proc/stat)
(yet another way to do this, which is useful in certain circumstances)
date -d @$(sed -n '/^btime /s///p' /proc/stat)
(yet another way to do this, which is useful in certain circumstances)
answered Dec 4 '14 at 14:06
AmanicAAmanicA
1013
1013
add a comment |
add a comment |
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
add a comment |
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
add a comment |
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
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
edited May 9 '16 at 14:07
answered May 9 '16 at 13:46
LonnieBestLonnieBest
58222033
58222033
add a comment |
add a comment |
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
add a comment |
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
add a comment |
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
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
answered Jul 5 '18 at 15:00
RfraileRfraile
1011
1011
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f263486%2flinux-getting-date-time-of-system-startup%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
What's
unreliable or hard
aboutuptime
?– 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