7.4 Notes on using Unix jobs
This section gives notes on using Unix jobs.
Read this section in conjunction with 2.6.2 Troubleshooting problems related to standard jobs, HTTP connection jobs, action jobs, and custom jobs in the manual JP1/Automatic Job Management System 3 Troubleshooting, which provides information about what might cause a Unix job to fail to start or end abnormally, and cautionary notes about using Unix jobs.
-
Return codes that can be set by jobs executed in UNIX
Jobs executed in UNIX can set return code values from 0 to 255. When a job fails to start, or when acquisition of standard output data or standard error output data fails, the return code is set to -1.
-
Preventing jobs from entering Failed-to-start status (in UNIX)
When the agent host is a UNIX host, a job might enter Failed to start status. To prevent this, make sure that the user who starts the JP1/AJS3 service and the OS user who executes the job have read and write permissions for the following files and directories:
-
Standard output file for the job
-
Standard error output file for the job
-
Work directory at agent process execution
-
Work path specified in the job's detailed definition#1
-
Home directory of the OS user who executed the job#1
-
Log files used for job execution control#2
- #1
-
The work path specified in the detailed definition of the job is the current directory at the time the job is executed. If you do not specify a work path, the home directory of the OS user is assumed. If no home directory is defined for the OS user, root (/) is assumed.
- #2
-
For details about the log files used in job execution control, see 1.2.5 List of log files and directories in the manual JP1/Automatic Job Management System 3 Troubleshooting.
-
-
Resource limits when Unix jobs are executed
In JP1/AJS3 for UNIX, the resource limits in effect at JP1/AJS3 startup apply when a job is executed. To apply resource limits, set them for the root user who starts JP1/AJS3. However, if you specify a limit in the job to be executed, the value specified in the job takes effect. For details, see 20.5 Setting up the job execution environment in the JP1/Automatic Job Management System 3 Configuration Guide.
The following is an example of changing file size limits:
-
In the login profile for the root user (usually [/.profile] ($HOME/.profile)), include the setting below:
For fsize, specify the required file size. If you do not want to impose a limit, specify unlimited.
ulimit -f fsize
-
Log in as the root user.
-
From the root account, start the JP1/AJS3 service.
The fsize value takes effect.
- Cautionary note
-
In AIX and Linux, the resource limits you define in the resource settings file for the OS (AIX: /etc/security/limits, Linux: /etc/security/limits.conf) apply only to processes started by users using the login command over a telnet connection or similar. Because jobs started by JP1/AJS3 take the form of processes started by a service, the settings in the file do not apply.
-
-
Precautions applying when the JP1/AJS3 service starts automatically
In a system where the JP1/AJS3 service starts automatically, the login profile of the root user is not loaded. For this reason, even if you change the resource limits in the login profile of the root user, different limits might apply when you log in manually and start the JP1/AJS3 service. In this case, set resource limits in the environment setting parameters of the job execution environment. For details about these parameters, see 20.5 Setting up the job execution environment in the JP1/Automatic Job Management System 3 Configuration Guide.
You can also write resource limits into the automatic start script (/etc/opt/jp1ajs2/jajs_start) of JP1/AJS3. If you do so, test your settings thoroughly before using the system.
Note that jobs might be executed under a group ID that differs from the group ID set for the root user at login. For details, see 5.4.12 Group ID for job execution (UNIX only) in the manual JP1/Automatic Job Management System 3 Overview.
-
Explicitly declaring the umask value for a job process in the profile of the job execution user or the executing shell
Job processes started by the JP1/AJS3 service adopt the umask value of the shell that started the JP1/AJS3 service, unless a umask value is explicitly declared.
If you specify the value of umask in a profile of the job-execution user such as /etc/profile and $HOME/.profile, the value in the profile overwrites the value of umask in the shell that started the JP1/AJS3 service.
You must explicitly specify the value of umask for the job process in a profile of the job execution user or the shell.
To change the value of umask for the standard output file and the standard error output file that are specified in a job definition, see 5.4.7 Value of umask set for the standard output file and the standard error output file (UNIX only) in the manual JP1/Automatic Job Management System 3 Overview.
-
Using a value other than /bin:/usr/bin as the PATH environment variable
When you start a job from JP1/AJS3, JP1/AJS3 explicitly specifies /bin:/usr/bin for the PATH environment variable. If you want to specify a different value, define it in the command or script file that you specify when defining the job, or in the local login script.
-
Executing a user program that requires a terminal as a job
In the UNIX version of JP1/AJS3, a user program that requires a terminal might not operate correctly if executed as a job (the job might end abnormally).
-
Changing OS user information for the login shell or other feature when using queueless jobs
If OS user information for the login shell or other feature is changed when you use a queueless job, use either of the following methods to clear the cache:
-
Execute the ajsqlalter command with the -r option specified.
-
Restart the queueless agent service.
-
-
Registering or changing an OS user
While a job is running, do not use the passwd command with administrator privileges to register or update the OS user associated with the job. Register or update the OS user information before you run the job.
-
Executing the jajs_dbbackup command from a Unix job with the backup enhancement function enabled
If you execute the jajs_dbbackup command by specifying an embedded database with a Unix job defined, the status of the Unix might not change from the following statuses even if the job has been executed. In this case, however, the Unix job status will change normally after the jajs_dbbackup command terminates.
-
Waiting to execute
-
Now queuing
To avoid such situations, make sure that the Unix job that executes the jajs_dbbackup command is defined in the scheduler service that runs on an embedded database that is not to be backed up.
For an overview of the backup enhancement function, see 5.2.5 Backing up and recovering an embedded database by using the backup enhancement function in the JP1/Automatic Job Management System 3 System Design (Configuration) Guide.
-