You are not logged in.
Hello everybody,
I experience an increasing size of the tables glpi_crontasklogs and glpi_events.
By having a look at the code it seems that CronTask::cronLogs is calling methods to cleanup those tables, but obviously this method is never called.
Can anybody give me a hint what is the mechanism to cleanup those tables:
(1) Is it done internally by GLPI in some way?
(2) Do I have activate an automatic task (if so, which one) and schedule it?
(3) Do I have to clean those tables manually with SQl commands as DB-admin?
Used GLPI-version: 9.3+1.1
Additional hint: the purgelog plugin, now implemented in the GLPI core with 9.3, does cleanup the table glpi_logs but not the before mentioned tables.
Any ideas welcome - thanks in advance!
Best regards,
Ruediger
Offline
Problem solved by further code reading and testing:
1. There's an automatic action (Setup -> Automatic actions) called "logs" which cleans up old entries in glpi_crontasklogs and glpi_events
2. For each task specify "Number of days this action logs are stored" (the logs are written to glpi_crontasklogs), the "logs" action will filter and remove entries which are older than this value
3. In the "logs" action specify for "System logs retention period (in days, 0 for infinite)" a time how long entries in glpi_events are kept.
Probable pitfall: Some actions allow a periodicity of 1 minute. IF "GLPI" is chosen as Run Mode then check in which periodicity cron.php is called - if the periodicity of the action is smaller than the periodicity of cron.php then you might get an unexpected behaviour.
By starting GLPI a cron job e.g. like this is created:
echo "*/2 * * * * www-data /usr/bin/php /var/www/html/glpi/front/cron.php &>/dev/null" >> /etc/cron.d/glpi
service cron start
in this case cron.php gets executed every 2 minutes...
Problem solved - no further assitance needed!
Offline