GLPI – Cleaning

12. 5. 2022 - Nezařazené

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!



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!

Napsat komentář

Translate »