Application customization for Live Update

Edit online

The AIX® Live Update operation performs the classification only during the Live Update operation.

Base processes
A base process is a process that does not participate in the Live Update operation. This process is not frozen or checkpointed. It does not have access to the network or data storage during the mobility phase of the Live Update operation. Base processes can be grouped as follows:
  • A set of core AIX services that continues to run in the Live Update operation after applications are checkpointed on the original partition and before they are restarted on the surrogate partition. These services are necessary because the memory associated with the moved processes is transferred asynchronously after they are checkpointed. So the original partition must be functional until all the memory is moved. All processes that are attached to the console of the original partition are marked as base processes because the console must remain associated with the original partition.
  • A set of services that are required to boot the surrogate partition to the point that it can communicate with the original partition and receive the moved processes. A customized /etc/inittab file is used to determine the services that start on the surrogate partition.
Mobile processes
Processes that are moved from the original partition to the surrogate partition as a part of the Live Update operation. All processes apart from the base processes are called mobile processes. Most workload processes are mobile processes. A mobile process has the same process ID (pid) or thread ID (tid) at the end of the Live Update operation. The mobile processes can be classified into the following groups:
  • Checkpointable processes: These processes are frozen and their state is checkpointed on the original partition. These processes are re-created on the surrogate partition.
  • Exit processes: These processes are frozen on the original partition. The Live Update operation does not checkpoint the state of these processes. These processes are re-created on the surrogate partition, but instead of restarting them at the instruction where they were checkpointed, they are forced to call the exit() function and terminate. Applications that are not impacted by its state when restarted can choose this method. These applications do not have to release resources that are not supported by the mobility operation. When these applications are monitored by a daemon mechanism (such as init or srcmstr), a new instance is started in the surrogate partition after they exit from the original partition.

For the Live Update operation to succeed, the following rules must be followed by the processes in the system:

  • A kproc is a base process.
  • The init process is a base process.
  • A direct child of init can be either a base process or a mobile process.
  • Children of a base process other than the init process are base processes.
  • A base process is either a direct child of the init process or the child of another base process.
  • Base processes do not share resources with non-base processes.

An application can register its processes as base process or exit process by using one of the following methods:

Static registration
Processes are registered by using the lvupdateSetProcs command. During the validation phase, the Live Update operation ensures that the rules for base processes are applied.
Dynamic registration
A process can register itself as a base process by using the proc_mobility_base_set() system call, or as an exit process by using the proc_mobility_restartexit_set() system call. The dynamic registration can occur only after the check notification is sent to the process. The system call ensures that the caller satisfies the base processes rules. Any existing child processes are automatically marked as a base process.

Inittab processes and init

When the surr_boot_rootvg volume group is cloned from the orig_rootvg volume group, the /etc/inittab file is replaced with a minimal set, which is designed for the Live Update operation. The following example shows a sample initab file:

:inittab.sur - live os update
init:2:initdefault:
brc::sysinit:/sbin/rc.boot 3 >/dev/console 2>&1 # Phase 3 of system boot
tunables:23456789:wait:/usr/sbin/tunrestore -R > /dev/console 2>&1 # Set tunables
securityboot:2:bootwait:/etc/rc.security.boot > /dev/console 2>&1
opt:2:wait:/usr/sbin/mount /opt
random:2:wait:/usr/sbin/randomctl -l
cons:0123456789:respawn:/usr/sbin/getty /dev/console
syslogd:2:once:/usr/sbin/syslogd >/dev/console 2>&1
slvupdate:2:wait:/usr/sbin/slvupdate >/dev/console 2>&1
ha_star:h2:once:/etc/rc.ha_star >/dev/console 2>&1

When the surrogate partition boots, it runs with the minimal set of processes to allow the Live Update operation to proceed.

Applications that prefer to be started as a part of the surrogate partition, can register to be included in the /etc/inittab file that is deployed on the surr-boot-rootvg environment by using the lvupdateInit command. These applications started from the inittab process are marked as base processes, hence these applications are not eligible to participate in any subsequent Live Update operation. In this case, the related kernel extensions must be loaded by the application started from the inittab process. These applications start in a running state on the surr-boot-rootvg environment. The chroot operation (changing the root directory) is performed on applications that are migrated from the original partition to the /old directory to run on the surr-mir-rootvg environment. The base applications that are started from the inittab process can access or chroot to the surr-mir-rootvg environment after the post notification.