Cron dejo de funcionar. "Attempting to re-run cron while it is already running." y "Cron has been running for more than an hour and is most likely stuck."

Submitted by danielcala on Mar, 2009-10-20 23:27

En este momento, tengo una pagina de noticias en producción con una instalacion de Acquia Drupal (6.13), Panels 2, Views, search, simplenews, entre otros. PHP 5.2.6, MySQL 5.0. y un servidor creo que lo suficientemente potente con 2 GB de ram.

Desde hace 6 meses no he tenido ningún problema grave hasta el momento. Pero la semana pasada, por algún motivo, el cron dejo de funcionar.

En este momento los reportes que me salen son dos: una alerta con el mensaje "Attempting to re-run cron while it is already running." y un error con el mensaje "Cron has been running for more than an hour and is most likely stuck.".

He tratado toda clase de alternativas encontradas en los foros tales como: borrar los caches, borrar las entradas en la base de datos "cron_sempaphore" y "cron_last" de la tabla variables, he reiniciado el apache (httpd), el cron (crond), el servidor. He cambiado la frecuencia del cron a que se ejecute cada hora, cada dos horas, tratando de darle más tiempo al cron para que termine, tratado de cambiar lo que indexa el cron por ejecución. Lo he tratado de ejecutar manualmente. y nada!!!

Mi sentido común aunque me puedo equivocar, me dice, que el problema no esta en el servidor, ya que el servidor con el servicion crond esta tratando de ejecutar de acuerdo a la frecuencia que le configuro, en este momento, lo tengo configurado de la siguiente forma:

01 */2 * * * wget -O - -q -t 1 http://www.misitio.com/cron.php

Y el Drupal registrar el intento de ejecución del cron no exitosa.

En este momento, estoy intentando una opción que no domino muy bien y no se si voy por buen camino, y eso es lo que me gustaría saber si alguien me puede ayudar; tratar de debuggear la ejecución del cron y encontrar donde se bloquea.

En el archivo includes/module.inc en el la función module_invoke_all(), despues del foreach estoy haciendo echo $function . " -- \n"; y al intentar ejecutar el cron, me salen algunos módulos, con función:

Estos modulos son los siguientes:

admin_menu_init -- content_init -- filefield_init -- googleanalytics_init -- imagefield_init -- lightbox2_init -- tagadelic_init -- aggregator_init -- blogapi_init -- book_init -- dblog_init -- node_init -- poll_init -- system_init -- user_init -- advanced_profile_init -- apture_init -- fckeditor_init -- globalredirect_init -- invite_init -- logintoboggan_init -- nodewords_init -- pollfield_init -- simplenews_init -- forum_init -- forum_access_init -- fieldgroup_init -- panels_init -- rules_init --

Si alguien sabe cuál es el siguiente paso, o un paso diferente pero seguro.

Les adjunto una imagen que muestra la ultima ejecución correcta del cron el 14 de octubre y lo que siguió después.

Adjunto	Tamaño
cron_last.jpg	126.43 KB

Grupos:

Argentina · Colombia · Spanish · Peru

Hay que remover un semáforo

victorkane - Mié, 2009-10-21 08:40

Es muy posible que tu situación sea la que describe Nancy en este hilo de conversación aquí: http://drupal.org/node/143519#comment-244463

"You need to delete the variable 'cron_semaphore' from your variables table. You can do this with phpMyAdmin, the Devel module, or the Site Documentation module."

O sea, borrar la variable 'cron_semaphore', yo diría instalando el módulo devel y haciendo uso de su editor de variables.

Cuando corre cron, coloca una variable para que no empiece de vuelta hasta que termine, cuando normalmente lo borra. Puede ser que hubo un problemilla y no lo borró. Con un poco de suerte borrando la variable solucionará el problema.

Nancy dice que la culpa podría tener el módulo update_status (en Drupal 5), pero no estoy de acuerdo que no hay que usar ese módulo, todo lo contrario.

De todos modos, estudiá esa página, seguramente te apuntará hacia una solución.

Victor Kane
http://awebfactory.com.ar
http://projectflowandtracker.com

http://awebfactory.com.ar
http://projectflowandtracker.com

Solución de eliminar semaforo no funciona para mi caso

danielcala - Mié, 2009-10-21 15:41

victorkane muchas gracias por el interés.

La solución de borrar la variable "cron_semaphore" ya la intenté, pero sigue sin funcionar el cron.

Empiezo a pensar que tiene que ver con algo relacionado con la base de datos MySQL. Al tratar de ejecutar el cron de forma manual, se imprimen una gran cantidad de log de MySQL empezando por los siguientes tres:

