George Shuklin
2012-Jul-12 13:35 UTC
[Pkg-xen-devel] Bug#681343: xcp-xapi: wait_for_xapi() function in init.d script does not work
Package: xcp-xapi Version: 1.3.2-9 Severity: normal Function wait_for_xapi in /etc/init.d/xcp-xapi does not work as intented. Symptoms: (on slave) /etc/init.d/xcp-xapi restart [....] Restarting The XenAPI server: xapiThe host toolstack is still initialising. Please wait. Cause: Line 'xe pif-scan host-uuid=${INSTALLATION_UUID}' called before xapi is fully synced with master. wait_for_xapi function in init.d script waiting for XAPI_STARTUP_COOKIE, but this is good only for master initialization. If host is slave, it cannot perform any (non-emergency) operations with database without established connection with master. I can't see normal solution here: 1) If we will wait master connection, script can hangs if master is down. 2) We can not remove pif-scan (AFAIK). But pif-scan should happens only if host is master (if host is slave it already do have properly initialized pif database and working management interface, at least in the past). Propose: check if host is master (/etc/xcp/pool.conf), and skip pif-scan and template creation if host is slave. Patch: root at lab-xh3:~# vim /etc/init.d/xcp-xapi root at lab-xh3:~# diff -u /etc/init.d/xcp-xapi.old /etc/init.d/xcp-xapi --- /etc/init.d/xcp-xapi.old 2012-07-12 17:27:46.000000000 +0400 +++ /etc/init.d/xcp-xapi 2012-07-12 17:32:52.000000000 +0400 @@ -104,16 +104,20 @@ # 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) + # Do some standard setup, e.g. pif-scan, template creation (maybe), only if host is master + grep master /etc/xcp/pool.conf >/dev/null + if [ $? -eq 0 ]; + then . /etc/xcp/inventory - xe pif-scan host-uuid=${INSTALLATION_UUID} + 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 + # 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 + md5sum /usr/lib/xcp/lib/create_templates > $TEMPLATES_MD5_STAMP + fi fi fi } -- 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.234-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-9 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-9 ii xcp-squeezed 1.3.2-9 ii xcp-storage-managers 0.1.1-2 ii xcp-v6d 1.3.2-9 ii xcp-xe 1.3.2-9 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 # 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
Bastian Blank
2012-Jul-12 17:38 UTC
[Pkg-xen-devel] Bug#681343: xcp-xapi: wait_for_xapi() function in init.d script does not work
On Thu, Jul 12, 2012 at 05:35:08PM +0400, George Shuklin wrote:> + # 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_STAMPWhas is this and why is it in the init script instead of the postinst script? Bastian -- I'm a soldier, not a diplomat. I can only tell the truth. -- Kirk, "Errand of Mercy", stardate 3198.9
Debian Bug Tracking System
2012-Nov-18 15:03 UTC
[Pkg-xen-devel] Bug#681343: marked as done (xcp-xapi: wait_for_xapi() function in init.d script does not work)
Your message dated Sun, 18 Nov 2012 15:02:56 +0000 with message-id <E1Ta6Oe-0005Y3-GN at franck.debian.org> and subject line Bug#681343: fixed in xen-api 1.3.2-13 has caused the Debian Bug report #681343, regarding xcp-xapi: wait_for_xapi() function in init.d script does not work 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.) -- 681343: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681343 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: wait_for_xapi() function in init.d script does not work Date: Thu, 12 Jul 2012 17:35:08 +0400 Size: 11011 URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20121118/9cec34d0/attachment-0002.mht> -------------- next part -------------- An embedded message was scrubbed... From: Thomas Goirand <zigo at debian.org> Subject: Bug#681343: fixed in xen-api 1.3.2-13 Date: Sun, 18 Nov 2012 15:02:56 +0000 Size: 6667 URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20121118/9cec34d0/attachment-0003.mht>
Seemingly Similar Threads
- Bug#680588: xcp-xapi: startup race condition between xcp-xapi and xcp-networkd on slave
- Bug#680528: xcp-xapi: /etc/init.d/xendomains cause xapi to hand during boot
- Bug#655302: xcp-xapi: init script will slow down boot process
- xen-api_1.3.2-13_amd64.changes ACCEPTED into unstable
- Bug#678723: xcp-xapi: vif-interfaces added to database as PIF's