cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wido den Hollander (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-3880) /sbin/poweroff et al or ACPID initiated shutdown does not stop cloudstack-[usage|management]
Date Tue, 30 Jul 2013 13:01:54 GMT

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-3880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13723826#comment-13723826
] 

Wido den Hollander commented on CLOUDSTACK-3880:
------------------------------------------------

I'm not sure if this is a blocker, is it really? Since all the DB work we do goes via transactions,
aren't we semi-safe here? I don't say the current way is good, we do need to fix this, but
imho it doesn't mean database corruption perse?
                
> /sbin/poweroff et al or ACPID initiated shutdown does not stop cloudstack-[usage|management]
> --------------------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-3880
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3880
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Management Server, Usage
>    Affects Versions: 4.1.1
>         Environment: manager running on RHEL64 (variant, OEL64)
>            Reporter: Ove Ewerlid
>            Priority: Blocker
>              Labels: patch
>             Fix For: 4.1.1
>
>
> cloudstack-management has custom stop() that does not handle finding the PID file if
invoked via S|K runlevel links. Interactive use works. 
> cloudstack-usage start() does not create the /var/run/subsys lockfile causing the stop()
function to not be invoked. Interactive use works.
> cloudstack-usage lacks runlevel # settings, causing default 50 to be selected and this
causes stop() to run after mysqld has been shutdown.
> effect of this can be data base corruption
> Here is a possible fix;
> [root@slc00xfr rc.d]# diff -c -r init.d.ref init.d
> diff -c -r init.d.ref/cloudstack-management init.d/cloudstack-management
> *** init.d.ref/cloudstack-management    2013-07-26 17:33:05.000000000 +0100
> --- init.d/cloudstack-management        2013-07-27 18:36:43.000000000 +0100
> ***************
> *** 44,49 ****
> --- 44,52 ----
>   NAME="$(basename $0)"
>   stop() {
> +         if [ "${NAME:0:1}" = "S" -o "${NAME:0:1}" = "K" ]; then
> +           NAME="${NAME:3}"
> +         fi
>         SHUTDOWN_WAIT="30"
>         count="0"
>         if [ -f /var/run/${NAME}.pid ]; then
> diff -c -r init.d.ref/cloudstack-usage init.d/cloudstack-usage
> *** init.d.ref/cloudstack-usage 2013-07-26 17:33:05.000000000 +0100
> --- init.d/cloudstack-usage     2013-07-27 18:36:53.000000000 +0100
> ***************
> *** 2,7 ****
> --- 2,8 ----
>   ### BEGIN INIT INFO
>   # Provides:          cloud usage
> + # chkconfig: - 79 21
>   # Required-Start:    $network $local_fs
>   # Required-Stop:     $network $local_fs
>   # Default-Start:     3 4 5
> ***************
> *** 96,101 ****
> --- 97,103 ----
>       if [ $rc -eq 0 ]; then
>           success
> +         touch $LOCKFILE
>       else
>           failure
>           rm -f "$PIDFILE"
> [root@slc00xfr rc.d]#

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message