Re: "dmesg -T" date doesn't match "date" output

[mlelstv%serpens.de@localhost (Michael van Elst)]

kre%munnari.OZ.AU@localhost (Robert Elz) writes:

>  | > 1.  when the firmware is told to boot
>  | > 2.  when the boot loader gets control from the firmware
>  | > 3.  when the kernel first starts executing.
>  | 3a. when the kernel has started clock
>  | 3b. when the kernel has mounted root
>  | > 4.  When the kernel starts init
>  | > 5.  When /etc/rc finishes

>3a and 3b aren't plausible definitions of when the system booted,
>those are just implementation artifacts

Being "plausible" is irrelevant here, we are just talking about
time stamps that are useful, not some meaning in the real world.


>  | $uptime is counted from 3a (maybe still starting at 1 instead of 0 ?).

>The way it is currently done, yes, the question is how it ought be done.

Uptime is counted when the counters start counting, and that's 3a.
Without counters counting you cannot count time, so that here is the
earliest possibility to get uptime information. Anything later will
just lose information.


>[Aside: according to w (aka uptime) "uptime" is now - boottime rounded
>to the nearest minute (ignoring all but the seconds parts of the times) -

w doesn't report $uptime but current time - $boottime. That data
is more precise than what is printed by w, which is obvious as
w produces output for humans.

Currently you can get $uptime from a CLOCK_MONOTONIC timer. However,
that's not specified by the standard.


>that is, extraordinarily imprecise.   If the result is less than a minute 
>(which means (now-boottime) < 30 seconds) the uptime does not exist.]

We are talking about internal kernel data. If you need $uptime, you
could expose it like $boottime.


>Note that none of the answers matter (other than for the timestamp values
>printed with kernel messages, which are just offsets from something) until
>we reach point 4 - until then the internal value of boottime (and time) is
>mostly irrelevant (boottime, entirely irrelevant).

I don't see why starting init (a very variable point in time) can be
more relevant than mounting root (a less variable point in time).
Both are just some points in the boot sequence and also almost the
same.

But mounting root is the earliest of these points where we can
get an absolute time, so why defer it?

If init is so important, I guess the time when specific services
start or when network is operational or when the first login
(or the distinct time for a remote login) is much more important
to any operator or user. So maybe such information is useful but
not really a good basis for $boottime. $boottime should simply
predate all such events, and if _all_ isn't possible, then
_as many as possible_.


>  | how we define $boottime.

>No, for dmesg alone we do not.   But since we're here, rather than
>adding yet another hack, I thought it would be better to actually
>define what is boot time - in a way that can be explained and makes
>some sense (and isn't "some random point about 6 seconds after
>the kernel stats running, and 3 or 4 seconds before init starts" !)

3b is the earliest point when an absolute time value exists, that
makes it special.

Init usually starts a split-second later. If it can be started.


>  | We just have to find a suitable value for $time
>  | at 3a so that this value can be added to the relative timestamp in the
>  | log to get an absolute time.

>subtracted from (unless you make it negative) and yes, that would
>also be easy, but if that is to be the fix, simply altering the setting
>of boottime (not when it is set, but the value it is set to) would be
>easier.

It would destroy the information that exists now, so while being easier,
it is not necessarily better.


>  | The easiest way to find such a value is to make a copy of $uptime
>  | when $boottime is set. We _could_ also adjust $boottime directly,
>  | changing how it is defined. Or we _could_ just expose the copied
>  | $uptime value and let dmesg do the computation.

>Yes, we could do either.   Since boottime is currently not really
>defined, changing it by a few seconds isn't going to bother anyone.

It is 'defined' as what exists now, there is no need to change that.
You would also lose the information about when root is mounted.

Adjusting the value of $boottime to align with 3a does have the
charm that both clocks now refer to the same origin.


>Neither of those really defines what we mean when we say "the time
>the system was booted" though, and I think it would be better to
>do that first.   After that it is all just mechanics.

I have no idea what "we" mean when we say "the time the system was
booted", so it probably doesn't matter much. Ideally you would start
with power-on or when the hardware comes out of reset. We don't have
that information, but starting time at the earliest possible moment
is the best we can do.


[... about dmesg buffer containing pre-boot data ...]

>Just adding extra messages in the log buffer is no use, as
>we cannot expect the last of those to still be there when
>we need to use it (that one would vanish early, then all
>the later messages are still missing their offset).

We don't need the last. The last start of the epoch is what
the system itself was producing and you get that information
just like now. You only need the currently lost information
from earlier epochs.


>it periodically would also not be useful (just more noise)
>even if we put it only in the buffer and not on the console.

It's not noise but signal. It could even be useful to print it
(one line per epoch), but it needs to be identifiable and thus
stored in a record that can be distinguished from regular output.
No idea if the current buffer can do that.


>Even if it were there, the early messages from a new
>boot would be before it, and appear to belong to the
>old boottime, rather than the next one (though one can detect
>that when they suddenly get smaller).   A big mess.

If the code can recover messages from the previous epoch, it can
also append new messages, and I believe it does.


Greetings,
Michael van Elst
-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."