Last week I’ve been debugging a problem I had with this site’s nginx server: from time to time it hanged and I had to restart the process. Some time ago I wrote a little script that checked if it was running OK and restarted it otherwise, but anyway that wasn’t a real solution.

So I spent some days really looking into it and asking for support and reporting my findings to the nginx mailing list. One useful tip I got there was enabling the “debug” mode on the error log, which shows full traces of the processes (including their PID) as they’re processing the request, the rewrites, upstreams, etc.

With this extended log and the PID of the process malfunctioning, it’s quite easy finding out what that process was doing right before hanging. In order to find out the PID of the hanged processes, I extended my check-reboot script to log some generic system metrics right before restarting nginx: netstat -nap (which shows the PID), ps, vmstat, etc.

#!/bin/sh

TIMEOUT=20
CHECK=http://localhost/wp-admin/
LOG=/var/log/checkWeb/checkWeb-$(date +%Y%m%d).log
LOGR=/var/log/checkWeb/restart-$(date +%Y%m%d).log
TMP=/tmp/checkWeb-$RANDOM

if ! wget -t 1 -o /dev/null -O /dev/nul -T $TIMEOUT $CHECK
then
echo "ERROR, restarting nginx"
echo "** RESTARTING **" >> $TMP
date >> $TMP
echo "- CLOSE_WAIT:" >> $TMP
netstat -nap | grep -c CLOSE_WAIT >> $TMP
echo "- vmstat" >> $TMP
vmstat 1 5 >> $TMP
echo "- free" >> $TMP
free >> $TMP
echo "- ps" >> $TMP
ps aux >> $TMP
echo "- netstat" >> $TMP
netstat -nap >> $TMP
echo "" >> $TMP
echo "" >> $TMP

#       pkill -9 -f php-cgi
pkill -9 -f nginx
sleep 1s
/etc/init.d/nginx start

cat $TMP
cat $TMP >> $LOG
date >> $LOGR
fi

rm -rf $TMP

This way, each time localhost/wp-admin was unresponsive (I was debugging a WP site), besides restarting nginx I was getting a lot of system info. With time I got to realize that nginx processes were not actually hanging, but some of their sockets got on the CLOSE_WAIT state forever until the process was restarted. Looking for the PID of those processes according to netstat on the error log, the last request they were processing before getting to the CLOSE_WAIT state was always the same: on my blog I have some examples of how running servers with daemontools; daemontools uses named pipes (FIFOs), which can become kind of black holes if there’s no process feeding them; when nginx hit one of these FIFOs, it hanged.

Funny thing is that I never had this problem with either Apache nor lighttpd. But anyway the problem is not nginx but those FIFOs which shouldn’t really be there. I removed them and have had no hanged processes in five days, while before this nginx was restarting 3-4 times a day.

Como aparte de configurar el servidor y el PHP con fast-cgi hay que convertir todos los rewrites del Apache (wpmu y super-cache) al formato de nginx, es posible que el blog haga cosas raras, no se actualice debidamente, algunas páginas no vayan bien, pete, no acepte comentarios, o cobre consciencia de sí mismo y decida matar a todos los humanos. YMMV.

Además he aprovechado para instalar algún plugin nuevo, porque llevo unos días jugando con Twitter (aún no me había subido a ese carro):

• Twitme: genera un post en Twitter cada vez que se publica algo en el blog.
• Twitter for WordPress: añade un widget con los últimos posts en Twitter.
• LifeStream: genera una página en la que puedes agregar información de varios sitios, entre otros last.fm, facebook, picassa, flickr, google reader… es decir, agrega toda tu actividad on-line en un único sitio. Más o menos lo que comenté que venía haciendo yo con facebook, pero ahora en el blog.

UPDATE: he desactivado Twitme, no me ha acabado de gustar. Una cosa es el blog y otra twitter, y aparte teniéndolo todo integrado (twitter en el blog, y el blog y twitter en facebook) era muy redundante.

El problema era cómo integrar los posts del blog en Facebook. Durante un tiempo usé la aplicación de Facebook Simplaris Blogcast, pero tenía dos problemas:

