Probablemente, en alguna ocasión te hayas enfrentado vía log o vía mensaje de urgencia con un mensaje de este tipo: “table marked as crashed and should be repaired” cuando trabajas con MySQL. Más aún si has tenido un reinicio de emergencia, si usas MyISAM o si tienes problema con tu sistema de ficheros (o tus discos).
Puedes tratar de reparar tabla a tabla, sin embargo, lo más productivo es hacer todas de una vez. Antes de cualquier operación de este tipo, haz una copia de todo por si acaso (aquí en Linux Hispano hablé de cómo hacer backups y recuperarlos).
La orden a ejecutar será la siguiente y el resultado lo veréis en la consola, si OK o si hay problemas:
mysqlcheck -u root -p --auto-repair --optimize --all-databases
timthumb es un pequeño script PHP que nos permite de forma simple mediante parámetros GET, redimensionar, recortar o hacer zoom sobre imágenes. Por esta utilidad, ha sido usado ampliamente en temas WordPress y en otros muchos sitios. Aunque tiene cierta fama por su seguridad (por sus fallos, a priori todos ya resueltos), su uso conlleva alguna problemática de vez en cuando.
Uno de los errores que pueden aparecernos es el que ilustra el título de esta entrada: “Could not create the index.html file” y que puede aparecer sólo o en compañía de otros errores típicos que en otra ocasión trataremos.
Uno de los mayores problemas de usar WordPress, es que a pesar de ser un sistema bastante ligero, llega un momento en el que como no tengamos cuidado, puede llegar a ocupar muchos recursos. De cómo aligerar WordPress, he hablado y hablaré (de forma presencial por cierto en la próxima WordPress Meetup Córdoba que es ya mismo) pero esta no es la idea de esta entrada.
La idea de esta entrada es: no puedo aligerar WordPress por cualquier razón (no hay más que aligerar, falta de tiempo…) y el espacio que direcciona de memoria RAM se ha agotado. El indicativo de este problema es un mensaje que dice lo siguiente:
Fatal error: Allowed memory size of N bytes exhausted en PHP
La solución, intentar ampliar la memoria que tenemos disponible para PHP y por lo tanto para WordPress. ¿Cómo? Iremos intentando cada una de estas acciones.
Dentro de php.ini
Si tienes acceso al php.ini global o en su defecto, tienes un php.ini disponible en tu cuenta compartida, busca la línea:
memory_limit = 32M;
Y sustitúyela por esta otra:
memory_limit = 64M;
Es uno de los fallos más frecuentes por despiste o por novato cuando estamos manejando el sistema de paquetes apt en Ubuntu, Debian o derivadas. Intentamos hacer algo así para instalar un paquete (he puesto libpng-dev como ejemplo):
apt-get install libpng-dev
Y aparece este error:
E: No se pudo abrir el fichero de bloqueo «/var/lib/dpkg/lock» - open (13: Permiso denegado) E: No se encontró un archivo de réplica «/var/lib/dpkg/»
¿Cuál es el problema? No tenemos permisos suficientes, por lo que sólo deberemos hacer lo siguiente para solucionarlo:
A raíz de un problema en la consistencia del sistema de ficheros de un servidor virtual que ejecuta PostgreSQL, he tenido que ejecutar un fsck. Tras recuperar la consistencia todos los servicios han salido andando sin problema menos el de PostgreSQL.
Intentaba arrancarlo con:
service postgresql start
Y nada de nada, siempre aparecía el mensaje de “FALLÓ”. Me dirigí a los logs de arranque en mi caso se encuentran en: /var/lib/pgsql dentro del fichero pgstartup.log. Tras hacerle un tail compruebo que aparece el siguiente error en el arranque:
Cuando programamos en PHP existe una serie de errores y warnings que son muy típicos y que para el programador más novel pueden suponer un problema. Aquí recopilamos algunos de los más típicos, pero ya que estamos, me gustaría que todos nos contarais errores y soluciones a los mismos que encontráis a menudo.
Warning: Cannot modify header information – headers already sent by
Que también podemos encontrar como “Warning: session_start(): Cannot send session cache limiter – headers already sent” o “Warning: session_start() [function.session-start]: Cannot send session cookie – headers already sent by“. Se produce cuando intentamos modificar las cabeceras del paquete HTTP, cuando ya hemos dejado de emitirlas y estamos emitiendo el cuerpo del paquete.
¿Por qué ocurre esto? Podéis verlo dentro del protocolo. Para solucionarlo deberemos ser muy cuidadosos en dos aspectos:
¿Alguien me lo puede explicar? Esta mañana entrando en la Ubuntu Store me he dado cuenta de que el teclado de la marca, recientemente publicado, incluye la tecla de Windows.
Muchos os preguntaréis que la tecla de Windows o Super es necesaria o que no estaría bien eliminarla, pero esa no es la cuestión, soy poseedor de un netbook, un Asus Eee 901, y este sí incluye la tecla Super pero sin el logo de Windows (este laptop viene sin Windows preinstalado). Lo que me sorprende es que una marca como Ubuntu incluya un logo tan despreciable en un producto que vende en su tienda.
En ocasiones por comodidad, y sobre todo para ahorrarnos dar más información de la cuenta de cara a la seguridad y a que aparezcan mensajes de errores en la pantalla del cliente, es preferible ocultar la información de depuración que nos devuelve el intérprete PHP mediante las típicas líneas de error y warning.
La forma más cómoda para hacerlo instrucción a instrucción es el uso del prefijo @ delante de la misma. El error o warning seguirá existiendo pero no se generará una salida HTML describiéndola.
