Re: xenstore utils dropped support for -s in 4.15

[Juergen Gross <jgross@xxxxxxxx>]

On 11.04.21 09:17, Henrik Riomar wrote:
> On Sun, 11 Apr 2021 07:34:16 +0200
> Juergen Gross <jgross@xxxxxxxx> wrote:
>
> > On 11.04.21 00:02, Henrik Riomar wrote:
> > > Hi,
> > >
> > > In Alpine and Debian (probably elsewhere as well), the -s flag removed in these 
> > > two commits:
> > >    * 
> > > https://github.com/xen-project/xen/commit/fa06cb8c38832aafe597d719040ba1d216e367b8
> > >    * 
> > > https://github.com/xen-project/xen/commit/c65687ed16d2289ec91036ec2862a4b4bd34ea4f
> > > is actually used in the init scripts.
> > > Reverting the two commits mentioned above restores a booting system.
> > >
> > > The -s flag was introduced in 2005 or so, so I guess you can say that dropping 
> > > it should
> > > at least be mentioned in the release notices, and an alternative be described, 
> > > or
> > > -s functionally should be brought back.
> > The -s served exactly no purpose.
> yes its used by dists to check that the socket is actually accessible (without 
> falling back to
> direct access to /dev/xen/xenbus).
There are Xen configurations where the socket is never accessible,
as it is not existing.

> > It was meant to force socket usage. A socket will be used anyway in
> > case xenstored is running in dom0, so specifying -s won't change
> > anything in this case.
> yes reverting the to commits above and using -s, brings back the original 
> behavior, returning
> with failure if the socket is not there.
And returning failure when Xenstore is running fine, but not in dom0.

> There are two issues here I think:
>   1. dists actually use -s to check if the daemon is up (and been doing this 
> for a long time)
This should be changed, as it is based on wrong assumptions.

>   2. Reads of /dev/xen/xenbus (via xenstore-read -s /), blocks for ever in 4.15
So you are basically saying that you'd like to have a test "is Xenstore
running", and this test should work with the "-s" flag.

I can look into that, but reverting the "access via socket" removal flag
is not the way to go.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys

Attachment: OpenPGP_signature
Description: OpenPGP digital signature