You are not logged in.
Pages: 1
Hello all.
I have some issue with mailgate and cron. I found in cron.log that sometimes after mailgate acction starts cron cannot use database (log in cron.log is 'Can't get DB lock'). Mailgate cannot collect mails form mailbox or hangs up.
If someone had similar problem or maybe someone know how to fix it?
Offline
Version of GLPI used?
Number of automatic tasks launched in the same time (in GLPI configuration)?
Version of MySQL or MariaDB?
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Version of GLPI used?
Number of automatic tasks launched in the same time (in GLPI configuration)?
Version of MySQL or MariaDB?
Version 0.90.5
Maximal number of automatic actions (run by CLI) 7
MySQLd server version: 5.6.35-2.el7
Offline
When the cron freeze, is your database active?
Can you create an item in GLPI when cron is HS?
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Database is on the same machine as GLPI. In logs there is no information about issues with databes.
What is HS for Crone?
Offline
Your automatics tasks are in GLPI or LI mode?
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
CLI mode
Offline
Same issue here... Anyone?
Offline
Hello!
I have this problem since migrating from 9.0.5 to 9.16. I believe this is because before every state change of automatic actions, GLPI locks table glpi_crontasks and releases this lock after state change. What I think happens is:
1. first task starts: locks table, updates status, unlocks table
2. second task starts: locks table, updates status, unlocks table
3. one of the tasks ends: locks table, and...
4. other task ends: tries to lock table, but it's already locked... writes error into cron.log, ends without updating status
I've changed most of my tables engine to INNODB (unsupported, I know, but it works) and I'm wondering if it is safe to remove this locking mechanism from crontask class and replace it with row lock... Unlike MYISAM, there is no need to lock a table to do update, because you can do it on row level in INNODB. I think this would prevent this scenario from happening.
As of now, I'm using this script: glpi/scripts/unlock_tasks.php in cron, but I had to modify it a bit: I removed "$cycle * `frequency`" and replaced it with "frequency" only, because it was too restrictive for me.
GLPI 9.5.1 CentOS
Offline
I have the same problem with version 9.1. Several times a day cron mailgate crashes in running status. Has anyone had this same problem? I don't know what it can be.
Offline
I have the same problem with version 9.1. Several times a day cron mailgate crashes in running status. Has anyone had this same problem? I don't know what it can be.
Hello, I have the same issue, the mailgate and the queuednotifications are in "running" state.
It's a dockerized GLPI 9.4.4
I checked the content of /etc/cron.d/glpi and the "cron" was launched twice, at the same time.
Since I removed one of them, it seems I don't have any error anymore (and no "can't get db lock" anymore)
I'm not sure it's the solution, but that could be logical, in my point of view : 2 identical jobs are in conflict and one of them can't terminate, leaving the status in "running" state.
Regards,
Philippe
Offline
Pages: 1