Resource manager operations

The first process in the UNIX/Linux kernel is the init process which creates and starts (spawns) the system resource controller (src). As shown in the following figure, the system resource controller is responsible for the System Automation for Multiplatforms resource managers.

The global resource manager creates additional processes to run the start, stop, and monitor commands of an IBM.Application resource. All commands created by the global resource manager run in the shell of the specified user. Here is some pseudo code of this functionality:

{
  fork;
  if child
    switch to specified user ID;
    run the users default shell and execute the command e.g.
      bash -c /usr/bin/mycommand;
  endif
}

The command itself, such as mycommand in the previous shown pseudo code, can be any executable including shell scripts which may create additional processes or use job control.

The following describes various scenarios:

IBM.Application is defined in asynchronous command mode:
```
StartCommand="/usr/bin/mycommand"
RunCommandsSync=0
```
In this case the global resource manager creates (forks) a process for the command, then it completely detaches from the new process and closes all file descriptors to the new process.
The global resource manager does not take care of the new process anymore, and in theory the command could run forever.

Since the new process does not have a parent anymore, it becomes an orphan and is adopted by the init process. When the process eventually ends, init will collect the return code of the process.
IBM.Application is defined in synchronous command mode:
```
StartCommand="/usr/bin/mycommand"
RunCommandsSync=1
```
Here the Global Resource Manager does not detach itself from the newly created (forked) process. File descriptors are open, and the resource manager waits for completion of the command:
- If the command returns a bad return code, messages from stderr are captured and written to the global resource manager trace and error block of the start or stop command.
- If the command does not return within the time specified in the StartCommandTimeout attribute, the global resource manager sends SIGKILL to the forked process (the users default shell). SIGKILL is propagated to all child processes of the user shell and therefore all child processes should end.
IBM.Application is defined in synchronous command mode, but uses job control of the user shell:
```
StartCommand="/usr/bin/mycommand &"
RunCommandsSync=1
```
In this setup, the user default shell will not end until all child processes which have open file descriptors to the shell have ended. Here the time specified in the StartCommandTimeout attribute also applies to mycommand, even it is run in background of the user shell. So if mycommand runs longer as the time specified in the StartCommandTimeout attribute, the global resource manager will send SIGKILL to the user shell and it will propagate SIGKILL to all background process.
If you want to make this setup working, you must make sure that all file descriptors of the shell child process are detached from the shell. This may look like:
```
StartCommand="/usr/bin/mycommand > /dev/null 2>&1 &"
RunCommandsSync=1
```
Now the user shell can end right after it has created (forked) the process for the command and has detached from the file descriptors of the new process. The command mycommand itself behaves as described in the first scenario, it becomes an orphan and is adopted by the init process.