Re: [Xen-devel] [PATCH v4 04/12] xenstore: add per-node generation counter

[Juergen Gross <jgross@xxxxxxxx>]

On 09/01/17 17:10, Jan Beulich wrote:
>>>> On 09.01.17 at 17:02, <JGross@xxxxxxxx> wrote:
>> On 09/01/17 15:38, Jan Beulich wrote:
>>>>>> On 05.12.16 at 08:48, <JGross@xxxxxxxx> wrote:
>>>> --- a/tools/xenstore/include/xenstore_lib.h
>>>> +++ b/tools/xenstore/include/xenstore_lib.h
>>>> @@ -44,6 +44,7 @@ struct xs_permissions
>>>>  
>>>>  /* Header of the node record in tdb. */
>>>>  struct xs_tdb_record_hdr {
>>>> +  uint64_t generation;
>>>>    uint32_t num_perms;
>>>>    uint32_t datalen;
>>>>    uint32_t childlen;
>>>
>>> After quite a bit of debugging I think I now understand that this is
>>> the reason for a startup SEGV I'm getting from 4.8 xenstored after
>>> that same system has run unstable xenstored. The above
>>
>> How are you starting xenstored? I can't see how xenstored started
>> by Xen's scripts will see a file with a tdb dump. Those should be
>> deleted by the start scripts of Xen.
> 
> I order to be able to use multiple Xen versions on a single system,
> I can't use the start scripts. Instead I launch xenstored from a
> script of mine (wrapping all the various xen-specific commands)
> upon first use after boot. Of course I could add deletion of that
> file to the script, but then again all has worked fine for years, so
> I'm a little reluctant to do so (after all I'd expect/hope there's a
> reason for this file to exist in the first place).

I believe this file is meant to aid diagnosis of a crashed xenstored:
you can extract the xenstore entries from it in order to see how far
it proceeded processing the last command.

I suggest to bump the TDB_VERSION in order to avoid something like
this happening again and then to always start with an empty xenstore
(I can write that patch) by not opening an existing tdb file in
xenstored.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel