Rootfs plein

Bonjour,
j’ai une machine qui ne fonctionne plus correctement car rootfs en plein à 100%

C’est arrivé d’un coup, sans prévenir aprés que j’ai changé le mode d’authentification de zoneminder.
J’ai utilisé les astuces habituelles pour retrouver de la place (purger les logs, purger le cache d’apt, rechercher les gros fichiers), mais rien à faire toujours 100%.
Une idée de piste ?

Pour voir, essaye un

[quote]1 /root
384 /usr
1 /run
1 /lost+found
1 /boot
4 /etc
0 /tmp
1312 /var
0 /dev
5 /sbin
52 /lib
5 /bin
1 /opt
du: impossible d’accéder à « /proc/28150/task/28150/fd/4 »: Aucun fichier ou dossier de ce type
du: impossible d’accéder à « /proc/28150/task/28150/fdinfo/4 »: Aucun fichier ou dossier de ce type
du: impossible d’accéder à « /proc/28150/fd/4 »: Aucun fichier ou dossier de ce type
du: impossible d’accéder à « /proc/28150/fdinfo/4 »: Aucun fichier ou dossier de ce type
0 /proc
1 /mnt
1 /media
1 /srv
1 /card
1 /selinux
1 /home
0 /sys
1760 /
[/quote]
c’est bien dans var que ce trouve le probléme.
Il doit y avoir un fichier de log qui ne s’archive pas

je sont les fichiers de mail, p

[quote]mail.err mail.log
mail.err.1 mail.log.1
mail.info mail.warn
[/quote]

qui sont énorme. comment les vider ?
Je chercherai ensuite qui me les rempli


et ainsi de suite

et ainsi de suite

c’est bon, j’ai le contenu du fichier mail.warn. Il est rempli

[quote]Jul 27 21:51:37 debian nullmailer[25334]: smtp: Failed: Connect failed
Jul 27 21:51:37 debian nullmailer[1438]: Sending failed: Host not found[/quote]

Mais ça ne m’explique pas pourquoi il n’est pas archivé par la rotation des logs

Lorsque les rapports gonflent de manière démesurée, on peut essayer d’analyser “têtes et queues”, head tail.

Lire le début du rapport:

$ head rapport.log

Lire la fin du rapport:

$ tail rapport.log

cat /dev/null >/var/log/rapport-obese.log

je croyais que cat ne faisait que lister le fichier sans le vider.
Jvais faire ça, et regarder quel est le probléme qui me le rempli.

cat recrache ce qui lui est donné à avaler.
cat porte ici sur /dev/null = ø,rien,zéro,nada.
Le résultat “null” est redirigé (>) vers le fichier /var/log/rapport-obese.log dont le contenu est remplacé.
À la différence de “rm”,la redirection permet de conserver le fichier dans l’arborescence.
Bien que vidé de sa substance,le fichier n’est pas effacé, réduit à son nom dans l’arborescence.

Je vais compiler toutes ces astuces sur une page du wiki

Voilà qui est une excellente idée :023
Quelle est le titre de cette page ?

Voilà qui est une excellente idée :023
Quelle est le titre de cette page ?[/quote]

Au secours mon disque est plein

Merci! :006

cat pour concaténer.
Tu lui donnes des bouts, il te sort un seul morceau. Ca sert par exemple avec les multi-archives (r01, r02, etc…)
$ cat archive.* > archive.rar
On s’en sert un peu pour tout. (voir les useless use of cat) notament pour lister un fichier alors que less (pager) suffit.

P.s: La concaténation est brute (bit par bit). Pour de l’audio ou de la video, il faut passer par des outils d’édition.

[quote=“silver.sax”]cat pour concaténer.
Tu lui donnes des bouts, il te sort un seul morceau. Ca sert par exemple avec les multi-archives (r01, r02, etc…)
$ cat archive.* > archive.rar
On s’en sert un peu pour tout. (voir les useless use of cat) notament pour lister un fichier alors que less (pager) suffit.

P.s: La concaténation est brute (bit par bit). Pour de l’audio ou de la video, il faut passer par des outils d’édition.[/quote]

+1, il y a quelques mois (années ?) je m’en étais servi pour des videos en pièces détachées, à “nettoyer” et à reconstituer.

n’hésitez pas à compléter le page du wiki si j’ai oublié qulque chose, ou que c’est mal exprimé.
Merci à tous pour vos astuces.

[quote=“etxeberrizahar”]

cat /dev/null >/var/log/rapport-obese.log[/quote]

ça fait trop de caractères à taper :stuck_out_tongue:

encore plus simple pour le même résultat :

c’est effectivement plus concis, mais moins lisible.
Pour un tuto sur le wiki, il faut rester didactique.
“si tu vois quelqu’un qui à faim, apprends lui à pécher”