Solución 1:
Esto probablemente se deba a que, aunque trunque el archivo, el proceso de escritura en el archivo continuará escribiendo en el desplazamiento final que tenía. Entonces, lo que sucede es que logrotate trunca el archivo, el tamaño es cero, el proceso vuelve a escribir en el archivo, continúa en el desplazamiento que dejó, y ahora tiene un archivo con bytes NULL hasta el punto en que lo truncó más el nuevo entradas escritas en el registro.
od -c después de truncar + crecimiento repentino, generó una salida similar a:
0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
33255657600 \0 C K B - s e r v e r [ h t t
33255657620 <more log output>
Lo que esto dice es que desde el desplazamiento 0 hasta el 33255657600, su archivo consta de bytes nulos y luego algunos datos legibles. Llegar a este estado no toma la misma cantidad de tiempo que tomaría escribir todos esos bytes nulos. Los sistemas de archivos ext{2,3,4} admiten algo llamado archivos dispersos, por lo que si busca más allá de una región de un archivo que no contiene nada, se supondrá que esa región contiene bytes nulos y no ocupará espacio. en disco Esos bytes nulos en realidad no se escribirán, solo se supone que están allí, por lo tanto, el tiempo que lleva ir de 0 a 3.5 GB no toma mucho tiempo. (Puede probar la cantidad de tiempo que lleva haciendo algo como dd if=${HOME}/.bashrc of=largefile.bin seek=3432343264 bs=1 , esto debería generar un archivo de más de 3 GB en unos pocos milisegundos).
Si ejecuta ls -ls en sus archivos de registro después de que hayan sido truncados y hayan tenido un crecimiento repentino nuevamente, ahora debería informar un número al comienzo de la línea que representa el tamaño real (en bloques ocupados en el disco), que probablemente sea un orden de magnitud más pequeño que el tamaño informado por solo ls -l .
Solución 2:
Soy extremadamente confiado en que Kjetil lo ha acertado. Drew, es posible que aún no te convenza su explicación, pero te insto a que leas atentamente lo que dijo.
Si lo acepta, la solución es detener y reiniciar su aplicación cuando se rotan los registros, o usar una herramienta como "rotatelogs" de apache, donde alimenta la salida del registro a la herramienta a través de una tubería, y la herramienta se encarga de rotando el archivo de registro de vez en cuando. Por ejemplo, una de mis instancias de apache inicia sesión con
ErrorLog "|/usr/sbin/rotatelogs /www/logs/error_log 604800"
lo que provoca una gran cantidad de archivos de registro con nombres como
-rw-r--r-- 1 root root 4078 Dec 21 01:04 error_log.1292457600
-rw-r--r-- 1 root root 4472 Dec 29 08:41 error_log.1293062400
-rw-r--r-- 1 root root 78630 Jan 4 12:57 error_log.1293667200
-rw-r--r-- 1 root root 15753 Jan 12 01:10 error_log.1294272000
para aparecer sin reiniciar apache; Luego puedo comprimirlos manualmente después del hecho. Tenga en cuenta cómo se realiza la rotación cada semana, que es cada 604800 segundos, siendo ese el argumento pasado a rotatelogs .
Si no puede detener y reiniciar la aplicación, y no puede iniciar sesión a través de una tubería, entonces creo que tiene un problema real. Quizás otros tengan sugerencias.