Table of Contents
Description
Use this option to edit the stop script that will be executed at service shutdown upon manual request or during the Charon Linux server shutdown procedure.
The script is unique and uses the configuration file (full name) to select commands to be executed at guest shutdown (selected by "case in...").
If the script does not exist, it will be generated automatically based on existing guests list and will by default do nothing except preparing the script skeleton with commands using the provided script examples to perform the shutdown via either "expect
", "rsh
" or "ssh
". Newly added virtual machines will have their "case" added to the script when it will be edited.
To be able to perform a clean shutdown of your virtual machine, you will have either to use the provided scripts (see above) or to add your own shutdown scripts.
Basic knowledge of shell programming is needed to implement the clean shutdown / stop script.
Method | Comments |
---|---|
expect | Requires you pass user and password to the script so that it can connect to the console via "
This method is useful if the virtual machine has no telnet connection available and cannot handle " Important notes:
|
rsh | Requires a trust to be created between the Linux server and the HP-UX guest to issue password free remote commands. For more, please read the Tips and Tricks chapter dedicated to rsh trusts. If 'rsh' is not installed on the Linux server, please run "# yum install rsh" (CentOS7/RHEL7) or "dnf install rsh" (CentOS8). For RHEL 8, please read the Tips and Tricks chapter dedicated to rsh installation on RHEL8. |
ssh | Requires a secured trust to be created between the Linux server and the HP-UX guest (key pair) to issue password and passphrase free remote commands. For more, please read the Tips and Tricks chapter dedicated to ssh trusts. |
Shutdown timeout
If your application and server need time to shutdown, it could be necessary to give more time in the service definition to prevent from the service stop procedure to fail due to timeout.
To do so, open the "Manage 'systemd' services
" option and edit the service configuration file. You can then add the TimeoutStopSec=
parameter in the Service
section. The default value is 20 minutes and can be changed in the preferences menu options.
Example:
|
More information can be found using the "# man systemd.service
" command on your Linux server
Options
- Options 1 to 3 are explanations on how to setup and prepare the virtual machine and the Charon Linux server (if necessary) to use the three available methods.
- Option 4 edits the script. This script is in a form of "case in <configuration filename> do ..."
- Option 5 is used to test the script. Use with caution on production machines.
You'll find in options 1 to 3 all the details to setup the remote connection: packages to install, proxy settings for rsh, key pair definition for ssh (password and passphrase free), the necessary firewall settings if needed, etc...
Common stop script explanation
When the script is initialized using option 6 or when a new virtual machine is added, the following lines are added:
...
...
|
One of the blue colored lines above has to be uncommented depending on the method chosen. Other lines can remain in the script or can be deleted.
Notes:
- The values between the < and > signs have to be filled manually.
- The operating system must be set to either HPUX or MPEIX (case insensitive).
- If the "rsh" or "ssh" method is used, the <hostname>, corresponding to the virtual machine hostname, must be known by the Charon Linux server.
- if MPEIX is defined, only the "expect" method can be used. Username, password and prompt can be set to "X" as they are not needed. Example:
${CHARONDIR}/utils/charon_gstop_expect \$1 \$2 X X X MPEIX
Stop script content example:
The editor defined in the Preferences is used to edit the script.
...
|
Stop script execution example with "ssh" / HP-UX 11.23:
Stop script execution example with "expect" / MPEiX:
Provided shutdown scripts explanation
Whatever the shutdown script execution result is, the stop request sent by the systemctl
command will stop the emulator. It is very important then to ensure the stop script has been tested and validated.
charon_gstop_expect
- Check if there's an active connection to the console on the local host, kill if any.
- Execute the /opt/charon/utils/guest_shutdown.exp expect script with the values provided: username (root), password, prompt (for HP-UX only), operating system (either HPUX or MPEIX). This script is able to send the shutdown command depending on the returned characters on the console.
- Report all output to
/opt/charon/log/console.stop.<guest name>.log
.
Notes:
- If the "Main Menu" prompt is found, the "
exit
" command is sent to stop the emulator. - If the "ISL>" prompt is found, a "
reset
" command is sent then waits for the "Main Menu" prompt and sends the "exit" command is sent to stop the emulator. - If the console is locked from an external connection or if the prompt is not detected after sending a carriage return, the expect script will fail.
charon_gstop_rsh
Check the guest can be reached via ping, if yes:
Issue the
shutdown
command via "rsh" (depends on the operating system),Wait for a few seconds
Check if the guest can be "pinged" and repeat with an interval of 5 seconds
If the guest cannot be pinged, assume the shutdown procedure is complete
Kill the emulator process and reset the service state. The shutdown commands does not power off nor stop the emulator process, that's why this operation is needed
Report the stop information within the guest log file
charon_gstop_ssh
Check the guest can be reached via ping, if yes:
Issue the
shutdown
command via "ssh" (depends on the operating system),Wait for a few seconds
Check if the guest can be "pinged" and repeat with an interval of 5 seconds
If the guest cannot be pinged, assume the shutdown procedure is complete
Kill the emulator process and reset the service state. The shutdown commands does not power off nor stop the emulator process, that's why this operation is needed
- Report the stop information within the guest log file