On 17 June 2013 13:31, Karel Zak <kzak@xxxxxxxxxx> wrote: > On Sun, Jun 16, 2013 at 07:53:41PM +0100, Sami Kerola wrote: >> Unfortunately the most troubling dmesg patch is now dropped by me. I had >> a look how systemd determines boot time, and it seem very early at >> execution clock_gettime() is called, and results are saved. If dmesg >> should agree with systemd when startup happen I see two possible options; >> >> 1. Make dmesg to get system startup time from systemd using dbus. >> >> 2. Make both dmesg and systemd to ask start up time from kernel. >> >> I feel first option is not great. The systemd boot time stamp is similar >> sort of approximation as reading fstat from /proc/1. Also asking when >> system started from system itself feels more neutral than consulting a >> software the system started. >> >> If the second option is favored a kernel patch, such as the one below, is >> needed and a bit coordination to make various programs to use the >> boottime from kernel. Meanwhile it migth be fine that differnt programs >> using differnet time stamps for klog messages. > > Note that the current dmesg(1) code uses sysinfo(2) which provides > uptime in seconds. It would be probably better to use /proc/uptime > where is uptime in sec.xx precision. I am aware of the sysinfo()'s limit to one second, which originally started to annoy me. http://markmail.org/message/zjp43ecruh5vduza Unfortunately I were a bit vague what seems to be the problem. With one second uptime resolution the seconds will start to flicker due rounding error/feature. If uptime value is less precise than delta time the small numbers of delta time start to affect rounding time dependant way. Because of this rounding happening the way it does I guess it is almost impossible to have all dmesg time stamps such way that the following would not differ. diff -q <(dmesg --ctime) <(sleep 0.5 ; dmesg --ctime) I gave a shot to /proc/uptime value, and with it the new ISO 8601 format differed less than with just a second precision. But, IMHO, having time stamps to flicker at all is not correct. Unstable output will also cause trouble if someone intends to analyse system log with for example logstash. >> Any opinions about klog time stamps? >> >> >> --- a/kernel/ksysfs.c >> +++ b/kernel/ksysfs.c >> @@ -157,6 +157,16 @@ static ssize_t rcu_expedited_store(struct kobject >> *kobj, >> } >> KERNEL_ATTR_RW(rcu_expedited); >> >> +/* High precision timestamp of the system boot. */ >> +static ssize_t boottime_show(struct kobject *kobj, >> + struct kobj_attribute *attr, char *buf) >> +{ >> + struct timespec ts; >> + getboottime(&ts); >> + return sprintf(buf, "%ld.%ld\n", ts.tv_sec, ts.tv_nsec); >> +} >> +KERNEL_ATTR_RO(hp_uptime); >> + >> /* >> * Make /sys/kernel/notes give the raw contents of our kernel .notes >> * section. >> */ >> @@ -197,6 +207,7 @@ static struct attribute * kernel_attrs[] = { >> &vmcoreinfo_attr.attr, >> #endif >> &rcu_expedited_attr.attr, >> + &hp_uptime_attr.attr, >> NULL >> }; > > Would be better to use /proc (where is 'uptime' file) rather than > /sys/kernel ? Isn't the /sys new /proc? More seriously, I don't mind to where the value is added if the idea itself is generally accepted as a reasonable solution. -- Sami Kerola http://www.iki.fi/kerolasa/ -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
