El 8/4/22 a les 15:37, Narcis Garcia ha escrit:
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.
Per això és millor idea la de la partició muntada ex-profeso per a
/var/log que la dels enllaços simbòlics, que de fet en el cas de rotació
(reconec que no hi havia caigut) poden invalidar igualment la solució de
/dev/null
De totes maneres, és el que deia abans, això no deixen de ser pedaços
per evitar la caiguda general del sistema per l'emplenament de la
partició arrel; el que cal és resoldre'n la causa