Difference between revisions of "Rebooting"

From WPKG | Open Source Software Deployment and Distribution
Jump to: navigation, search
m (command exited with a given code)
m
 
Line 29: Line 29:
 
     Other possible values are reboot='postponed', reboot='false', and undefined,
 
     Other possible values are reboot='postponed', reboot='false', and undefined,
 
     which defaults to 'false' - see down below for more details.
 
     which defaults to 'false' - see down below for more details.
 +
  
 
== rebooting after executing all commands ==
 
== rebooting after executing all commands ==

Latest revision as of 17:35, 4 September 2008

WPKG can reboot the machine if needed. Rebooting can be defined in a package definition in two places:

  • after a command exited with a given code,
  • after all commands were executed.


command exited with a given code

Here, we schedule a reboot when the below command exited with code 3010. Note where 'reboot="true"' entry is located:

<install cmd='msiexec /qn /i "%SOFTWARE%\package.msi"' >
         <exit code="3010" reboot="true" />
         <exit code="0" />
</install>
<install cmd='%SOFTWARE%\fix_icons.bat' />
    The reboot=true attribute on an exit code forces an immediate reboot.
    Unfortunately all following commands are skipped then. Sometimes
    (maybe even more often) you might like to just set the package reboot
    flag depending on a command exit code. Therefore, you can use
    reboot='delayed' within the command nodes. This allows to schedule a
    reboot instead of immediately executing it. The effect is the same
    as setting reboot='true' on package level (reboot after executing
    all commands. However it allows you to leave reboot='false' on package
    level and schedule a reboot based on command exit codes.

    Other possible values are reboot='postponed', reboot='false', and undefined,
    which defaults to 'false' - see down below for more details.


rebooting after executing all commands

To reboot after all commands were executed, define your package similarly to the one below. Note the 'reboot="true"' entry:

<package
    id="sample_package"
    name="This package will reboot after "
    revision="1"
    reboot="true">

    <check type="uninstall" condition="exists" path="Sample entry in Add or Remove Programs" />

    <install cmd='"%SOFTWARE%\sample\myprogram.exe" /silent'>
    <install cmd='"%SOFTWARE%\sample\fixlinks.bat'>

    <remove  cmd='%PROGRAMFILES%\sample\uninst.exe -quiet' />

    <upgrade cmd='"%SOFTWARE%\sample\myprogram.exe" /silent' />
    <upgrade cmd='"%SOFTWARE%\sample\fixlinks.bat'>
</package>


    "true", "false" and "postponed" are allowed as a value of the reboot attribute
    within the package node. The states have the following effect:

    "true"      Immediate reboot after package installation.
                This will take precedence of any command-level reboot="postponed"
                attribute if present and reboot immediately after package
                installation.
                A reboot="true" attribute on command-level will still result in
                an immediate reboot.
                Resulting status depending on command-level reboot flag:
                "true"      immediate reboot after command execution
                "delayed"   reboot after package installation
                "postponed" reboot after package installation
                "false"     reboot after package installation

    "postponed" Schedule reboot after installing all packages within this
                session, for example after synchronizing.
                Resulting status depending on command-level reboot flag:
                "true"      immediate reboot after command execution
                "delayed"   reboot after package installation
                "postponed" reboot after all actions are completed
                "false"     reboot after all actions are completed

    "false"     No reboot unless one is defined at command-level.

    or not set  Resulting status depending on command-level reboot flag:
                "true"      immediate reboot after command execution
                "delayed"   reboot after package installation
                "postponed" reboot after all actions are completed
                "false"     no reboot

    As a result there are four possibilities to schedule a reboot in order of
    precedence:

    immediate   Command node specified reboot=true, immediate reboot takes place.

    package     Reboot is issued right after installing:
                - package specifies reboot="true"
                  OR
                - any command node specified reboot="delayed"

    postponed   Reboot will take place after all packages have been applied.
                - package specifies reboot="postponed"
                  OR
                - any command node specified reboot="postponed"

    none        No reboot is issued by this package:
                - package does not specify reboot or specifies reboot="false"
                  AND
                - no command node specified any form of reboot reboot

    This means that an immediate reboot always has the highest priority. You
    can just set "reboot markers" on a "timeline" on package and command level
    where the closest reboot marker will be executed:
    immediate => package => postponed => none

    Exit code 0 is not any more automatically regarded as "successful" value.
    Even code 0 is now evaluated by exit code nodes. If no node is found it is
    still assumed that the command was successful. This allows administrators
    to schedule a reboot (immediate/delayed/postponed) even on exit code 0.