2.5.3 OS user environment when a job is executed
Note the following when considering the job execution environment.
- Organization of this subsection
(1) User account at job execution
In JP1/AJS3, jobs are executed under the OS user account of the destination agent host. The destination agent host has a user mapping definition, which is used to convert the JP1 user who registered the job for execution to the OS user. The job is then executed under the OS user's permissions. The resources referenced or updated by the job process are dependent on the OS security control.
The user account is referenced each time a job is executed. Any changes to the definitions affect jobs executed after the changes are made.
In the Windows version of JP1/AJS3, when a job is executed under a user account other than the account from which the JP1/AJS3 service was started, JP1/AJS3 acquires the user information needed to start the job process. To acquire information about a user, an access token is required. The access token contains user information such as the security groups to which the user belongs and the user's access permissions.
Using Win32 API functions, JP1/AJS3 obtains an access token each time it starts a job, and releases the access token when the job completes execution. When an error occurs in one of these functions, the job is placed in the Failed to start status if the access token could not be acquired, or in the Ended abnormally status if the access token could not be released.
You can keep and reuse an access token if the domain name, user name, and password remain the same.
By reusing access tokens, you can minimize the number of times tokens are acquired and released, thus avoiding the temporary errors caused by the Win32 API functions. This results in fewer jobs ending abnormally. For details, see 6.2.17 Reusing access tokens for job execution in the JP1/Automatic Job Management System 3 Configuration Guide.
(2) OS user environment used for job execution
The OS user environment used to execute jobs is platform-dependent.
When a job is executed on a Windows agent host, the system environment variable normally takes precedence over the user profile information. However, you can enable the user profile information by specifying the environment setting for job execution control. For details, see 6.2.16 Executing a job that requires a user profile in the JP1/Automatic Job Management System 3 Configuration Guide.
When a job is executed on a UNIX agent host, JP1/AJS3 reads the local login script of the OS user mapped from the JP1 user. The OS user's login shell is set as the execution shell of the job, unless otherwise specified in the first line of the script file or command statement.
The OS user environment is read each time a job is executed. Any changes to a definition affects jobs executed after the changes are made.
(3) HP-UX OS user groups
When an OS user who executes jobs belongs to more than one group, and you want to enable access to all these groups, you must set /etc/logingroup; otherwise, only the group ID defined in /etc/passwd can be used.
To enable access to multiple groups, you must copy the /etc/group group definition into /etc/logingroup, or make a symbolic link between /etc/logingroup and /etc/group. For details, see your OS documentation.
- Cautionary note
-
To enable access to multiple groups when the process of a JP1/AJS3 service accesses a job result file or temporary file, see the setting described in 15.2.18 Enabling the file access permission check for the ACL and secondary group settings during job execution in the JP1/Automatic Job Management System 3 Configuration Guide.
If you do not perform this setting, access from a secondary group based on the entries in /etc/logingroup is possible only for a job process. Entries in /etc/logingroup do not apply to a JP1/AJS3 service process accessing a job result file or temporary file. If a JP1/AJS3 service process is unable to access a result file, either change the permission of the directory containing the result file to a permission that will allow access from a secondary group, or change the group that owns the directory or the specified result file from the secondary group to the primary group of the user executing the job. In the case of a temporary file, change the permission of the work directory to a permission that will allow access from a secondary group.
For details, see 2.6.2(3) Executing a standard job, action job, or custom job results in an abnormal end in the manual JP1/Automatic Job Management System 3 Troubleshooting.
(4) Access permission to job executable files and script files
For a job executed on a Windows agent host, set the access permission for the executable file in the JP1/AJS3 service account. You do not need to grant access permission to the OS user executing the job.
For a job executed on a UNIX agent host, grant access permission to the executable script file to the OS user.
(5) Login shell at job startup (Unix jobs, flexible jobs, HTTP connection jobs, and action jobs)
If the execution host (agent) is a UNIX host, the system executes the OS user's login shell (contents of the /etc/passwd file) at the destination agent host when a job is started. If no login shell is defined, /bin/sh is executed. In JP1/AJS3, sh, csh, and ksh can be used as login shells (For Linux, in addition to the csh, the bash can also be used). See the following precautions on using shells other than these three.
(a) Precautions for Unix jobs and flexible jobs
If you use a login shell other than sh, csh, ksh or bash, the login script might not be executed under certain OSs. Consequently, because the environment variable settings for the user executing the job are not applied, jobs might terminate abnormally, or return unexpected results. To avoid such problems, specify the environment variable settings required for executing a job script.
To check whether the environment variables needed for job execution are set properly, create a shell script that writes the execution results returned by the env command to a file, and then look at the contents of the file that is output when you execute this script as a job.
(b) Common precautions for jobs
Some shells, such as bash, do not initialize signal processing to the default status. As a result, jobs might terminate abnormally, or return unexpected execution results. In this case, use the sh, csh, or ksh shell instead.
Signal processing can be initialized to the default status by changing a setting as described in 15.2.17 Applying SIG_DFL (setting for receiving the SIGCHLD signal) to a child process started from JP1/AJS3 in the JP1/Automatic Job Management System 3 Configuration Guide. If you are performing a new installation of JP1/AJS3 or JP1/AJS2 version 08-00 or later, there is no need to change the setting because jobs are executed in these versions with the default setting (SIG_DFL) which allows child processes to receive SIGCHLD signals.