Esto me ha sucedido un par de veces, hoy me llamó un cliente al que le damos soporte al servidor, que el server cuando arrancó luego de un apagón, no le funcionaba adecuadamente, no le navegaban las máquinas de su red.

Entré al server, y en efecto el squid estaba caído! Le intenté levantar y nada, daba un error así como pude observar en /var/log/squid/cache.log

2012/11/26 08:01:21| WARNING: Could not write pid file
2012/11/26 08:01:21| Squid plugin modules loaded: 0
2012/11/26 08:01:21| Adaptation support is off.
2012/11/26 08:01:21| Ready to serve requests.
FATAL: Received Segment Violation…dying.
2012/11/26 08:01:21| storeDirWriteCleanLogs: Starting…
2012/11/26 08:01:21|   Finished.  Wrote 0 entries.
2012/11/26 08:01:21|   Took 0.00 seconds (  0.00 entries/sec).
CPU Usage: 0.029 seconds = 0.022 user + 0.007 sys
Maximum Resident Size: 41744 KB
Page faults with physical i/o: 0
Memory usage for squid via mallinfo():
total space in arena:    3460 KB
Ordinary blocks:         3378 KB      5 blks
Small blocks:               0 KB      0 blks
Holding blocks:          1096 KB      4 blks
Free Small blocks:          0 KB
Free Ordinary blocks:      81 KB
Total in use:            4474 KB 129%
Total free:                81 KB 2%

Lo que me llamó la atención es que decía que no podía escribir squid.pid. Miré el espacio libre en /var y resultaba que sí había espacio! mira:

df -h
S.ficheros            Size  Used Avail Use% Montado en
/dev/sda2             4,9G  1,2G  3,4G  27% /
tmpfs                 7,8G     0  7,8G   0% /dev/shm
/dev/sda1             194M  106M   78M  58% /boot
/dev/sda5            1008M   34M  924M   4% /tmp
/dev/sda6              38G   26G  9,5G  74% /var

Bueno, tiene un 74% de uso, no es el 100% aunque es medio alto no.

Me la olí, es un tema de inodos, se agotaron los inodos, porque cuando se acaban los inodos (cada filesystem tiene un número finito de inodos) puede suceder esto, ejecuté df -i para ver inodos libres y en efecto:

df -i
S.ficheros            Inodes   IUsed   IFree IUse% Montado en
/dev/sda2             320000   57751  262249   19% /
tmpfs                2041813       1 2041812    1% /dev/shm
/dev/sda1              51200      56   51144    1% /boot
/dev/sda5              65536      17   65519    1% /tmp
/dev/sda6            2485504 2485504       0  100% /var

Ahí está! 100% de uso de inodos. Por cada archivo que se escribe, se gasta al menos un inodo, el sistema a la hora de instalarse calcula más o menos cuánto espacio hay en la partición y divide este espacio por, digamos: 4k, de forma tal que estima que se escribirán como promedio archivos de 4k. Lógicamente muchos de los archivos que se escriben son mayores a 4k, por lo tanto normalmente los inodos bastan.

En este caso es porque el usuario tiene sarg instalado, sarg es un sistema de análisis de logs de squid que escribe diariamente, semanalmente, mensualmente su resultado del análisis, y son miles de archivitos pequeños, que no llegan a 4k, y esto es lo que hace que se agoten primero los inodos antes que el espacio

Si te fijas, un supuesto problema resultó no serlo. El usuario pensaba era porque se fue la luz. Yo ví que el squid no arrancaba y asumí primero un problema de permisos (puede suceder a veces) pero a la final resultó ser algo totalmente inesperado. Debe planificarse una tarea programada cada cierto tiempo para borrar los logs del sarg más viejos para evitar que esto ocurra.