Tips for administrator
Tips for administrator
In order to operate properly, iTop maintenance operations and asynchronous tasks must be executed on a regular basis. In order to ease the installation, all the background tasks have been grouped to be launched from a single file:
The following features rely on the activation of cron.php
Use schedtask.exe or the 'at' command to schedule cron.php to run every 5 minutes.
schtasks.exe /create /sc minute /mo 5 /tn "iTop CRON" /tr "\"/var/www/itop/webservices/cron.cmd\""
Edit the crontab to execute the script every 5 minutes:
*/5 * * * * www-data /usr/bin/php /var/www/html/itop/webservices/cron.php --param_file=/etc/itop-cron.params >>/var/log/itop-cron.log 2>&1
cron.phpusing root user! You must launch the command with the same user that is used by the web server running iTop.
The page cron.php can also be executed through the web server. This is useful if you don't have access to the system (for example on shared hosting systems). In such a case you can rely on a web cron service to run it for you. But the frequency and execution times will probably be restricted compared to a natively scheduled job.
|param_file||Path to the parameters file|
|auth_user||User login - CLI mode only, if no parameters file is used||-|
|auth_pwd||User password - CLI mode only, if no parameters file is used||-|
|verbose||if set to 1, more information will be given, use this for troubleshooting. Beware: since the process runs continuously in background, the log files tend to become big pretty quickly. Don't set this options to 1 for a long period of time.||0|
|status_only|| (New in iTop 2.0.1) if set to 1, a status about the scheduled tasks is displayed and the process stops immediatly (can be launched in parallel to the normal execution ||0|
Since the arguments passed to cron.php on the command line are visible to other users on the system, a recommended practice is to move all the sensitive parameters away from the command line. This is the purpose of the “parameter file”.
The argument param_file can be used with most of the REST/CLI web services. By convention, the cron.php service searches for a parameter file name « cron.params » to read its parameters from.
# This is a parameter file # # If a parameter is given both in the file and in the arguments, # then the value given as argument is retained # # Authentication auth_user = qwertyuiop auth_pwd = ded!catedL0g1n # My web service size_min = 20 # Megabytes time_limit = 40 # Minutes
/etc/itop/on Linux systems would be a good location) or make a special exclusion rule in your webserver's configuration. Only the process that runs cron.php from the command line should be able to access this file.
Those settings are configured into the main iTop configuration file: “itop-config.php”
|cron_max_execution_time||Duration (seconds) of the page cron.php, must be shorter than php setting max_execution_time and shorter than the web server response timeout||600|
|cron_sleep||Duration (seconds) before cron.php checks again if something must be done||2|
|email_asynchronous||If set to 1, the emails are sent off line, which requires cron.php to be activated. Exception: some features like the email test utility will force the serialized mode||0|
Only administrators are allowed to execute
When a task is no more running, there are a few things to know:
priv_backgroundtaskcontains multiple information for each task, such as:
pausedas requested by an administrator (field status)
cron_max_execution_time. The task would of course stops at a point where it makes sense, for example for Mail To Ticket Automation, it could stop between the processing of 2 received Mails.
cron_max_execution_time, if yes it commits suicide (this is because a never ending process usually consumes memory which is not totally freed)
cron_sleepsecond before checking the table again for tasks ready to be executed.
A task seems to never be executed:
When a particular task encounters an issue which make it hangs in an infinite loop, cron.php might be stopped by the php
max_execution_time (usually not when running in CLI); in all cases the tasks which are following that one will never be executed. In the following run of cron.php, as the tasks are always executed in the same order, the same issue will probably occur again. For identifying the faulty task, you should
paused one after the other the tasks which you suspect to have this issue by setting their status in the
priv_backgroundtask table and see if you have stopped the faulty one. Such situation is usually due to a bug of the extension bringing that task, the task facing an unplanned situation.
The logfile should be monitored to generate alarm to get advanced notice of such issue.