How does the AutoSys 4.x auto_remote work?

Products

• CA Workload Automation AE - Business Agents (AutoSys)
• CA Workload Automation AE - Scheduler (AutoSys)
• Workload Automation Agent

Issue/Introduction

Description:

Details of how the auto_remote process is invoked and where it gets it's environment.

Solution:

1. The event processor processes a STARTJOB or other event and determines that a job is to be started on a remote agent machine.
   
   
2. The event processor opens an inet socket to the remote agent machine, using the port number specified on the AutoRemPort parameter of the $AUTOUSER/config.$AUTOSERV file.
   
   
3. When the inet socket is opened on the remote agent machine, the operating system notifies the inet daemon (inetd).
   
   
4. The inet daemon identifies the service associated with the port number in in the /etc/services file.
   
   
5. The inet daemon obtains the configuration of the service from the /etc/inetd.conf file.
   
   
6. The inet daemon attaches the inet socket to stdin and does a fork() system function call. The parent side of the fork() releases stdin.
   
   
7. The child side of the inetd fork() issues a setuid() system function call using the userid specified as parameter 5 of the /etc/inetd.conf configuration file.
   
   
8. The child side of the inetd fork() next issues an exec() system function call using the binary specified in parameter 7 of the /etc/inetd.conf configuration file. This is the auto_remote binary, running as a child process of the inetd inet daemon.
   
   
9. The auto_remote binary reads the job definition from stdin (ie. the inet socket), including the job owner. Additional parameters include: t he database connect string, the event server database ID and its encrypted password.
   
   
10. The auto_remote binary opens a log file for writing, and opens the /etc/auto.profile file for reading.
    
    
11. The auto_remote scans the /etc/auto.profile file for lines beginning with the string "#AUTOENV#"; when found it calls the putenv() system function with the remainder of the line as the parameter. The putenv() accepts a string of the form name=value and places it in the environment list.
    
    
12. The auto_remote binary issues a fork() system function call. The parent of the fork() writes a RUNNING status to the event table and issues a waitpid() for the child side of the fork().
    
    
13. The child side of the fork() "becomes" the job owner via getpwnam(), setgid(), initgroups(), and setuid() system function calls. It also sets the HOME environment variable (via putenv() with information from the getpwnam() call).
    
    
14. The child side of the fork() builds a command string (visible in the remote agent log file on the line beginning with "Executing cmd->"), and uses the exec() system function call to invoke the /bin/sh command with the -c option, using the command string on the -c option.
    
    
15. The command string consists of a number of semi-colon delimited statements; the last statement before "exec <command>" is the sourcing of the /etc/auto.profile (or the file specified in the job definition).
    
    
16. When the command string ends, the child process terminates. This completes the waitpid() function of the parent, which writes the completion states to the event server database with the exit code of the child.

Notes on the above:

1. The environment of the user job is:
   
   
   • inherited from init.
     
     
   • inherited from inetd (normally started by init).
     
     
   • inherited from auto_remote (ie. #AUTOENV# settings).
     
     
   • sourcing /etc/auto.profile.
     
     
2. The /etc/auto.profile is used twice in two different contexts:
   
   
   • Read by the auto_remote and scanned for lines beginning #AUTOENV#, which are subsequently put into the environment list.
     
     
   • Sourced by the user job just before the shell exec of the command.
     
     
3. The /etc/auto.profile >MUST< contain a line:

   #AUTOENV#TNS_ADMIN=<directory> (Oracle only!)

   This is required so the auto_remote parent process can write the RUNNING and SUCCESS/FAILURE/TERMINATED change status events to the event server database. For Sybase #AUTOENV#SYBASE=<directory>

4. If there will be a shadow event processor running on the machine, the /etc/auto.profile must contain:

   #AUTOENV#TZ=<timezone>#AUTOENV#EDVersionStar=*

   These are required by the event processor. They are not needed for other remote agents.

5. For Oracle based systems, all AutoSys binaries are statically linked against Oracle libraries, most link with Oracle version 8.1.7 libraries, AIX 5.x is linked with Oracle 9.2.0 libraries to support the 64 bit operating system. For Sybase based systems, all AutoSys binaries are statically linked against Sybase libraries.
   
   
6. Oracle only! For National Language Support for database messages from AutoSys binaries the ORA_NLS33 may need to be set to the $AUTOSYS/oracle/nls33, ie:
   

   #AUTOENV#ORA_NLS33=<directory>

   The nls files in $AUTOSYS/oracle/nls33 will always match the version of the Oracle libraries that the binaries in $AUTOSYS/bin were linked to.

7. If other environment variables are set in the /etc/auto.profile, they will be inherited by all user jobs that run on that remote agent machine, ie:

   #AUTOENV#ORACLE_HOME=<directory>#AUTOENV#SYBASE=<directory>

8. If environment variables are incorrect for the user job environment they may be unset in the /etc/auto.profile:

   unset ORACLE_HOMEunset ORA_NLS33unset SYBASE

Environment

Release: ATSY1C99000-4.5-AutoSys-Job Management-Class 1 Remote Agent
Component: