* [PATCH 0 of 2] xencommons init script improvements
@ 2010-06-29 13:56 George Dunlap
2010-06-29 13:56 ` [PATCH 1 of 2] xencommons: Make init script more verbose George Dunlap
2010-06-29 13:56 ` [PATCH 2 of 2] xencommons: Wait for xenstored to start before setting dom0 name George Dunlap
0 siblings, 2 replies; 7+ messages in thread
From: George Dunlap @ 2010-06-29 13:56 UTC (permalink / raw)
To: xen-devel; +Cc: george.dunlap
Rework of patches from yesterday, without the first one:
* Make xencommons more verbose, as normal init scripts are
* Wait for xenstored to start before attempting to set the domain name.
- Time out after 30 seconds
- Exit the script if the timeout fails.
If exiting is not the preferred behavior, feel free to elide the error
check. :-)
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH 1 of 2] xencommons: Make init script more verbose
2010-06-29 13:56 [PATCH 0 of 2] xencommons init script improvements George Dunlap
@ 2010-06-29 13:56 ` George Dunlap
2010-06-29 13:56 ` [PATCH 2 of 2] xencommons: Wait for xenstored to start before setting dom0 name George Dunlap
1 sibling, 0 replies; 7+ messages in thread
From: George Dunlap @ 2010-06-29 13:56 UTC (permalink / raw)
To: xen-devel; +Cc: george.dunlap
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
diff -r 3ea84fd20b26 -r ad0f9cc72415 tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons Tue Jun 29 13:43:18 2010 +0100
+++ b/tools/hotplug/Linux/init.d/xencommons Tue Jun 29 14:56:28 2010 +0100
@@ -42,21 +42,28 @@
test -z "$XENSTORED_ROOTDIR" || XENSTORED_ROOTDIR="/var/lib/xenstored"
rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null
test -z "$XENSTORED_TRACE" || XENSTORED_ARGS=" -T /var/log/xen/xenstored-trace.log"
+
+ echo Starting xenstored...
xenstored --pid-file=/var/run/xenstore.pid $XENSTORED_ARGS
+ echo Setting domain 0 name...
xenstore-write "/local/domain/0/name" "Domain-0"
fi
+ echo Starting xenconsoled...
test -z "$XENCONSOLED_TRACE" || XENCONSOLED_ARGS=" -T /var/log/xen/xenstored-trace.log"
xenconsoled --pid-file=$XENCONSOLED_PIDFILE $XENCONSOLED_ARGS
test -z "$XENBACKENDD_DEBUG" || XENBACKENDD_ARGS="-d"
test "`uname`" != "NetBSD" || xenbackendd $XENBACKENDD_ARGS
}
do_stop () {
+ echo Stopping xenconsoled
if read 2>/dev/null <$XENCONSOLED_PIDFILE pid; then
kill $pid
while kill -9 $pid >/dev/null 2>&1; do sleep 0.1; done
rm -f $XENCONSOLED_PIDFILE
fi
+
+ echo WARNING: Not stopping xenstored, as it cannot be restarted.
}
case "$1" in
^ permalink raw reply [flat|nested] 7+ messages in thread* [PATCH 2 of 2] xencommons: Wait for xenstored to start before setting dom0 name
2010-06-29 13:56 [PATCH 0 of 2] xencommons init script improvements George Dunlap
2010-06-29 13:56 ` [PATCH 1 of 2] xencommons: Make init script more verbose George Dunlap
@ 2010-06-29 13:56 ` George Dunlap
2010-06-29 14:10 ` Ian Campbell
2010-06-29 14:37 ` Jeremy Fitzhardinge
1 sibling, 2 replies; 7+ messages in thread
From: George Dunlap @ 2010-06-29 13:56 UTC (permalink / raw)
To: xen-devel; +Cc: george.dunlap
On one of my boxes, the xenstore-write setting dom0's name starts
before xenstored is actually ready to handle the connection properly,
resulting in the name set failing. Wait for xenstored to be up and
responding to reads before continuing, timing out after 30 seconds.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
diff -r ad0f9cc72415 -r dc49f02fc463 tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons Tue Jun 29 14:56:28 2010 +0100
+++ b/tools/hotplug/Linux/init.d/xencommons Tue Jun 29 14:56:28 2010 +0100
@@ -37,14 +37,32 @@
fi
do_start () {
+ local time=0
+ local timeout=30
+
if ! `xenstore-read -s / >/dev/null 2>&1`
then
test -z "$XENSTORED_ROOTDIR" || XENSTORED_ROOTDIR="/var/lib/xenstored"
rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null
test -z "$XENSTORED_TRACE" || XENSTORED_ARGS=" -T /var/log/xen/xenstored-trace.log"
- echo Starting xenstored...
+ echo -n Starting xenstored...
xenstored --pid-file=/var/run/xenstore.pid $XENSTORED_ARGS
+
+ # Wait for xenstored to actually come up, timing out after 30 seconds
+ while [ $time -lt $timeout ] && ! `xenstore-read -s / >/dev/null 2>&1` ; do
+ echo -n .
+ time=$(($time+1))
+ sleep 1
+ done
+ echo
+
+ # Exit if we timed out
+ if ! [ $time -lt $timeout ] ; then
+ echo Could not start xenstored
+ exit 1
+ fi
+
echo Setting domain 0 name...
xenstore-write "/local/domain/0/name" "Domain-0"
fi
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH 2 of 2] xencommons: Wait for xenstored to start before setting dom0 name
2010-06-29 13:56 ` [PATCH 2 of 2] xencommons: Wait for xenstored to start before setting dom0 name George Dunlap
@ 2010-06-29 14:10 ` Ian Campbell
2010-06-29 14:37 ` Jeremy Fitzhardinge
1 sibling, 0 replies; 7+ messages in thread
From: Ian Campbell @ 2010-06-29 14:10 UTC (permalink / raw)
To: George Dunlap; +Cc: xen-devel
On Tue, 2010-06-29 at 14:56 +0100, George Dunlap wrote:
> On one of my boxes, the xenstore-write setting dom0's name starts
> before xenstored is actually ready to handle the connection properly,
> resulting in the name set failing. Wait for xenstored to be up and
> responding to reads before continuing, timing out after 30 seconds.
Does this make the xenstored in a stub-dom case more complicated? (due
to use of "-s")
Is the domain 0 name node special enough that we could just make
xenstored set it itself at start of day?
Ian.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 2 of 2] xencommons: Wait for xenstored to start before setting dom0 name
2010-06-29 13:56 ` [PATCH 2 of 2] xencommons: Wait for xenstored to start before setting dom0 name George Dunlap
2010-06-29 14:10 ` Ian Campbell
@ 2010-06-29 14:37 ` Jeremy Fitzhardinge
2010-06-29 15:02 ` Ian Campbell
1 sibling, 1 reply; 7+ messages in thread
From: Jeremy Fitzhardinge @ 2010-06-29 14:37 UTC (permalink / raw)
To: George Dunlap; +Cc: xen-devel, Vincent Hanquez
On 06/29/2010 03:56 PM, George Dunlap wrote:
> On one of my boxes, the xenstore-write setting dom0's name starts
> before xenstored is actually ready to handle the connection properly,
> resulting in the name set failing. Wait for xenstored to be up and
> responding to reads before continuing, timing out after 30 seconds.
>
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
>
> diff -r ad0f9cc72415 -r dc49f02fc463 tools/hotplug/Linux/init.d/xencommons
> --- a/tools/hotplug/Linux/init.d/xencommons Tue Jun 29 14:56:28 2010 +0100
> +++ b/tools/hotplug/Linux/init.d/xencommons Tue Jun 29 14:56:28 2010 +0100
> @@ -37,14 +37,32 @@
> fi
>
> do_start () {
> + local time=0
> + local timeout=30
> +
> if ! `xenstore-read -s / >/dev/null 2>&1`
> then
> test -z "$XENSTORED_ROOTDIR" || XENSTORED_ROOTDIR="/var/lib/xenstored"
> rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null
> test -z "$XENSTORED_TRACE" || XENSTORED_ARGS=" -T /var/log/xen/xenstored-trace.log"
>
> - echo Starting xenstored...
> + echo -n Starting xenstored...
> xenstored --pid-file=/var/run/xenstore.pid $XENSTORED_ARGS
>
Why isn't xenstored ready by the time the main process exits? Seems
like a bug in xenstored. Does oxenstored get this right?
J
> +
> + # Wait for xenstored to actually come up, timing out after 30 seconds
> + while [ $time -lt $timeout ] && ! `xenstore-read -s / >/dev/null 2>&1` ; do
> + echo -n .
> + time=$(($time+1))
> + sleep 1
> + done
> + echo
> +
> + # Exit if we timed out
> + if ! [ $time -lt $timeout ] ; then
> + echo Could not start xenstored
> + exit 1
> + fi
> +
> echo Setting domain 0 name...
> xenstore-write "/local/domain/0/name" "Domain-0"
> fi
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH 2 of 2] xencommons: Wait for xenstored to start before setting dom0 name
2010-06-29 14:37 ` Jeremy Fitzhardinge
@ 2010-06-29 15:02 ` Ian Campbell
2010-06-29 15:06 ` Keir Fraser
0 siblings, 1 reply; 7+ messages in thread
From: Ian Campbell @ 2010-06-29 15:02 UTC (permalink / raw)
To: Jeremy Fitzhardinge; +Cc: George Dunlap, xen-devel, Vincent Hanquez
On Tue, 2010-06-29 at 15:37 +0100, Jeremy Fitzhardinge wrote:
>
>
> Why isn't xenstored ready by the time the main process exits? Seems
> like a bug in xenstored. Does oxenstored get this right?
Looks like Bastian tried to fix this in C xenstored years ago with:
changeset: 17296:21d9575c669e
user: Keir Fraser <keir.fraser@citrix.com>
date: Wed Mar 26 13:21:42 2008 +0000
files: tools/misc/xend tools/xenstore/xenstored_core.c
description:
xenstored: Delay forking until after listening sockets are
opened. Also, in startup xend script, delay further startup until
xenstored initial child process has exited. This serialises xenstored
startup with that of other daemons (e.g., xenconsoled).
Signed-off-by: Bastian Blank <waldi@debian.org>
But it was reverted shortly after:
changeset: 17304:ed67f68ae2a7
user: Keir Fraser <keir.fraser@citrix.com>
date: Thu Mar 27 09:12:09 2008 +0000
files: tools/misc/xend tools/xenstore/xenstored_core.c
description:
Revert 17296:21d9575c669e.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
because it broke something. The thread at
http://lists.xensource.com/archives/html/xen-devel/2008-03/msg00758.html
has more details.
I'm not especially inclined to fix the C xenstored, lets hasten the
switch to oxenstored instead.
Ian.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-06-29 15:06 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-06-29 13:56 [PATCH 0 of 2] xencommons init script improvements George Dunlap
2010-06-29 13:56 ` [PATCH 1 of 2] xencommons: Make init script more verbose George Dunlap
2010-06-29 13:56 ` [PATCH 2 of 2] xencommons: Wait for xenstored to start before setting dom0 name George Dunlap
2010-06-29 14:10 ` Ian Campbell
2010-06-29 14:37 ` Jeremy Fitzhardinge
2010-06-29 15:02 ` Ian Campbell
2010-06-29 15:06 ` Keir Fraser
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).