Comment puis-je libérer de l'espace dans un dossier /var/log/ de 39,5 Go ?

Je ne supprimerais pas l'intégralité du dossier /var/log - cela casserait les choses.

Vous pourriez simplement détruire les journaux comme le suggère @jrg - mais à moins que les choses qui écrivent dans les fichiers journaux (principalement syslogd) ne soient redémarrées, cela ne vous fera pas regagner d'espace disque, car les fichiers continueront d'exister dans un état supprimé jusqu'à ce que les filehandles soient fermés.

Le mieux serait de trouver pourquoi les journaux ne sont pas tournés (et plus tard supprimés). logrotate est censé faire cela pour vous, et je soupçonne qu'il n'est pas exécuté chaque nuit comme il le devrait.

La première chose que je ferais serait :

sudo /etc/cron.daily/logrotate

Ce site devrait faites tourner les fichiers journaux (ainsi kern.log devient kern.log.1) ; et vous pouvez ensuite supprimer kern.log.1 etc. pour libérer l'espace disque.

Si tout est bon jusqu'ici, la question suivante est de savoir pourquoi cela ne se produit pas automatiquement. Si vous éteignez votre ordinateur la nuit, assurez-vous d'avoir anacron installé.

Vous devriez regarder les journaux et voir ce qui y est écrit. Je pense que c'est ufw/iptables (vous enregistrez tout le trafic réseau).

ufw - si vous enregistrez tous les paquets, vous obtiendrez des journaux volumineux. Si vous n'avez pas l'intention d'examiner les journaux, désactivez la journalisation. Si vous souhaitez surveiller votre réseau, utilisez snort. Snort filtrera les milliers de paquets que vous recevez et vous alertera sur le trafic potentiellement problématique.

Je pense que l'ufw est le coupable et que vous obtenez un grand journal dans kern.log parce que vous y enregistrez également des paquets.

Parfois, un problème de noyau ou de matériel remplit les journaux. Dans ce cas, il est préférable de résoudre le problème ou de signaler un bogue. Pour ce faire, vous devrez examiner les journaux.

Si vous ne pouvez pas résoudre le problème, vous pouvez configurer syslog de manière à ne pas remplir vos journaux.

Voir http://manpages.ubuntu.com/manpages/precise/man5/syslog.conf.5.html

Si vous fournissez plus de détails sur le problème, nous pourrons mieux le déboguer.

AVERTISSEMENT : Je ne suis pas un expert en la matière, à utiliser à vos propres risques !

Après avoir constaté que mon /var/log/journal Le dossier prenait plusieurs GB, j'ai suivi :

https://ma.ttias.be/clear-systemd-journal/

journalctl --vacuum-time=10d

ce qui a permis d'éliminer plus de 90 % du problème

Suppression de /var/log est probablement une mauvaise idée, mais la suppression des fichiers journaux individuels devrait être correcte.

Sur mon ordinateur portable, avec un disque SSD assez petit, j'ai configuré /var/log (et /tmp y /var/tmp ) comme tmpfs en ajoutant les lignes suivantes à /etc/fstab :

temp        /tmp        tmpfs   rw,mode=1777    0   0
vartmp      /var/tmp    tmpfs   rw,mode=1777    0   0
varlog      /var/log    tmpfs   rw,mode=1777    0   0

Cela signifie que rien dans ces répertoires survit à un redémarrage. Pour autant que je puisse dire, cette configuration fonctionne parfaitement. Bien sûr, je perds la possibilité de consulter les anciens journaux pour diagnostiquer les problèmes qui pourraient survenir, mais je considère que c'est un compromis équitable pour l'utilisation réduite du disque.

Le seul problème que j'ai eu est que certains programmes (notamment APT) veulent écrire leurs journaux dans des sous-répertoires de /var/log et ne sont pas assez intelligents pour créer ces répertoires s'ils n'existent pas. Ajout de la ligne mkdir /var/log/apt sur /etc/rc.local a réglé ce problème particulier pour moi ; selon le logiciel que vous avez installé, vous devrez peut-être créer d'autres répertoires également.

(Une autre possibilité serait de créer un simple tar contenant juste les répertoires, et de le décomposer en /var/log au démarrage pour créer tous les répertoires nécessaires et définir leurs permissions en une seule fois).