TOOLS-2964 - Improve to support running multiple auto-task and restarting cub_auto process
2. Stop CUBRID manager process using the following command:
> cubrid manager stop @ cubrid manager server stop ++ cubrid manager server stop: success
3. Add two configuration items to %CUBRID%/conf/cm.conf.( Screenshot )
auto_job_timeout 43200 mon_cub_auto yes
4. Replace %CUBRID%/bin/cub_auto.exe and %CUBRID%/bin/cub_js.exe with the files in the patch package.
In Linux, replace $CUBRID/bin/cub_auto and $CUBRID/bin/cub_js with the files in the patch package.
5. Start CUBRID manager process using the following command:
> cubrid manager start @ cubrid manager server start ++ cubrid manager server start: success
The following parameteres were newly added:
- auto_job_timeout: Auto jobs execution timeout (sec)
Default value: 43200 (12 hours) , Minimum value: 60
- mon_cub_auto: Allowing cub_js to restart cub_auto process, if cub_auto is not running.
Default value: NO
When cub_auto process starts an auto job, it will start another process to execute a shell command of the auto job, and wait the command to return.
Now in the patches, the cub_auto will start a thread, then the thread will start another process to execute the shell command. When cub_auto process finds the thread executing too long (exceed the max executing time), the cub_auto will cancel the thread. But it can't cancel the process which executing the shell command, so the shell command process only can exit when the command is finished. The max executing time is very long (The default value is 12 hours), so the cancel operation is rarely happened. And mostly, the command process will execute successfully. But the success information of auto job can't be logged. And there is one potential problem exist, if the auto job was a period job, and the shell command was hung up by some unkown reason, the command process can't exit. As time goes, the will be a lot of such kind of processes. This issue will be solved in the future version of CUBRID Manager service.