• no sé por qué no trataba bien acentos, eñes, etc. que salían como símbolos raros. Algún problema de encodings entre la aplicación y el blog.
• tiene un nº límite de artículos, y cuando los llenas tienes que borrar alguno a mano. Quería algo completamente automático y ésta limitación me obligaba a hacer limpieza periódicamente.

Otra cosa que probé es con la utilidad de importación de RSS nativa de Facebook: los artículos se importan como notas, y eso no me gustaba por dos razones:

• contenido duplicado en el blog y en Facebook. En Facebook quiero una reseña que apunte al blog.
• comentarios también duplicados. En realidad, dos sitios independientes donde comentar: en las notas de Facebook y en el blog.

Hay otras aplicaciones tipo Simplaris, pero todas tenían distintas combinaciones de los problemas que encontré con estas dos que he comentado.

La semana pasada estuve un rato peleándome con Wordbook hasta que lo hice funcionar. Wordbook se diferencia de las otras dos alternativas en que, en lugar de ser simplemente una aplicación en Facebook que lee el RSS del blog periódicamente (con lo que la publicación no es inmediata), tiene una parte de aplicación en Facebook y un plugin para WordPress, de forma que en el momento que publicas un artículo en el blog, el plugin se conecta a la aplicación y se publica inmediatamente en Facebook. Además hace justo lo que quería: una reseña en el muro y una caja con la lista de los últimos artículos, en ambos casos con enlaces al blog con lo que ni el contenido ni los comentarios “se desperdigan” entre dos sitios.

El único problema es que no me acababa de funcionar: no publicaba y la configuración se reseteaba tras cada publicación, algo que también le pasaba a más gente. Investigando vi que era porque la comunicación plugin->app es a traves de JSON y no se “sanitizan” las cadenas eliminando saltos de línea. La solución fue tan sencilla como modificar las líneas 1127 y 1128 de wordbook.php (en el plugin para WordPress) para eliminar los saltos de línea con la función nl2br:

Aparte, también he instalado el plugin Facebook Connector, que lo que hace es habilitar una especie de “single sign-on” basado en Facebook: integra tu cuenta de Facebook en el blog para que no tengas que logarte en un sitio u otro a la hora de hacer comentarios. La verdad para un blog personal como el mío me parece una chorrada pero total, para lo que me cuesta… para una página en plan comunidad puede estar muy bien.

Las week the final version of WordPress MU 2.6 was released. I’ve made two diff files this time, one for upgrading from the previous stable release (1.5.1) and one from the RC1:

• wpmu-1.5.1-2.6.diff
• wpmu-2.6rc1-2.6.diff

After yesterday’s upgrade to 1.5.1 I’ve just realized that there had been released a 2.6 RC already, allowing among other things to access both the blog and specially the admin area over HTTPS.

So, the obligatory upgrade patch: wpmu-1_5_1-2_6rc1.diff

I’ve just upgraded the blog to WordPress MU 1.5.1. For a couple of days some features may not work as expected, due to plugin incompatibilities, new options, etc.

I’ve made a .diff patch file to make the upgrade process from the release I was using before (1.3.3) a little bit easier. It’s available here in case anyone finds it useful. If you may find any problems after the upgrade, be sure to disable and remove all plugins, specially from the mu-plugins folder, and proceed to install them one by one.

One thing I always missed in WordPress is the ability to select the size of the thumbnail that’s generated every time you upload a picture to your blog. The default size is quite small, sometimes you may want it, for example, to be as wide as the page, without needing to scale the original pic down in HTML with width=”xx”.

I’ve found today the imagesControlSize plugin by aNieto2k, that allows you to select the thumbnail’s width when uploading an image (the height is calculated automatically, maintaining the aspect ratio). Works great.

WordPress MU 1.3.3 has been released today (announce, download). It includes a series of important security fixes and gets the code in sync with WordPress 2.3.3.

Once again, I’ve prepared a .diff file for an easier upgrade procedure from the previous version:

•  wpmu-1_3_2-1_3_3.diff

WordPress MU 1.3.2 has been released. It gets the project in sync with WordPress 2.3.2 and besides that adds several WPMU-specific security fixes, so it’s a must.

The full package is available for download here. If you already have the previous release installed (simply 1.3, but it was in sync with WP 2.3.1) you can use the following patch to upgrade it more easily: wpmu-1_3-1_3_2.diff