[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: (deb-cat) Frenar bitacoles del sistema

__________
I'm using this dedicated address because personal addresses aren't masked enough at this mail public archive. Public archive administrator should fix this against automated addresses collectors. 
El 8/4/22 a les 15:30, Eloi ha escrit:

El 8/4/22 a les 15:22, Narcis Garcia ha escrit:

El 8/4/22 a les 15:13, Eloi ha escrit:

El 8/4/22 a les 14:42, Narcis Garcia ha escrit:

Hola bones,
En un ordinador, sota algunes circumstàncies que encara no tinc ben delimitades, però que semblen tenir a veure amb una aplicació d'escriptori, hi ha moments en què els fitxers: 
/var/log/messages
/var/log/syslog
/var/log/user.log
creixen de manera desbordant fins que el disc s'emplena completament i després no hi ha manera ni d'arrencar.
He provat a configurar la limitació de fitxers a 20M i rotació horària a: 
/etc/logrotate.d/rsyslog
i també fer una crida al logrotate amb /etc/cron.hourly/logrotate
però no és suficient, perquè quan les bitàcoles creixen ho fan més ràpid que no pas el temps de reacció.
Algú sap com limitar de forma eficaç el volum d'aquests fitxers de registre o, com a últim recurs, que no es generin? 

Gràcies.
Sense entrar a valorar la causa de l'emplenament exagerat dels fitxers de registre d'activitat (si ho consideres convenient, podries enviar-ne una petita mostra per si et podem orientar millor), la idea salomònica de neutralitzar-los seria recreant-los com enllaços simbòlics a /dev/null
Personalment no m'agrada gens la idea de perdre tot registre d'activitat pel risc que suposa emmascarar errors o il·lícits, així que prioritzaria per sobre de tot trobar-ne la causa arrel. Així a cegues, per les bitàcoles afectades diria que hi ha algun procés que està intentant canviar de permisos o privilegis d'usuari contínuament, probablement sense èxit.
Tens raó, i porto més d'un mes donant voltes a això. El problema és que els missatges enregistrats no parlen de cap problema, sinó que sembla la reiteració dels mateixos missatges de Xorg mil vegades, i altre programari del sistema. Com que no he pogut aïllar l'aplicació i quan és que fa aquest efecte, tampoc no he pogut analitzar bé les bitàcoles, i quan el problema ha ocorregut la prioritat era esborrar-les per a permetre l'arrencada. 

Provaré això del /dev/null si és l'únic fre a les inundacions de text.

Gràcies.
Una alternativa menys traumàtica, però que tampoc és solució, seria muntar /var/log a un sistema de fitxers diferenciat, preferentment no compartit (evitant un bind contra una altra partició, traslladant el problema). Si no disposes d'espai per reparticionar, sempre pots crear un fitxer contenidor en una partició ja existent i muntar-la.
Pot tenir problemes de rendiment (especialment si el fitxer és sparse o està fragmentat) i igualment un cop emplenada la partició suposarà la pèrdua de registres, però pot servir per contenir el problema temporalment.
Parlant de registres, un problema que ja m'he trobat és el de ~/.xsession-errors, que aquest per defecte no està sota la mira del logrotate i té tendència a créixer desmesuradament amb el temps.
Solució interessant (veig millor la partició ordinària), tot i que implica que, en emplenar-se, totes les bitàcoles deixarien d'enregistrar res. He pensat ara en no muntar tot el directori /var/log sinó un directori sense cap relació, i aleshores enllaçar-hi només les 3 bitàcoles problemàtiques: 
ln -s /mnt/runa/log/messages /var/log/messages
ln -s /mnt/runalog/syslog /var/log/syslog
ln -s /mnt/runa/log/user.log /var/log/user.log

i buidar els fitxers de la partició a cada arrencada del sistema.
Del què necessito estar segur és que els enllaços no seran reemplaçats per rsyslog ni per logrotate amb les seves operacions. 

Salut.
Reply to: