Escribiré este post en dos idiomas para que realmente pueda ayudar. (English below)
Actualmente estoy trabajando con la migración de un sitio choncho de un VPS a otro. Este sitio requiere dos extensiones de PHP adicionales, Memcache y APC.
Todo iba funcionando perfectamente hasta que instalé APC. Al intentar ver un archivo en PHP, este se abria correctamente una sola vez, al segundo intento no me devolvia nada. Exploré el archivo de errores de Apache para encontrarme que un proceso hijo había terminado por una falta de segmento. Imediatamente supe que era por APC.
Despues de bajar y recompilar casi 15 versiones de APC sin exito y cambiar todas las opciones de APC, tambien sin exito, me puse a indagar en internet durante mucho tiempo, sin ninguna ayuda, hasta que por error di con un post del ZEND Optimizer que no tenia nada que ver y eso me dio una idea: Deshabilitar ZEND.
Problema:
Apache envia error SEG FAULT (11) al ejecutar scripts de PHP con APC
Escenario:
PHP 5.2.10, Apache 2.2.11, WHM/cPanel, CentOS 5.3, APC 3.0.19, Memcache 1.1, ZEND 3.3.3
Solución:
Deshabilitar Zend Optimizer en php.ini
---------------------------------------------
English:
Right now I'm migrating a very huge site from a VPS to another. This site requires two additional PHP extensions to work as expected: APC & Memcache.
Everything was going just as expected until i compiled and installed APC. When trying to run a PHP script, it was shown correctly only once; for the second try it just showed a blank screen. Immediatly I gave a look into the Apache's error log file to see what the problem was; at the last line, it read something about a Seg(ment) fault (11), for sure i knew it was because of APC.
After downloading and recompiling 15 (yes, 15!!) APC versions and changing every APC runtime option without succes, i googled for help... after about an hour of browsing lots of sites without any hint that may get me out of the problem, i found (by mistake) a post about ZEND optimizer that had nothing to do with the APC issue, but that give me an idea... it could be because of ZEND!
Problem:
Apache crashes a child process with SEG FAULT (11) when running a PHP script with APC.
Scenario:
PHP 5.2.10, Apache 2.2.11, WHM/cPanel, CentOS 5.3, APC 3.0.19, Memcache 1.1, ZEND 3.3.3
Solution:
Disable ZEND Optimizer extensions in php.ini
Saturday, December 19, 2009
Tuesday, October 20, 2009
MSI Wind U100 con Windows 7
Pues bueno... esto en realidad ya tiene tiempo que lo hice pero no habia podido postear. Recientemente me adquirí una netbook MSI Wind U-100. Esta lap se la había recomendado a la hermanita de mi mejor amigo a principios de año desde que vi que era MSI.
Ahora, a ella ya no le gustó por que dice que es muy pequeña, mientras yo justamente estaba buscando una lap pequeña y sencilla ya que para lo único para lo que la necesito es para mostrar trabajos a mis clientes y navegar un rato en Internet para perder el tiempo.
Este post no será muy largo. Simplemente para hacer notar las siguientes cosas de la lap, y de la lap con Windows 7 Ultimate:
Mis comentarios: Excelente lap. MSI es sinonimo de calidad y en este caso no es la excepción, aunque bién pudieron haber hecho que la batería durara más tiempo (dura 3 horas con XP)
MSI Wind U-100 con Windows 7:
Muuuchos problemas al instalar. Monté un DVD-RAM en un case externo para conectarselo por USB a la Wind. El instalador corrió perfecto, hasta que iniciaba la fase de "Expandir archivos". En esta fase, se trabó el instalador con un error de copia de archivos a porcentajes aleatorios.
Después de como 10 intentos, decidí copiar los archivos de instalación de Windows a una USB (en mi caso no tengo USB de 4Gb, así que use un viejo disco duro de 8Gb montado en el case usb) usando un procedimiento bastante sencillo para hacerlo booteable.
Después de esto, Windows se pudo instalar sin problemas en 20 minutos. No requirió ningún driver adicional, inclusive funciona bastante bien la interfaz Aero, aunque el consumo de batería aumentó drasticamente. Con XP la batería duraba aproximadamente 3 horas; con Seven este tiempo se redujo a 1 hora y 50 minutos.
En resumen: Dado a las altas ventajas que trae Windows 7, la movilidad de la U-100 y la facilidad de instalación, recomiendo poner Windows 7 en la U-100.
Ahora, a ella ya no le gustó por que dice que es muy pequeña, mientras yo justamente estaba buscando una lap pequeña y sencilla ya que para lo único para lo que la necesito es para mostrar trabajos a mis clientes y navegar un rato en Internet para perder el tiempo.
Este post no será muy largo. Simplemente para hacer notar las siguientes cosas de la lap, y de la lap con Windows 7 Ultimate:
- Procesador: Intel Atom N270 1.6Ghz
- RAM: DDR2 1Gb
- Disco Duro: 160Gb
- Wifi: b/g/n
- Bluetooth: No
- Pantalla: 10", Iluminación de led, 1024x600 pixeles
- Microfono y Cámara web
- SO instalado: Windows XP Home
Mis comentarios: Excelente lap. MSI es sinonimo de calidad y en este caso no es la excepción, aunque bién pudieron haber hecho que la batería durara más tiempo (dura 3 horas con XP)
MSI Wind U-100 con Windows 7:
Muuuchos problemas al instalar. Monté un DVD-RAM en un case externo para conectarselo por USB a la Wind. El instalador corrió perfecto, hasta que iniciaba la fase de "Expandir archivos". En esta fase, se trabó el instalador con un error de copia de archivos a porcentajes aleatorios.
Después de como 10 intentos, decidí copiar los archivos de instalación de Windows a una USB (en mi caso no tengo USB de 4Gb, así que use un viejo disco duro de 8Gb montado en el case usb) usando un procedimiento bastante sencillo para hacerlo booteable.
Después de esto, Windows se pudo instalar sin problemas en 20 minutos. No requirió ningún driver adicional, inclusive funciona bastante bien la interfaz Aero, aunque el consumo de batería aumentó drasticamente. Con XP la batería duraba aproximadamente 3 horas; con Seven este tiempo se redujo a 1 hora y 50 minutos.
En resumen: Dado a las altas ventajas que trae Windows 7, la movilidad de la U-100 y la facilidad de instalación, recomiendo poner Windows 7 en la U-100.
Friday, August 28, 2009
El correo se envia muy rapido y luego sale error (Windows 7, Outpost)
Bueno, el titulo no lo explica mucho pero aqui va:
Estaba yo feliz diseñando una lona para un cliente y al terminarla, se la envie por correo. Era un archivo adjunto en ZIP de mas o menos 6mb. A mi desgraciadamente Infinitum no me ha subido la velocidad, asi que sigo con mis fabulosos 128kbps de subida. Obviamente con esta velocidad, 6MB se tardan bastante en enviarse. Inesperadamente, la barrita de progreso se fue al 100% como en 5 segundos (demasiado rapido).. claro, era algo IMPOSIBLE.
Yo uso el Agnitum Outpost Firewall Pro 6.7.2957.446.0711, (el mejor firewall para mi) y estoy corriendo la RTM de Windows 7. Abri el Outpost para ver que sucedia con la conexion de mi fabulosisimo FoxMail, un cliente de correo chino (no me gustan las cosas chinas, pero en este se la rifaron) muuuy sencillo de usar y altamente configurable.
Para mi sorpresa, en el Outpost aparecia que la conexion si estaba bien hecha a mi servidor de correo, pero los 6MB ya estaban enviados y no habia mas actividad. Gracias a la tonteria de Microsoft de quitar la animación de actividad del icono de red en el área de notificación, no podia saber si mi internet estaba enviando datos.
Obviamente, despues de un ratito el Foxmail me mando un error de tiempo de espera agotado (timeout). Como es muy configurable, le movi como solucion temporal el timeout para que si enviara el correo. Sorpresa, lo envio, pero aun asi era demasiado extraño que la barra se fuera al 100% tan rapido, que el Outpost reportara que todo habia sido enviado y que no habia actividad.
Pense primero en varias cosas: Que el windows 7 usara alguna especie de buffer para los correos, o que mi antivirus (Nod32) lo estuviera almacenando en buffer para escanearlo y enviarlo. Nada de esto fue verdad.
La solución la encontre despues de indagar como 2 horas en internet en un foro del outpost de un cuate que tenia problemas al enviar correo desde Outlook Express:
El Outpost usa un sistema "Content Handling" (Manejo de Contenido) que escanea el contenido de los paquetes TCP, es por esto que el Outpost recibia el correo primero (por eso el Foxmail se iba al 100% tan rapido), lo escaneaba y lo empezaba a enviar en el fondo (por eso el outpost reportaba que el 100% del contenido del correo estaba enviado, por que tecnicamente el cliente si lo envio, pero al outpost.
SOLUCION: Editar Archivo "machine.ini". Este archivo yo ya lo conocia y cuando me entere de que era cosa del outpost, me puse a buscarle en el pero no encontraba nada relacionado con correo o archivos adjuntos. Despues de leer el foro, vi que esto es lo que se tiene que editar:
EnableContentHandler=false
Esa directiva esta por default en true, si la ponemos en false se deshabilita el gestor de contenido. Los paquetes TCP no son escaneados y por tanto el outpost no funciona como proxy local o buffer de paquetes TCP. El archivo "machine.ini" esta en C:\Program Files\Agnitum\Outpost Firewall Pro\. Para poder editarlo hay que deshabilitar el Self Defense (Auto Protección) del Outpost.
Espero les sea de utilidad.
Estaba yo feliz diseñando una lona para un cliente y al terminarla, se la envie por correo. Era un archivo adjunto en ZIP de mas o menos 6mb. A mi desgraciadamente Infinitum no me ha subido la velocidad, asi que sigo con mis fabulosos 128kbps de subida. Obviamente con esta velocidad, 6MB se tardan bastante en enviarse. Inesperadamente, la barrita de progreso se fue al 100% como en 5 segundos (demasiado rapido).. claro, era algo IMPOSIBLE.
Yo uso el Agnitum Outpost Firewall Pro 6.7.2957.446.0711, (el mejor firewall para mi) y estoy corriendo la RTM de Windows 7. Abri el Outpost para ver que sucedia con la conexion de mi fabulosisimo FoxMail, un cliente de correo chino (no me gustan las cosas chinas, pero en este se la rifaron) muuuy sencillo de usar y altamente configurable.
Para mi sorpresa, en el Outpost aparecia que la conexion si estaba bien hecha a mi servidor de correo, pero los 6MB ya estaban enviados y no habia mas actividad. Gracias a la tonteria de Microsoft de quitar la animación de actividad del icono de red en el área de notificación, no podia saber si mi internet estaba enviando datos.
Obviamente, despues de un ratito el Foxmail me mando un error de tiempo de espera agotado (timeout). Como es muy configurable, le movi como solucion temporal el timeout para que si enviara el correo. Sorpresa, lo envio, pero aun asi era demasiado extraño que la barra se fuera al 100% tan rapido, que el Outpost reportara que todo habia sido enviado y que no habia actividad.
Pense primero en varias cosas: Que el windows 7 usara alguna especie de buffer para los correos, o que mi antivirus (Nod32) lo estuviera almacenando en buffer para escanearlo y enviarlo. Nada de esto fue verdad.
La solución la encontre despues de indagar como 2 horas en internet en un foro del outpost de un cuate que tenia problemas al enviar correo desde Outlook Express:
El Outpost usa un sistema "Content Handling" (Manejo de Contenido) que escanea el contenido de los paquetes TCP, es por esto que el Outpost recibia el correo primero (por eso el Foxmail se iba al 100% tan rapido), lo escaneaba y lo empezaba a enviar en el fondo (por eso el outpost reportaba que el 100% del contenido del correo estaba enviado, por que tecnicamente el cliente si lo envio, pero al outpost.
SOLUCION: Editar Archivo "machine.ini". Este archivo yo ya lo conocia y cuando me entere de que era cosa del outpost, me puse a buscarle en el pero no encontraba nada relacionado con correo o archivos adjuntos. Despues de leer el foro, vi que esto es lo que se tiene que editar:
EnableContentHandler=false
Esa directiva esta por default en true, si la ponemos en false se deshabilita el gestor de contenido. Los paquetes TCP no son escaneados y por tanto el outpost no funciona como proxy local o buffer de paquetes TCP. El archivo "machine.ini" esta en C:\Program Files\Agnitum\Outpost Firewall Pro\. Para poder editarlo hay que deshabilitar el Self Defense (Auto Protección) del Outpost.
Espero les sea de utilidad.
Wednesday, August 26, 2009
FireFox: Error 0x80004005 nsidomnshtmldocument WYSIWYG
Pues bueno, este post es simple. Estaba yo programando el editor WYSIGYG para uno de mis clientes, y cuando estaba probando en FireFox 3.5, me di cuenta que no siempre estaba disponible la edición en el iFrame aunque designMode estaba activado.
Después de indagar en muchos foros sin ningún resultado, me puse a echarle coco por mi mismo y encontré la respuesta: En Firefox, cuando el iFrame tiene contenido cargado desde un archivo mediante el atributo src, designMode no funciona hasta que este totalmente cargado el documento del iFrame. Es decir, si se activa el designMode pero el documento dentro del iFrame no ha terminado de cargarse, designMode no funciona.
Esto lo resolvi de la siguiente forma:
if(detectamos si es firefox){
document.getElementById('id_del_iframe').contentWindow.onload = function(){
this.document.designMode = "on";
}
} else {
//Hacemos lo necesario para IE
}
Asi de simple hacemos que el designMode se active hasta que el documento del iFrame haya sido cargado.
Después de indagar en muchos foros sin ningún resultado, me puse a echarle coco por mi mismo y encontré la respuesta: En Firefox, cuando el iFrame tiene contenido cargado desde un archivo mediante el atributo src, designMode no funciona hasta que este totalmente cargado el documento del iFrame. Es decir, si se activa el designMode pero el documento dentro del iFrame no ha terminado de cargarse, designMode no funciona.
Esto lo resolvi de la siguiente forma:
if(detectamos si es firefox){
document.getElementById('id_del_iframe').contentWindow.onload = function(){
this.document.designMode = "on";
}
} else {
//Hacemos lo necesario para IE
}
Asi de simple hacemos que el designMode se active hasta que el documento del iFrame haya sido cargado.
Subscribe to:
Posts (Atom)