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.phpY 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.
| Attachment | Size |
|---|---|
| cron_last.jpg | 126.43 KB |
Comments
Hay que remover un semáforo
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
Victor Kane
http://awebfactory.com
Solución de eliminar semaforo no funciona para mi caso
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 = 'a:63:{s:3:\"acl\";a:10:{s:5:\"title\";s:3:\"ACL\";s:10:\"short_name\";s:3:\"acl\";s:10:\"dc:creator\";s:6:\"salvis\";s:11:\"api_version\";s:3:\"6.x\";s:17:\"recommended_major\";s:1:\"1\";s:16:\"supported_majors\";s:1:\"1\";s:13:\"default_major\";s:1:\"1\";s:14:\"project_status\";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 = 'admin/reports/updates' AND language IN('es', '') 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, 'update', 'Attempted to fetch information about all available new releases and updates.', 'a:0:{}', 5, '<a href=\"/admin/reports/updates\">ver</a>', 'http://www.misitio.com/admin/reports/status/run-cron', 'http://www.misitio.com/admin/reports/dblog', '201.232.127.28', 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 ....
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 = 16MAlgunas 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
http://dev.mysql.com/doc/refman/5.0/en/gone-away.html
http://drupal.org/node/259580
Problema resuelto
Mi problema con el cron fue resuelto de la siguiente manera:
Cambiando el valor
max_allowed_packet = 16Ma
max_allowed_packet = 32MAl parecer es muy importante seguir las recomendaciones que dan en este link:
http://drupal.org/node/259580
Saludos
Que buen intercambio sobre el tema
Excelente Patricio!
Me alegro que esté resuelto el problema!
Saludos a todos,
Victor
Victor Kane
http://awebfactory.com
Buenas, Respecto al tunning
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!
Estuve teniendo el mismo
Estuve teniendo el mismo problema, aparentemente el modulo upload toma mucho tiempo para ejecutar la rutina cuando corre cron, es más, desde hace unos meses lo tenía deshabilitado ya que me bloqueo el sitio por completo y hasta encontrar una solución preferí prescindir de este modulo aunque sé que es muy útil. Despues de leer bastante seguí los siguientes pasos:
1-Puse el sitio en mantenimiento, hice un backup de la DB y del directorio del server, deshabilité todos los módulos y puse el tema Garland
2-Actualizé el core de Drupal a la versión 6.17
3-Comencé por habilitar el módulo update, luego ejecuté cron y todo anduvo ok
4-Luego seguí habilitando todos los módulos que tenía en funcionamiento antes, pero haciendo pruebas de cron a medida que iba habilitando modulos hasta que cron falló.
5-Entonces utilicé esta solución http://acquia.com/node/367179 (en otras palabras lo que dice Victor de borrar el semaforo)
Pero fue algo que duró poco y a medida que habilitaba más módulos cron volvía a fallar
6-Luego use esto http://drupal.org/node/382682
Me permitió ver y confirmar en las "Entradas recientes del registro" que cada vez que había una falla al correr cron el módulo update no devolvía la llamada quedaba en: calling update
7-Hice pruebas deshabilitando el módulo update y cron funcionó perfectamente. Al habilitarlo falló de nuevo.
8-Solicité al server Cambiar el valor max_allowed_packet, y mientras esperaba la respuesta del ticket probé con esta solución: http://drupal.org/node/259580#comment-1511512
9-Finalmente la solucion aportada por cog.rusty me ha dado resultado.
Veremos que me dice la gente del servidor por la consulta de cambiar el max_allowed_packet
Espero poder ayudar a quien tenga el mismo problema.
Saludos
No sera un tema del servidor?
Tenes acceso por la consola al cron del servidor? Se esta ejecutando? Probaste de ver los logs del server?
My two cents,
Gustavo Orrillo
Moldeo Interactive