[systemd-devel] [PATCH v2] journalctl: Add support for showing messages from a previous boot

[Jan Janssen]

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 (medhefgo at web.de) wrote:
>
>>
>> On 06/04/2013 04:42 PM, Lennart Poettering wrote:
>>> On Thu, 30.05.13 17:24, Jan Janssen (medhefgo at 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