George Shuklin
2012-Jul-07 02:20 UTC
[Pkg-xen-devel] Bug#680588: xcp-xapi: startup race condition between xcp-xapi and xcp-networkd on slave
Package: xcp-xapi
Version: 1.3.2-8
Severity: important
Tags: patch
Found race condition (specific only to slave hosts):
xcp-xapi can start earlier than xcp-networkd due lack of dependency in init.d
script.
Syptoms:
After reboot slave's xcp does not work:
xe (anything):
The host failed to acquire an IP address on its management interface and
therefore cannot contact the master.
log:
/var/log/xcp-xapi.log:[20120707T01:36:51.361Z| warn|lab-xh3|0
thread_zero|bringing up management interface D:065e1b39b653|xapi] Failed to
acquire a management IP address
That bug appears only on slave host.
Patch:
--- /tmp/xcp-xapi 2012-07-07 06:13:47.000000000 +0400
+++ /etc/init.d/xcp-xapi 2012-07-07 06:08:05.000000000 +0400
@@ -1,7 +1,7 @@
#! /bin/sh
### BEGIN INIT INFO
# Provides: xcp-xapi
-# Required-Start: $remote_fs $syslog xcp-squeezed xcp-v6d xcp-fe
+# Required-Start: $remote_fs $syslog xcp-squeezed xcp-v6d xcp-fe
xcp-networkd
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
(after applying exec 'update-rc.d xcp-xapi defaults')
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-3-686-pae (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages xcp-xapi depends on:
ii hwdata 0.233-1
ii libc6 2.13-34
ii libpam0g 1.1.3-7.1
ii libuuid1 2.20.1-5.1
ii libvhd0 2.0.90-1
ii libxen-4.1 4.1.3~rc1+hg-20120614.a9c0a89c08f2-4
ii libxenstore3.0 4.1.3~rc1+hg-20120614.a9c0a89c08f2-4
ii lsb-base 4.1+Debian7
ii pciutils 1:3.1.9-5
ii python 2.7.3-1
ii python-xenapi 1.3.2-8
ii stunnel4 [stunnel] 3:4.53-1
ii xcp-eliloader 0.1-4
ii xcp-fe 0.5.2-3+b1
ii xcp-networkd 1.3.2-8
ii xcp-squeezed 1.3.2-8
ii xcp-storage-managers 0.1.1-2
ii xcp-v6d 1.3.2-8
ii xcp-xe 1.3.2-8
ii xen-hypervisor-4.1-amd64 [xen-hypervi 4.1.3~rc1+hg-20120614.a9c0a89c08f2-4
ii xen-utils-4.1 4.1.3~rc1+hg-20120614.a9c0a89c08f2-4
ii zlib1g 1:1.2.7.dfsg-13
Versions of packages xcp-xapi recommends:
ii cifs-utils 2:5.5-1
ii xcp-guest-templates 0.1-3
ii xcp-vncterm 0.1-2
xcp-xapi suggests no packages.
-- Configuration Files:
/etc/init.d/xcp-xapi changed:
XAPI_INIT_COMPLETE_COOKIE=/var/run/xapi_init_complete.cookie
XAPI_STARTUP_COOKIE=/var/run/xapi_startup.cookie
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="The XenAPI server"
NAME=xapi
DAEMON=/usr/sbin/$NAME
DAEMON_ARGS="-daemon -writereadyfile $XAPI_STARTUP_COOKIE
-writeinitcomplete $XAPI_INIT_COMPLETE_COOKIE -onsystemboot"
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
TEMPLATES_MD5_STAMP=/var/lib/xcp/templates.md5
[ -x "$DAEMON" ] || exit 0
grep hypervisor /proc/cpuinfo > /dev/null || exit 0
[ -r /etc/default/$NAME ] && . /etc/default/$NAME
[ -r /etc/default/xen ] && . /etc/default/xen
. /lib/init/vars.sh
. /lib/lsb/init-functions
if [ "${TOOLSTACK}" != "xapi" ]; then
log_failure_msg "Xen toolstack is not set to xapi! Exiting."
exit 0
fi
if [ -f /var/run/xend.pid ]; then
log_failure_msg "/var/run/xend.pid exists; ${NAME} conflicts with
xend"
exit 1
fi
wait_for_xapi() {
MAX_RETRIES=50
RETRY=0
while [ ${RETRY} -lt ${MAX_RETRIES} ]; do
if [ -e ${XAPI_STARTUP_COOKIE} ]; then
return 0
fi
sleep 1
RETRY=$(( ${RETRY} + 1 ))
done
return 1
}
do_start()
{
# Return
# 0 if daemon has been started
# 1 if daemon was already running
# 2 if daemon could not be started
modprobe xen-netback
modprobe xen-blkback
modprobe blktap
mkdir -p /var/run/xend/boot
mkdir -p /usr/share/xcp/packages/iso
export OCAMLRUNPARAM=b
rm -f $XAPI_STARTUP_COOKIE $XAPI_INIT_COMPLETE_COOKIE
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test >
/dev/null \
|| return 1
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
$DAEMON_ARGS \
|| return 2
# Add code here, if necessary, that waits for the process to be ready
# to handle requests from services started subsequently which depend
# on this one. As a last resort, sleep for some time.
wait_for_xapi
# Do some standard setup, e.g. pif-scan, template creation (maybe)
. /etc/xcp/inventory
xe pif-scan host-uuid=${INSTALLATION_UUID}
# Check whether the md5 of the create-templates binary matches the one
# used previously. If not, recreate the templates.
if [ -e /usr/lib/xcp/lib/create_templates ]; then
if ! md5sum -c --status $TEMPLATES_MD5_STAMP ; then
/usr/lib/xcp/lib/regenerate-templates start
md5sum /usr/lib/xcp/lib/create_templates > $TEMPLATES_MD5_STAMP
fi
fi
}
do_stop()
{
# Return
# 0 if daemon has been stopped
# 1 if daemon was already stopped
# 2 if daemon could not be stopped
# other if a failure occurred
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE
--name $NAME
RETVAL="$?"
[ "$RETVAL" = 2 ] && return 2
# Wait for children to finish too if this is a daemon that forks
# and if the daemon is only ever run from this initscript.
# If the above conditions are not satisfied then add some other code
# that waits for the process to drop all resources that could be
# needed by services started subsequently. A last resort is to
# sleep for some time.
start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec $DAEMON
[ "$?" = 2 ] && return 2
# Many daemons don't delete their pidfiles when they exit.
rm -f $PIDFILE
return "$RETVAL"
}
do_reload() {
#
# If the daemon can reload its configuration without
# restarting (for example, when it is sent a SIGHUP),
# then implement that here.
#
start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --name $NAME
return 0
}
case "$1" in
start)
[ "$VERBOSE" != no ] && log_daemon_msg "Starting
$DESC" "$NAME"
do_start
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
stop)
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping
$DESC" "$NAME"
do_stop
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
status)
status_of_proc "$DAEMON" "$NAME" && exit 0 ||
exit $?
;;
#reload|force-reload)
#
# If do_reload() is not implemented then leave this commented out
# and leave 'force-reload' as an alias for 'restart'.
#
#log_daemon_msg "Reloading $DESC" "$NAME"
#do_reload
#log_end_msg $?
#;;
restart|force-reload)
#
# If the "reload" option is implemented then remove the
# 'force-reload' alias
#
log_daemon_msg "Restarting $DESC" "$NAME"
do_stop
case "$?" in
0|1)
do_start
case "$?" in
0) log_end_msg 0 ;;
1) log_end_msg 1 ;; # Old process is still running
*) log_end_msg 1 ;; # Failed to start
esac
;;
*)
# Failed to stop
log_end_msg 1
;;
esac
;;
*)
#echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}"
>&2
echo "Usage: $SCRIPTNAME {start|stop|status|restart|force-reload}"
>&2
exit 3
;;
esac
:
/etc/xcp/pool.conf changed:
slave:31.186.98.97
-- no debconf information
Debian Bug Tracking System
2012-Jul-08 17:36 UTC
[Pkg-xen-devel] Bug#680588: marked as done (xcp-xapi: startup race condition between xcp-xapi and xcp-networkd on slave)
Your message dated Sun, 08 Jul 2012 17:32:48 +0000 with message-id <E1SnvLk-0003fg-Vd at franck.debian.org> and subject line Bug#680588: fixed in xen-api 1.3.2-9 has caused the Debian Bug report #680588, regarding xcp-xapi: startup race condition between xcp-xapi and xcp-networkd on slave to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner at bugs.debian.org immediately.) -- 680588: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680588 Debian Bug Tracking System Contact owner at bugs.debian.org with problems -------------- next part -------------- An embedded message was scrubbed... From: George Shuklin <george.shuklin at gmail.com> Subject: xcp-xapi: startup race condition between xcp-xapi and xcp-networkd on slave Date: Sat, 07 Jul 2012 06:20:05 +0400 Size: 9437 URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20120708/222dabe1/attachment.mht> -------------- next part -------------- An embedded message was scrubbed... From: Thomas Goirand <zigo at debian.org> Subject: Bug#680588: fixed in xen-api 1.3.2-9 Date: Sun, 08 Jul 2012 17:32:48 +0000 Size: 6933 URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20120708/222dabe1/attachment-0001.mht>
Seemingly Similar Threads
- Bug#681343: xcp-xapi: wait_for_xapi() function in init.d script does not work
- Bug#680528: xcp-xapi: /etc/init.d/xendomains cause xapi to hand during boot
- Bug#678719: xen-utils-common: please label all created directories for SE Linux
- Bug#742397: xen-utils-common: /etc/init.d/dom0weight is hardcoded to use xm
- Upgrading Samba 3 to Samba 4 - Domain Controller unreachable