Warning: MySQL server has gone away query: INSERT INTO watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (1, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user warning\";s:8:\"%message\";s:517855:\"MySQL server has gone away\nquery: UPDATE cache_update SET data = &#039;a:63:{s:3:\&quot;acl\&quot;;a:10:{s:5:\&quot;title\&quot;;s:3:\&quot;ACL\&quot;;s:10:\&quot;short_name\&quot;;s:3:\&quot;acl\&quot;;s:10:\&quot;dc:creator\&quot;;s:6:\&quot;salvis\&quot;;s:11:\&quot;api_version\&quot;;s:3:\&quot;6.x\&quot;;s:17:\&quot;recommended_major\&quot;;s:1:\&quot;1\&quot;;s:16:\&quot;supported_majors\&quot;;s:1:\&quot;1\&quot;;s:13:\&quot;default_major\&quot;;s:1:\&quot;1\&quot;;s:14:\&quot;project_status\&quot;;s:9:\&a in /home/sitio/public_html/includes/database.mysqli.inc on line 128

Warning: MySQL server has gone away query: INSERT INTO watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (1, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user warning\";s:8:\"%message\";s:174:\"MySQL server has gone away\nquery: SELECT dst FROM url_alias WHERE src = &#039;admin/reports/updates&#039; AND language IN(&#039;es&#039;, &#039;&#039;) ORDER BY language DESC\";s:5:\"%file\";s:41:\"/home/sitio/public_html/includes/path.inc\";s:5:\"%line\";i:69;}', 3, '', 'http://www.misitio.com/admin/reports/status/run-cron', 'http://www.misitio.com/admin/reports/dblog', '201.232.127.28', 1256138468) in /home/sitio/public_html/includes/database.mysqli.inc on line 128

Warning: MySQL server has gone away query: INSERT INTO watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (1, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user warning\";s:8:\"%message\";s:548:\"MySQL server has gone away\nquery: INSERT INTO watchdog\n (uid, type, message, variables, severity, link, location, referer, hostname, timestamp)\n VALUES\n (1, &#039;update&#039;, &#039;Attempted to fetch information about all available new releases and updates.&#039;, &#039;a:0:{}&#039;, 5, &#039;&lt;a href=\&quot;/admin/reports/updates\&quot;&gt;ver&lt;/a&gt;&#039;, &#039;http://www.misitio.com/admin/reports/status/run-cron&#039;, &#039;http://www.misitio.com/admin/reports/dblog&#039;, &#039;201.232.127.28&#039;, 1256138468)\";s:5:\"%file\";s:50:\"/home/lsv in /home/sitio/public_html/includes/database.mysqli.inc on line 128

Alguien sabe que me dice esto, con claridad?

Ese es otro problema ....

patricio.keilty - Mié, 2009-10-21 16:23

me ha pasado alguna vez que las queries muy largas tiran abajo la conexión del MySQL : la solución que me funcionó a mi es incrementar la variable max_allowed_packet del MySQL:

max_allowed_packet = 16M

Algunas referencias que te pueden servir:

MySQL troubleshoot
DrupalCoder - MySQL server has gone away
DO - MySQL has gone away

en algunos casos, si no tenés control de esta variable de MySQL puede ser conveniente desactivar algunos módulos..... como decía Victor suelen hecharle la culpa al Update module, creo que son varios los módulos que generan queries muy extensas (entre ellos el Update), alguien tiene una estadística al respecto?.

MySQL server has gone away

jonhattan - Mié, 2009-10-21 16:33

http://dev.mysql.com/doc/refman/5.0/en/gone-away.html

http://drupal.org/node/259580

Problema resuelto

danielcala - Mié, 2009-10-21 17:28

Mi problema con el cron fue resuelto de la siguiente manera:

Cambiando el valor

max_allowed_packet = 16M

max_allowed_packet = 32M

Al parecer es muy importante seguir las recomendaciones que dan en este link:

http://drupal.org/node/259580

Saludos

Que buen intercambio sobre el tema

victorkane - Mié, 2009-10-21 19:53

Excelente Patricio!

Me alegro que esté resuelto el problema!

Saludos a todos,

Victor

http://awebfactory.com.ar
http://projectflowandtracker.com

Buenas, Respecto al tunning

drupdruppalpal - Mié, 2009-11-04 11:11

Buenas,
Respecto al tunning del mysql, esta claro que es necesario, y no quiero ser pesimista, pero yo también lo resloví aumentando el max_allowed_packet y me ha estado funcionando, y con el tiempo el problema ha vuelto. Me salen los warnings del server has gone away y creo que los parametros del MySQL están bien.
lo único que no he hecho es cambiar a innodb:

INNODB SPECIFIC:

innodb_buffer_pool_size = 384M
innodb_additional_mem_pool_size = 20M
innodb_log_file_size = 10M
innodb_log_buffer_size = 64M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 180

por que me parecía más engorroso y por lo que se innodb tambien tiene sus inconvenientes. ¿alguien sabe si cambiar las tablas a innodb mejora realmente el rendimiento?

Gracias. Un saludo!

Groups.drupal.org is a part of the drupal.org group of sites. Logging in on this site requires an account on the main drupal.org site. If you do not have an account on drupal.org, you will need to create one, log in over there, and then come back here where you should automatically be logged in.

Thanks!