[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 4/4] tools: make xenstore domain easy configurable
On Mon, Jul 25, 2016 at 04:16:51PM +0200, Juergen Gross wrote: > On 25/07/16 16:11, Wei Liu wrote: > > On Mon, Jul 25, 2016 at 04:06:11PM +0200, Juergen Gross wrote: > >> On 25/07/16 16:01, Wei Liu wrote: > >>> On Mon, Jul 25, 2016 at 03:56:17PM +0200, Juergen Gross wrote: > >>>> On 25/07/16 15:43, Wei Liu wrote: > >>>>> On Fri, Jul 22, 2016 at 05:09:31PM +0200, Juergen Gross wrote: > >>>>> [...] > >>>>>> diff --git a/tools/hotplug/Linux/launch-xenstore.in > >>>>>> b/tools/hotplug/Linux/launch-xenstore.in > >>>>>> index 2bd9f64..fdfa33a 100644 > >>>>>> --- a/tools/hotplug/Linux/launch-xenstore.in > >>>>>> +++ b/tools/hotplug/Linux/launch-xenstore.in > >>>>>> @@ -48,18 +48,40 @@ test_xenstore && exit 0 > >>>>>> > >>>>>> test -f @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons && . > >>>>>> @CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons > >>>>>> > >>>>>> -test -z "$XENSTORED_ROOTDIR" && XENSTORED_ROOTDIR="@XEN_LIB_STORED@" > >>>>>> -rm -f "$XENSTORED_ROOTDIR"/tdb* 2>/dev/null > >>>>>> -test -z "$XENSTORED_TRACE" || XENSTORED_ARGS=" -T > >>>>>> @XEN_LOG_DIR@/xenstored-trace.log" > >>>>>> +[ "$XENSTORETYPE" = "" ] && XENSTORETYPE=daemon > >>>>>> + > >>>>>> +/bin/mkdir -p @XEN_RUN_DIR@ > >>>>>> + > >>>>>> +[ "$XENSTORETYPE" = "daemon" ] && { > >>>>>> + [ -z "$XENSTORED_ROOTDIR" ] && > >>>>>> XENSTORED_ROOTDIR="@XEN_LIB_STORED@" > >>>>>> + /bin/rm -f $XENSTORED_ROOTDIR/tdb* 2>/dev/null > >>>>>> + [ -z "$XENSTORED_TRACE" ] || XENSTORED_ARGS="$XENSTORED_ARGS -T > >>>>>> @XEN_LOG_DIR@/xenstored-trace.log" > >>>>>> + [ -z "$XENSTORED" ] && XENSTORED=@XENSTORED@ > >>>>>> + [ -x "$XENSTORED" ] || { > >>>>>> + echo "No xenstored found" > >>>>>> + exit 1 > >>>>>> + } > >>>>>> > >>>>>> -if [ -n "$XENSTORED" ] ; then > >>>>>> echo -n Starting $XENSTORED... > >>>>>> $XENSTORED --pid-file @XEN_RUN_DIR@/xenstored.pid > >>>>>> $XENSTORED_ARGS > >>>>>> -else > >>>>>> - echo "No xenstored found" > >>>>>> - exit 1 > >>>>>> -fi > >>>>>> > >>>>>> -timeout_xenstore $XENSTORED || exit 1 > >>>>>> + systemd-notify --booted 2>/dev/null || timeout_xenstore > >>>>>> $XENSTORED || exit 1 > >>>>>> > >>>>>> -exit 0 > >>>>>> + exit 0 > >>>>>> +} > >>>>>> + > >>>>>> +[ "$XENSTORETYPE" = "domain" ] && { > >>>>>> + [ -z "$XENSTORE_DOMAIN_KERNEL" ] && > >>>>>> XENSTORE_DOMAIN_KERNEL=@LIBEXEC@/boot/xenstore-stubdom.gz > >>>>>> + XENSTORE_DOMAIN_ARGS="$XENSTORE_DOMAIN_ARGS --kernel > >>>>>> $XENSTORE_DOMAIN_KERNEL" > >>>>>> + [ -z "$XENSTORE_DOMAIN_SIZE" ] && XENSTORE_DOMAIN_SIZE=8 > >>>>>> + XENSTORE_DOMAIN_ARGS="$XENSTORE_DOMAIN_ARGS --memory > >>>>>> $XENSTORE_DOMAIN_SIZE" > >>>>>> + > >>>>>> + echo -n Starting $XENSTORE_DOMAIN_KERNEL... > >>>>>> + ${LIBEXEC_BIN}/init-xenstore-domain $XENSTORE_DOMAIN_ARGS || > >>>>>> exit 1 > >>>>>> + systemd-notify --ready 2>/dev/null > >>>>> > >>>>> Please test if there is systemd-notify before trying to invoke it and > >>>>> then you can properly log the failure of the invocation. > >>>> > >>>> I thought about that. What would be the purpose doing so? Following > >>>> cases are possible: > >>>> > >>> > >>> This > >>> > >>>> - system is booted under control of systemd, systemd-notify is found: > >>>> everything is nice, systemd receives the notification it is waiting > >>>> for > >>>> > >>> > >>> Here you assume systemd-notify always succeed. It can fail due to some > >>> reasons. That's what its manpage suggests. > >>> > >>> We need to handle this. > >> > >> May I repeat the sd_notify() man page here? > >> > >> "In order to support both, init systems that implement this scheme and > >> those which do not, it is generally recommended to ignore the return > >> value of this call." > > > > That's a different thing from the systemd-notify utility, isn't it? > > > > I read man systemd-notify in this case: > > > > EXIT STATUS > > On success, 0 is returned, a non-zero failure code otherwise. > > > > I'm not too sure about the relationship between systemd-notify and > > sd_notify, but I bet it is more than just a call to sd_notify. > > The systemd-notify man-page tells us: > > "This is mostly just a wrapper around sd_notify() and makes this > functionality available to shell scripts. For details see sd_notify(3)." > OK. I'm convinced now. Wei. > > Juergen > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |