The "-s" option to xenstore-ls is used by the xencommons startup
script to check whether xenstored is already running, before starting
it.
Since 22498:
a40455ae9ad3, "-s" has been a no-op, and libxenstore will
always fall back to using xenbus. The combined effect is that the
xencommons script deadlocks: xenstore-ls hangs waiting for xenstored,
which isn't started by xencommons because xencommons is waiting for
xenstore-ls.
In this patch, we:
* Introduce a new XS_OPEN_SOCKETONLY flag which disables the
fallback behaviour;
* Make the xenstore command line tools use the new xs_open call
rather than the old, deprecated xs_open_* calls (which are
now identical).
* Plumb the xenstore command line tools "-s" option to set the
XS_OPEN_SOCKETONLY flag.
* Change the type of the XS_OPEN_* flags so that they naturally have
type unsigned long.
The "-s" option to xenstore-ls et al, and the XS_OPEN_SOCKETONLY flag,
are intended for use by toolstack infrastructure and should not
normally be used by higher-level code.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
max_width = ws.ws_col - 2;
}
- xsh = socket ? xs_daemon_open() : xs_domain_open();
- if (xsh == NULL)
- err(1, socket ? "xs_daemon_open" : "xs_domain_open");
+ xsh = xs_open(socket ? XS_OPEN_SOCKETONLY : 0);
+ if (xsh == NULL) err(1, "xs_open");
again:
if (transaction) {
else
xsh = get_handle(xs_daemon_socket(), flags);
- if (!xsh)
+ if (!xsh && !(flags & XS_OPEN_SOCKETONLY))
xsh = get_handle(xs_domain_dev(), flags);
return xsh;
#define XBT_NULL 0
-#define XS_OPEN_READONLY 1<<0
+#define XS_OPEN_READONLY 1UL<<0
+#define XS_OPEN_SOCKETONLY 1UL<<1
struct xs_handle;
typedef uint32_t xs_transaction_t;