First, the basic user environment
No User Specified
The environment for the job will be that of the user that is running the Agent.
Unix/Linux: that is usually “root”, and will be the user environment at the time the Agent was started. If the Agent is started as a daemon at system boot, the environment may be different than if the agent is started later, after root could have modified its environment.
Windows: that is the user configured to run the service, usually the local SYSTEM account. This account does not have a specific environment associated with it, so it just inherits the global environment variables. It has access only to file shares that have permissions for “Everyone”.
Unix/Linux: the Agent switches the job’s owner to the specified user by using the “setuid” system call. This changes the owner of the running process to the user, but does not change the user’s environment. Specifically, it does not read the user’s “.profile”, “.login” or other file that typically sets up the environment for a user. So the basic environment is still that of the user that started the System Agent, usually “root”.
Windows: Windows requires that a user must be logged in before they can take ownership of a process. The Agent logs the user in, sets up their environment, then uses the system call “CreateProcessAsUser” to execute the job. The basic user environment will have both the global and user environment variables available. The process will have access to file shares where that user has permissions.
Environment variables from profile files in agentparm.txt
There are three possible profile files that can be specified in the agentparm.txt to make environment variables available to the job. These files can contain multiple lines in the format “VARNAME=value”. These will add environment variable named VARNAME with the value of value.
These files are read by the System Agent, then the various VARNAME=value parameters are passed to cybspawn (Unix/Linux) or su.exe (Windows) on the command line. They will show up in the command line printed in the first line of the job’s *.joblog file.
Variables in this file are loaded for every job. Typical use is to add the path to the AutoSys client executables to the job’s PATH variable.
Variables in this file are loaded for every job that was submitted by the MGRNAME manager. Typical use is to set the AutoSys AUTOUSER variable to point to a specific AutoSys instance configuration so the AutoSys clients will communicate with the right instance.
On Unix/Linux, it is also used to set the EWAGLOBALPROFILE environment variable. This specifies a file that will be sourced in the shell before the job is executed. It can contain any valid shell commands, including environment variables. In an AutoSys agent, this is usually set to “EWAGLOBALPROFILE=/etc/auto.profile”.
Variables in this file are loaded for every job that was submitted by the USERNAME user. Typically this is used to specify variables that are usually set up in the user’s “.profile”. In fact, the file can be set to just point to the user’s “.profile” file, if that file only contains environment variables and not arbitrary shell commands.
A profile file can be specified in the job definition. This gets sent to the Agent as an environment variable named EWA_ENV_SRC_1.
Order of processing
- Basic environment. Environment of user that started the agent (Unix/Linux: ususally root; Windows: usually local SYSTEM).
- [Windows:] Environment of user running the job
- Variables from global profile file (oscomponent.environment.variable)
- Variables from manager-specific profile file (oscomponent.environment.variable_MGRNAME)
- Variables from user-specific profile file (oscomponent.environment.variable_USERNAME)
- Variables from EWAGLOBALPROFILE and EWA_ENV_SRC_1
i.Variables from EWAGLOBALPROFILE
ii.Variables from EWA_ENV_SRC_1
i.Variables from EWA_ENV_SRC_1
ii.Variables from EWAGLOBALPROFILE
7. Variables passed as environment variables in the job definition