Getting time of last reboot on Linux

[Alex Vinokur]

Hi,

Is there any sytem call (preferable) or shell-utility to get time of
last reboot on Linux?

uptime(1) is not what I need in my program.

Alex

[Steve Thompson]

On Sun, 18 Dec 2011, Alex Vinokur wrote:

> Is there any sytem call (preferable) or shell-utility to get time of
> last reboot on Linux?

/proc/uptime

[Alex Vinokur]

Thanks.

But I need time of last reboot, not system uptime.

Alex

[Volker Birk]

root@dragon:~# strace uptime 2>&1 | grep time
execve("/usr/bin/uptime", ["uptime"], [/* 21 vars */]) = 0
open("/etc/localtime", O_RDONLY) = 3
open("/proc/uptime", O_RDONLY) = 3
root@dragon:~# _

Then you've seconds since reboot, and can calculate.

HTH, HAND,
VB.
--
"If /dev/null is fast in web scale I will use it."

http://www.mongodb-is-web-scale.com/

[Volker Birk]

In comp.os.linux.development.system Alex Vinokur <alex.v...@gmail.com> wrote:

Time of last reboot = Now - system uptime

Yours,

[Lew Pitcher]

On December 18, 2011 12:35, in comp.os.linux.development.system,

alex.v...@gmail.com wrote:

> Hi,
>
> Is there any sytem call (preferable) or shell-utility to get time of
> last reboot on Linux?

The who(1) command will tell you this. Use the -b ("time of last system
boot") option.

For example:
~ $ who -b
system boot 2011-11-07 11:41

FWIW, the system boot time is recorded in the utmp file (see utmp(5) for
details), and Linux supplies an API that allows processes to read records
from the file (see getutent(3) for details). If you need programmatic
access to the utmp file (rather than scripted access through the who(1)
command), you can use this API to retrieve the BOOT_TIME record.

HTH
--
Lew Pitcher

[Stephane CHAZELAS]

2011-12-18, 13:31(-05), Lew Pitcher:

> On December 18, 2011 12:35, in comp.os.linux.development.system,
> alex.v...@gmail.com wrote:
>
>> Hi,
>>
>> Is there any sytem call (preferable) or shell-utility to get time of
>> last reboot on Linux?
>
> The who(1) command will tell you this. Use the -b ("time of last system
> boot") option.
>
> For example:
> ~ $ who -b
> system boot 2011-11-07 11:41

[...]

That will be the time init(8) was started which is different
from the time reported by uptime which is the time the kernel
itself was started, though.

--
Stephane

[Barry Margolin]

In article <slrnjesnua.t5.s...@spam.is.invalid>,

What kind of application would care about the distinction?

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[Stephane CHAZELAS]

["Followup-To:" header set to comp.unix.programmer.]

[...]
>> That will be the time init(8) was started which is different
>> from the time reported by uptime which is the time the kernel
>> itself was started, though.
>
> What kind of application would care about the distinction?

What kind of application would not care about the distinction?

They either want to know when the kernel was started, or the
last init was started. If they expect one, and are given the
other, they are going to be confused as they could be
hours/days/seconds appart.

--
Stephane

[William Ahern]

Lew Pitcher <lpit...@teksavvy.com> wrote:
> On December 18, 2011 12:35, in comp.os.linux.development.system,
> alex.v...@gmail.com wrote:
> > Hi,
> >
> > Is there any sytem call (preferable) or shell-utility to get time of
> > last reboot on Linux?

> The who(1) command will tell you this. Use the -b ("time of last system
> boot") option.

> For example:
> ~ $ who -b
> system boot 2011-11-07 11:41

> FWIW, the system boot time is recorded in the utmp file (see utmp(5) for
> details), and Linux supplies an API that allows processes to read records
> from the file (see getutent(3) for details).

Here's a scenario: init starts and the current time is recorded in utmp.
init runs the startup scripts, which runs an ntp client. ntp notices that
the clock is off... way off. The system time leaps forwards or backwards.

I believe on Linux and *BSD, uptime(3) and /proc/uptime (where available)
are monotonic counters with the start time as an epoch. If you subtract this
from a known good time, you get the wall time boot time. However, last time
I inquired with Google, 32-bit Linux had a wrapping issue with /proc/uptime
(and presumably uptime(3)). The uptime gives seconds, but is computed in
jiffies, which has a much higher resolution but overflows much
faster--400-something days on some 2.4 kernels.

clock_gettime(CLOCK_MONOTONIC) could prove useful, but the problem is
converting it to wall time. Also, CLOCK_MONOTONIC support can be hard to
come by sometimes. Linux 2.4 doesn't have it, and neither does OS X
(although it's easy to write an implementation for OS X using
mach_absolute_time()).

[Lew Pitcher]

On December 19, 2011 18:15, in comp.unix.programmer,

wil...@wilbur.25thandClement.com wrote:

> Lew Pitcher <lpit...@teksavvy.com> wrote:
>> On December 18, 2011 12:35, in comp.os.linux.development.system,
>> alex.v...@gmail.com wrote:
>> > Hi,
>> >
>> > Is there any sytem call (preferable) or shell-utility to get time of
>> > last reboot on Linux?
>
>> The who(1) command will tell you this. Use the -b ("time of last system
>> boot") option.
>
>> For example:
>> ~ $ who -b
>> system boot 2011-11-07 11:41
>
>> FWIW, the system boot time is recorded in the utmp file (see utmp(5) for
>> details), and Linux supplies an API that allows processes to read records
>> from the file (see getutent(3) for details).
>
> Here's a scenario: init starts and the current time is recorded in utmp.
> init runs the startup scripts, which runs an ntp client. ntp notices that
> the clock is off... way off. The system time leaps forwards or backwards.

System clock changes are usually recorded in utmp(x) NEW_TIME and OLD_TIME
records. Perhaps a thoroughly accurate reboot time accounting would need to
interpret BOOT_TIME, NEW_TIME, and OLD_TIME records to produce a reboot
timestamp that reflects the current clock.

Question: how likely is your scenario? That is, in (say) 1000 reboots of an
aribtrary machine, how often would NTP radically reset the system clock?

--
Lew Pitcher

[William Ahern]

Lew Pitcher <lpit...@teksavvy.com> wrote:
<snip>

> Question: how likely is your scenario? That is, in (say) 1000 reboots of an
> aribtrary machine, how often would NTP radically reset the system clock?

I don't know. Perhaps it's not something to worry about. But "arbitrary
machine" is a significant qualification.

I worked at an appliance company once where a component manufacturer sent
thousands of NICs with identical MAC addresses. The company wasn't equipped
to reflash the NICs individually, so we had to do it in the appliance
firmware. And in any event, certainly this wasn't the first time a huge
batch of such NICs left the factory, so it was probably prudent to handle
this condition anyhow. If somebody asked me the question how often would I
truly need to worry about duplicate MAC addresses I'd have to respond, "all
the time!"

Imagine a run of appliances or motherboards with a bad RTC. The answer could
again be, "all the time!" But perhaps this is common enough to actually be
worrisome without such a pathological scenario.

I've also seen cases where vendors run `ntpdate -b` from a cron job rather
than relying on ntpd to skew the clock, or where ntp isn't used regularly at
all. It's one thing when writing software to rely on the expertise and
sanity of developers whose aim is correctness. It's another thing entirely
to rely on vendors whose aim is to maximize profit, a pursuit which heavily
discounts correctness. Most vendors (by number) rely on _other_ people doing
the correct thing, then writing crappy software on top of that.

I suspect these sorts of clock issues tend to manifest as odd errors that go
away quickly enough that nobody bothers to investigate. Imagine a software
watchdog that restarts an HTTP service because the clock jumped forward 10
seconds. The wrong thing happened, but it was rather benign because HTTP is
stateless and the user habitually resubmitted the form.

[Ivan Shmakov]

>>>>> William Ahern <wil...@wilbur.25thandClement.com> writes:

[...]

> However, last time I inquired with Google, 32-bit Linux had a
> wrapping issue with /proc/uptime (and presumably uptime(3)). The
> uptime gives seconds, but is computed in jiffies, which has a much
> higher resolution but overflows much faster--400-something days on
> some 2.4 kernels.

Indeed, I've had such a problem on one of my home systems once.

Assuming the rate of 100 jiffies per second, it gives some 497
days before the overflow.

(/ (expt 2 32)
100.0 60 60 24)
=> 497.1026(962)

[...]

--
FSF associate member #7257

[Andrew Smallshaw]

On 2011-12-18, Volker Birk <bum...@dingens.org> wrote:
>
> Time of last reboot = Now - system uptime

Not always. When I've tested this in the past many systems will
not count time that the system is suspended towards the uptime.
Depending on the specific machine that could make no difference
whatsoever or it could be months out.

--
Andrew Smallshaw
and...@sdf.lonestar.org

[Richard Kettlewell]

Alex Vinokur <alex.v...@gmail.com> writes:
> Is there any sytem call (preferable) or shell-utility to get time of
> last reboot on Linux?

awk '/^btime/ {print $2}' /proc/stat

--
http://www.greenend.org.uk/rjk/

[Gordon Burditt]

> System clock changes are usually recorded in utmp(x) NEW_TIME and OLD_TIME
> records. Perhaps a thoroughly accurate reboot time accounting would need to
> interpret BOOT_TIME, NEW_TIME, and OLD_TIME records to produce a reboot
> timestamp that reflects the current clock.
>
> Question: how likely is your scenario? That is, in (say) 1000 reboots of an
> aribtrary machine, how often would NTP radically reset the system clock?

Would that be 100% on systems where the time is supposedly kept
running while the system is powered off, and the CMOS battery to
keep that time running is failing / has failed (but you cannot
detect that it has failed without knowing what year it is)?

I would expect that it would be near 100% on systems where there
is no real-time-clock kept alive when the system is powered off,
and the system has to resort to a mod time on the root superblock
from shutdown. Scheduled shutdowns (systems not expected to run
anywhere close to 24/7 for power-saving, security, noise, or other
reasons) or shutdowns for hardware reconfiguration are likely to
take more than 10 minutes. I'll assume that the system is robust
enough not to have a lot of panic/immediate reboot cycles.

(I'll assume that "radically reset" involves times larger than, say,
10 minutes or a few hours, and could easily involve decades.)

It may well be that on aging (PC-like) desktops and servers, nobody
notices a failed CMOS clock because time is set from the network
by NTP, and time stamps generated during single-user boots aren't
used much. (Yes, this would include modern Windows systems set up
to get time from the network.) I suspect that the situation may be
the same on laptops, which do not seem to lose the time even if you
remove (both) batteries and the AC adapter *if* it's a reasonably
new laptop.

[Stefan Monnier]

> I would expect that it would be near 100% on systems where there
> is no real-time-clock kept alive when the system is powered off,
> and the system has to resort to a mod time on the root superblock
> from shutdown. Scheduled shutdowns (systems not expected to run
> anywhere close to 24/7 for power-saving, security, noise, or other
> reasons) or shutdowns for hardware reconfiguration are likely to
> take more than 10 minutes. I'll assume that the system is robust
> enough not to have a lot of panic/immediate reboot cycles.

FWIW, it *is* 100% on many/most home routers I know, since they don't
have any RTC, and they don't try to do anything fancy with the root
superblock (they try to touch the flash as rarely as possible) nor do
they even shutdown usually (they're just power cycled instead).


Stefan

[Kenny McCormack]

In article <87wr9pc...@araminta.anjou.terraraq.org.uk>,

Richard Kettlewell <r...@greenend.org.uk> wrote:
>Alex Vinokur <alex.v...@gmail.com> writes:
>> Is there any sytem call (preferable) or shell-utility to get time of
>> last reboot on Linux?
>
>awk '/^btime/ {print $2}' /proc/stat

ITYM:

gawk '/^btime/ {print strftime("%c",$2)}' /proc/stat

Incidentally, I'm curious, does this data value stored just once (at boot
time - which is what I think we are all looking for in this thread) or is
calculated each time you access it (which is, of course, what we don't
want). The reason I ask is that I tested on a system where the usual method
(calculating: "current time" - "uptime" = "boot time") is known to be
unreliable, and, on this system, the above command line returned the same
result as the calculation. This suggests that it uses the same method
(calculation).

Note, finally, that on most of my systems these days (both Windows & Linux),
I have a command somewhere in the startup sequence to write the current time
to a file (appending). This is really the only reliable way to keep track
of when the system was booted.

And of course, remember that while Windows wraps around in 49 days, Linux
takes about 400 (days). But it does wrap-around...

--
> No, I haven't, that's why I'm asking questions. If you won't help me,
> why don't you just go find your lost manhood elsewhere.

CLC in a nutshell.

[Richard Kettlewell]

gaz...@shell.xmission.com (Kenny McCormack) writes:
> Richard Kettlewell <r...@greenend.org.uk> wrote:
>> Alex Vinokur <alex.v...@gmail.com> writes:

>>> Is there any sytem call (preferable) or shell-utility to get time of
>>> last reboot on Linux?
>>
>>awk '/^btime/ {print $2}' /proc/stat
>
> ITYM:
>
> gawk '/^btime/ {print strftime("%c",$2)}' /proc/stat

That's the same thing with some irrelevant detail added.

> Incidentally, I'm curious, does this data value stored just once (at boot
> time - which is what I think we are all looking for in this thread) or is
> calculated each time you access it (which is, of course, what we don't
> want).

It is calculated, as, essentially:
btime = CLOCK_REALTIME - CLOCK_MONOTONIC - <time spent asleep>

> The reason I ask is that I tested on a system where the usual method
> (calculating: "current time" - "uptime" = "boot time") is known to be
> unreliable, and, on this system, the above command line returned the
> same result as the calculation. This suggests that it uses the same
> method (calculation).

If it gives the wrong answer then either your computer has the clock set
wrongly or it can't keep time correctly. NTP will solve the former.
The latter may well be fixable by choosing a different kernel clock
source.

> Note, finally, that on most of my systems these days (both Windows & Linux),
> I have a command somewhere in the startup sequence to write the current time
> to a file (appending). This is really the only reliable way to keep track
> of when the system was booted.

While this may suffice for your needs, it is no good as a strategy for
the kernel; the only timestamp available at boot time is the BIOS clock,
which is likely to be inaccurate (and may be completely wrong).

> And of course, remember that while Windows wraps around in 49 days, Linux
> takes about 400 (days). But it does wrap-around...

I don't know where you get that from. The variables used to track this
stuff have type 'struct timespec' and certainly do not wrap after 400
days.

--
http://www.greenend.org.uk/rjk/