Archivos temporales consumen el disco (RESPONDIDO)

SIU-Diaguita Técnicos SIU-Diaguita
1

Buenas noches.

Estamos teniendo un inconveniente con Diaguita 4.1.0. Los archivos dentro de la carpeta SIU-Diaguita410/temp me ocupan todo el disco y por eso deja de funcionar todo el server.

Lo que hago cuando me reportan que el sistema no carga es limpiar esa carpeta con : sudo find /var/www/SIU-Diaguita410/temp -maxdepth 1 -type f -delete ; y ahi pasa de tener 165G a 1,6G.

Reinicio el motor de la BD y ahi sigue funcionado. Pero no se porque esta pasando esto con los temporales.

En el cron del server tengo esta sentencia, para que corra automaticamente::

0 5 * * 1 sh /var/www/SIU-Diaguita410/bin/limpiar_temporales.sh

Y el mismo llamado los 3 días de la semana que hacemos automaticamente backup de la BD::
sudo sh /var/www/SIU-Diaguita410/bin/limpiar_temporales.sh

Pero evidentemente ninguna de estas 2 ultimas ejecuciones que menciono, limpia temporales. Solo la primera que puse al comienzo.

Espero puedan orientarme.

Desde ya muchas gracias.

Saludos, y buen finde.

2

Hola Gabriel,
El comando limpiar temporales elimina archivos de los siguientes directorios:

APP_PATH/vendor/siu-toba/framework/temp/*
APP_PATH/temp/*
APP_PATH/www/temp/*
APP_PATH/vendor/siu-toba/framework/www/temp/*

A tener en cuenta que el cron debe correr con usuario del tipo root del servidor donde se aloja la aplicación.
Luego lo importante es listar el contenido de ese directorio para analizar que archivos esta generando ese uso en disco.
Saludos!!!

3

Hola Diego, si se corre como sudo y probé con root pero el temp aparentemente no borra. Lo que me llama la atención es como a pesar de que en horarios que no se esta usando en la universidad el sistema, yo vacío la carpeta y en el momento ya se empiezan a generar archivos.

La /var/www/SIU-Diaguita410/temp en 20 minutos crece 400MB, sin que nadie en. Si corro el htop aparecen los registros pid de Java relacionados con Diaguita, adjunto imagen de lo que se visualiza en pantalla, pero la lista es aun mas larga. También los recursos del server están todo el tiempo disparados, mas la memoria ram.

Ahora agregue al sh que hace el backup de la bd (que se corre 2 veces a la semana de forma automática) las siguientes 2 lineas:

sudo find /var/www/SIU-Diaguita410/temp -maxdepth 1 -type f -delete
sudo pkill -f JavaBridge.jar

Captura de pantalla_2026-03-08_16-41-05
Captura de pantalla_2026-03-08_16-41-051357×499 183 KB

Captura de pantalla_2026-03-08_16-47-46
Captura de pantalla_2026-03-08_16-47-46676×491 70 KB

4

Hola Gabriel,
¿Como te va ? Estoy observando en la primera imagen adjunta que tenes muchos procesos jasper corriendo, lo recomendable es detenerlo, podes hacerlo mediante un comando en el CLI o con el comando administrativo para los reportes:

./bin/diaguita_reportas.sh stop

Luego con respecto a esos archivos generados en el directorio temp eliminarlos y luego volver a correr el comando para iniciar el servicio de jasper en diaguita.
Saludos!!!

5

Hola Gabriel,

Respecto a lo que comentas que en horarios que no usan el sistema se generan temporales, podrías verificar el access.log para ver que tipo de peticiones están recibiendo.

Tengan en cuenta que el Portal de compras es accesible de forma pública. Han implementado un archivo robots.txt para evitar accesos de bots y scrappers?

Si no lo han implementado lo ideal es que lo implementen para evitar este tipo de peticiones. Te dejo 2 link con info acerca del robots.txt. Son varias las universidades que lo han implementado para evitar este tipo de peticiones.

Saludos

6

Hola, buen día.

Diego, Pablo.

Voy a poner entonces en mi script ./bin/diaguita_reportas.sh stop.

Lo del archivo no lo tenemos creado. Voy a revisar los link para hacerlo a la brevedad. Y ver que pasa.

Muchas gracias a ambos.

Saludos.

7

Hola Gabriel,
Gracias por la respuesta y esperemos que con lo recomendado puedas resolverlo .
Saludos!!!

8

De momento se agregó el robots.txt, pero desde nginx dado que ese es nuestro proxy reverso.

Ahora bien, dado que incluso bots “legítimos” pueden ignorarlo, y scanners maliciosos siempre lo harán se ha agregado además la opción de clasificar requests según el User-Agent y también la definición de una zona para rate limiting por IP

En nginx.conf (contexto http):

map $http_user_agent $bad_bot {
    default 0;
    ~*(GPTBot|ClaudeBot|Bytespider|CCBot) 1;
}

limit_req_zone $binary_remote_addr zone=botlimit:10m rate=5r/s;

Definimos un snippet reutilizable

/etc/nginx/snippets/protection-siu.conf

if ($bad_bot) {
return 403;
}

limit_req zone=botlimit burst=40;

Y después en cada bloque server con apps SIU

upstream backend {
   server 10.10.20.247;
   keepalive 32;
}

server {

    location / {
        include snippets/proteccion-siu.conf;
        proxy_pass http://backend;
    }

}

… seguimos