[systemd-devel] [PATCH] RD_TIMESTAMP: support the value being set from /proc/uptime

[Lennart Poettering]

On Fri, 02.09.11 09:17, Tom Gundersen (teg at jklm.no) wrote:

> 
> On Fri, Sep 2, 2011 at 4:20 AM, Lennart Poettering
> <lennart at poettering.net> wrote:
> > On Thu, 25.08.11 22:59, Tom Gundersen (teg at jklm.no) wrote:
> >
> >> This is useful to be able to use systemd-analyze with initrd's that don't
> >> have systemd support. In particular, Arch's initrd exports RD_TIMESTAMP
> >> on this format. I also believe dracut falls back to this when systemd-timestamp
> >> is not present.
> >
> > When I wrote this I was thinking about allowing the /proc/uptime format
> > for this, but decided against it for a number of reasons. Instead I
> > preppaed systemd-timestamp for inclusion in initrds. I am not a fan of
> > allowing too many variables in the game where they bring no clear
> > benefit. Hence my question: why? Why can't your initrd simply include
> > systemd-timestamp in the image, the same way we do it on dracut? (the
> > binary has no deps, so there's nothing stopping you really).
> 
> Since systemd is not our only (nor even the default) init system, and
> it probably won't be for some time, we'd rather not add
> systemd-specific stuff to our initrd (especially when the benefit is
> so small).
> 
> I am all in favor of sharing the protocols between all initrd/init
> implementations (we also have support for /run/initramfs in both our
> initrd and initscripts). I also think it makes sense that you get the
> best result (in this case highest precision) if you use the "blessed"
> combination of packages (systemd+dracut). However, it would be nice if
> there could be a fallback that would also work if you choose to swap
> out some of the components.
> 
> Since dracut (afaik) already falls back to /proc/uptime, and it is the
> simplest thing to implement from a shell, in case you don't have the
> systemd binary available, I thought it made a lot of sense to use as

Well, the thing is that RD_TIMESTAMP is an optional feature anyway, and
not setting it has no ill effects on things at all. So I am not sure
what we'd win by supporting something half-way that is optional
anyway...

What I'd like to avoid here is have people ship this as default in a big
scale, where they really should get the proper timestamps and nothing
else.

If it really bothers people so much that this tool is built from the
systemd tree I'd suggest they add a feature to /bin/date to format
CLOCK_REALTIME and CLOCK_MONOTONIC as integer. I am sure the maintainers
of coreutils would accept such a patch (it appears CLOCK_REALTIME is
already supported to some degree anyway with +%s, so a tiny patch for
CLOCK_MONOTONIC shouldn't be that hard.). Whether you patch systemd like
this or coreutils shouldn't really matter, except that with coretuils
you'd get a correct solution and with /proc/uptime support in systemd
you don't.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.