How does the RS_REBOOT environment variable work with Version 5 images and RightScripts?
Important! The RS_REBOOT environment variable is not available to Chef recipes in a RightLink run. For Chef, you should design your cookbooks to be idempotent i.e. multiple runs of a recipe restore the same state and do not have an undesired effect.
v4.X
When using v4.x (slightly older) images, we will set the RS_REBOOT flag upon a server/instance when the following actions are taken:
- Reboot
- Stop/Start actions
Take note that with later versions of v4.4.10, RS_REBOOT is not set on reboot (upgrade to a >= v5.7 MCI recommended).
v5.5.9
When using our v5.5.9 images (first GA release of Rightlink) we will set the RS_REBOOT flag upon a server/instance when these actions are taken:
- Reboot
- Operational
- Operational *after* Reboot
- Decommission
- Stop/Start actions
NOTE: We realize that this was a faulty configuration with this particular image generation, and have done our best to resolve this in v5.6 and newer images.
v5.6.28
When using our v5.6.28 images, we will set the RS_REBOOT flag upon a server/instance when these actions are taken:
- Reboot
NOTE: We do not set RS_REBOOT on a v5.6.28 image upon issuing a Stop or Start command.
IMPORTANT - It's important to note that when setting the RS_REBOOT flag in v5.6.28 images, we only set the flag on a Reboot operation when the server is rebooting! Once the server reaches an Operational state, the flag will no longer be set! Thus, any Operational scripts that are run after the reboot in an operational state will not see this flag!
v5.7 and v5.8
When using our v5.7 and v5.8 images, we will set the RS_REBOOT flag upon a server/instance when these actions are taken:
- Reboot
The behaviour can be demonstrated better with the following tables showing the status and actions for a server's runtime lifecycle:
RightLink Linux
| Boot/phase | Environment variable | Value |
| First boot | RS_REBOOT | -unset- |
| RS_ALREADY_RUN | -unset- | |
| *reboot action* | ||
| Decommission | RS_REBOOT | -unset- |
| RS_ALREADY_RUN | true | |
| Second boot | RS_REBOOT | true |
| RS_ALREADY_RUN | true | |
| *reboot action* | ||
| Decommission | RS_REBOOT | -unset- |
| RS_ALREADY_RUN | true | |
| Third boot | RS_REBOOT | true |
| RS_ALREADY_RUN | true | |
| *terminate action* | ||
| Decommission | RS_REBOOT | -unset- |
| RS_ALREADY_RUN | true | |
As seen above, RS_ALREADY_RUN can be used to detect a reboot action in the decommission phase after the reboot is triggered. Subsequently, RS_REBOOT can then be used in the next boot instigated by the reboot.
RightLink Windows
| Boot/phase | Environment variable | Value |
| First boot | RS_REBOOT | -unset- |
| RS_ALREADY_BOOTED | -unset- | |
| RS_ALREADY_RUN | -unset- | |
| *reboot action* | ||
| Decommission | RS_REBOOT | -unset- |
| RS_ALREADY_BOOTED | -unset- | |
| RS_ALREADY_RUN | true | |
| Second boot | RS_REBOOT | true |
| RS_ALREADY_BOOTED | true | |
| RS_ALREADY_RUN | true | |
| *reboot action* | ||
| Decommission | RS_REBOOT | -unset- |
| RS_ALREADY_BOOTED | true | |
| RS_ALREADY_RUN | true | |
| Third boot | RS_REBOOT | true |
| RS_ALREADY_BOOTED | true | |
| RS_ALREADY_RUN | true | |
| *terminate action* | ||
| Decommission | RS_REBOOT | -unset- |
| RS_ALREADY_BOOTED | true | |
| RS_ALREADY_RUN | true | |
Note: The decommission phase will only run when the server is rebooted via the RightScale API or dashboard as there is currently no way for RightLink to detect a reboot vs. a shutdown on Windows if instigated within the instance itself (e.g. via the start menu, command prompt or Powershell script). This is mainly due to Windows not supporting a mechanism such as runlevels (see below).
Runlevels
In addition to the RS_REBOOT and RS_ALREADY_RUN environment variables in RightLink, another strategy for logic in scripts is taking use of the current runlevel of the system after a reboot or terminate action has been instigated.
For information on runlevels for OS/distributions:
- http://www.debianadmin.com/debian-an...un-levels.html (Debian/Ubuntu)
- http://www.novell.com/documentation/...l/ch13s02.html (SUSE/SLES/OpenSUSE etc.)
| Termination/ runlevel change method | Runlevel (current) | Runlevel (new) |
|---|---|---|
| Terminate button (server) | 2 | 2 |
| Shrink action (server array instance) | 2 | 2 |
| shell command: shutdown -h now | 2 | 0 |
| Reboot button (server) | ||
| shell command: reboot | 2 | 6 |
Reboots
When a reboot is actioned locally on the system by the reboot or telinit 6 commands, this will reflect in the runlevel command output as (effecitvely) 6 (depending on the OS/distribution). This is a change from the current operating runlevel of 2-5.
Workarounds
In RightLink >= 5.7, during a soft decommission a runlevel change does not occur until after the phase run (see table above).
This means it isn't possible to detect a reboot vs. a terminate. For servers that require reboots, the following technique can be used:
- A Boot script ensures that /var/run/will_reboot is removed
- Reboot the server via an operational script that touches /var/run/will_reboot then executes rs_shutdown --reboot (as opposed to the Reboot button in the dashboard or RightScale API)
- A Decommission script checks for the existence of /var/run/will_reboot (if the file does not exist, the server is terminating not rebooting)
Note: This technique is only possible with autoscaling arrays if step 2. is always used as the reboot method i.e. always assume in decommission that the instance is terminating if /var/run/will_reboot does not exist as the vote shrink mechanism will terminate the instance conventionally.
Shutdowns (termination)
Additionally when the shutdown command is issued, e.g. shutdown -h now the runlevel will change to 0.
Testing
A ServerTemplate has been published to test your MCI/Machine Image to see the environment variables and runlevels (Linux only supports runlevels) used in different phases and by different reboot/shutdown actions:
- © Copyright 2015 RightScale Technical Support