Sorry, I failed to hit Reply-All.
On 06/04/2013 07:10 PM, Lennart Poettering wrote:
On Tue, 04.06.13 18:47, Jan Janssen (medhe...@web.de) wrote:
On 06/04/2013 04:42 PM, Lennart Poettering wrote:
On Thu, 30.05.13 17:24, Jan Janssen (medhe...@web.de) wrote:
I like this idea!
The format to specify the boot ID is inspired by git's ^n syntax
and it even allows to look into the future.
Unfortunately, to get a chronological list of boot IDs, we
need search through the journal. sd_journal_enumerate_unique()
doesn't help us here, because order of returned values is undefined.
To make things less painful, an initial search for the reference
boot ID is performed, which will either quickly fail so we don't have
to needlessly walk the full journal or give us a cursor from which
to start the slow lookup process.
Hmm, I think this should be implemented differently: we should define a
new message with a fixed message ID which is ussed once during boot,
which we then can search for. We already have
SD_MESSAGE_STARTUP_FINISHED which kinda does that, but is generated only
after startup finished. For this feature we should have a message that
is generated as early as possible in the boot process as possible
(i.e. right after the journal is up), and from PID1, and only once
during boot. We'd then simply search for this message ID in the
database, and this would return a nicely ordered list of boots. We then
pick the one we want and use it in an entirely new query.
This would work, but only if this message won't rotate away.
Otherwise results would be unexpected to users. Although, now that I
think about it, I guess I could look into ensuring that...
Hmm, looking for startup messages plus an extra check for the boot ID of
the oldest entry in all journals should give you a full list.
Any journal file could contain messages from more than one boot. And
if you have a (user) journal file with two or more boot IDs from boots
that are not in the list obtained by message ID, you'd miss some boot
IDs. Or I just don't grok your approach.
I am not sure I really like the "^" syntax. This after all is different
>from git, as the "^" would works strictly by time, there is no real
"ancestral" information. (or in other words: the result of ^ differs
when you use different filters...).
Actually, the final boot ID result doesn't change even if you
provide other filters. The lookup is done before all user defined
filters are added.
Yeah, but that's not what I meant. I meant that on the conceptional
level in git the "^" actually indicates an ancestral relation, but this
--boot= stuff would give you different results if you would apply a
filter, or there are missing journal files and so on. it would simply
return the newest boot id that is before the specified id
_which_is_in_the_current_dataset_. If you follow what I mean...
Now I see what you mean. I'll try some other/better phrasing for docs.
Maybe we can use a different syntax? Something like "--boot=-5" or
"--boot=bd1b92058dd24e1eab573808e114f18b-5" or so?
If there is consent on one. Hyphen is rather sub-optimal. It clashes
with boot IDs given in UUIDs form
(6bf79b04-3e50-4336-94ff-4ccf1083a005). It's supported, though not
explicitly stated.
Indeed, "-" sucks. Hmm, not sure what we could use instead. I'd like a
syntax that is sufficiently different from git's so that people don't
make the wrong assumption, but something that is still easy to type...
Maybe use bd1b92058dd24e1eab573808e114f18b:-5 and
bd1b92058dd24e1eab573808e114f18b:+5 or so?
degree should probably be an "unsigned" rather than an "int". We try to
use types that indicate the sensible range of the variable, and a
negative value here doesn't appear to make sense, so please use "unsigned".
A negative value does make sense. It allows to see into the future.
To try it, just look for a past boot ID and look up the following
boot by
appending "^-1". Trying it on the current boot will fail for obvious
reasons.
Oh, true. Sorry for my confusion...
Lennart
Jan
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
