Comment limiter la taille de mon syslog?

J'ai l'ordinateur de ma mère qui exécute Ubuntu 12.04 LTS. Cela fonctionne très bien, mais tout le syslog soudain s'est rempli. Et en remplissant, je veux dire que je viens de supprimer un /var/log/syslogqui faisait 400 Go. Oui - Gigaoctets.

Bien que je sois sûr qu'il y avait des informations utiles là-dedans, je ne suis pas sûr que 400 Go soient des informations à passer au crible. Et ce qui est vraiment étonnant, c'est que cela s'est produit dans un délai de 8 heures - j'avais couru dfvers midi, et entre-temps et maintenant, son entraînement était à 30% (passant d'un peu moins de 70% à 100%).

Qu'est-ce qui pourrait être à l'origine de cela et comment pourrais-je le réparer?

EDIT On dirait que l'USB est le contrevenant:

Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157829] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157836] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157842] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157849] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157857] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157863] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157870] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157877] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157884] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157891] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use

Vous devez savoir ce qui cause la grande quantité de messages, comme si vous résolviez ce problème, vous corrigez le gros fichier journal.

Cependant, jusque-là, vous pouvez mettre une base de rotation des journaux sur l'un des ci-dessous.

• heure (par exemple, tourner tous les jours)
• taille (par exemple, faire pivoter lorsque le fichier atteint 10 Mo)

Cela sera déjà configuré sur le système par défaut: /etc/logrotate.d/rsyslog

 /var/log/syslog
{
    rotate 7
    daily
    missingok
    notifempty
    delaycompress
    compress
    postrotate
            reload rsyslog >/dev/null 2>&1 || true
    endscript
 }

De cela, vous pouvez voir qu'il fera tourner le fichier / var / log / syslog quotidiennement et conservera 7 copies du fichier tourné.

Vous pouvez changer cela pour qu'il pivote sur une taille limite, disons 1 Mo ou réduire le nombre de copies qu'il stocke.

Avertissement: cela ne résoudra pas la cause première de votre problème , mais cela vous fera gagner du temps car cela empêchera le système de fichiers de se remplir.

• Source: /etc/logrotate.d/rsyslog
• Source: homme logrotate

Limitez la taille du logrotate

Ouvrez le /etc/logrotate.d/syslogfichier de configuration

sudo nano /etc/logrotate.d/syslog

Le fichier ressemble à qch. comme

/var/log/syslog
{
    rotate 7
    daily
    missingok
    notifempty
    delaycompress
    compress
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}
....
...

Ajoutez par exemple size 100k entre parenthèses. Ensuite, cela devrait ressembler à:

/var/log/syslog
{
    rotate 7
    size 100k
    daily
    missingok
    notifempty
    delaycompress
    compress
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

Notez que cela limite la taille de fichier des fichiers en rotation et non le fichier Syslog réel. Enregistrez le fichier. La prochaine fois que le travail de chronologie logrotate démarre, cela limitera la taille des journaux tournés.

Limitez la taille du journal système actuel

Pour limiter la taille de /var/log/syslog, vous devez modifier le /etc/rsyslog.d/50-default.confet définir une taille de journal fixe.

Ajoutez ou modifiez ce paramètre en modifiant la ligne suivante dans /etc/rsyslog.d/50-default.conf:

.*;auth,authpriv.none       -/var/log/syslog

Voici un extrait du manuel rsyslog :

Canaux de sortiesont définis via une directive $ outchannel. Sa syntaxe est la suivante: $ outchannel name, file-name, max-size, action-on-max-size name est le nom du canal de sortie (pas le fichier), file-name est le nom du fichier à écrire , max-size la taille maximale autorisée et action-on-max-size une commande à émettre lorsque la taille maximale est atteinte. Cette commande a toujours exactement un paramètre. Le binaire est la partie de l'action sur la taille max avant le premier espace, son paramètre est tout derrière cet espace. Veuillez noter que max-size est interrogé AVANT d'écrire le message du journal dans le fichier. Assurez-vous donc de définir cette limite raisonnablement basse pour que tout message puisse tenir. Pour la version actuelle, il est utile de la définir 1k plus bas que prévu. La taille maximale doit toujours être spécifiée en octets - il n'y a pas de symboles spéciaux (comme 1k, 1m, …) À ce stade de développement. Gardez à l'esprit que $ outchannel définit simplement un canal avec «nom». Il ne l’active pas. Pour ce faire, vous devez utiliser une ligne de sélection (voir ci-dessous). Cette ligne de sélection comprend le nom de la chaîne plus un signe $ devant. Un échantillon pourrait être:. : omfile: $ mychannel Dans leur forme actuelle, les canaux de sortie offrent principalement la possibilité de limiter la taille d'un fichier de sortie. Pour ce faire, spécifiez une taille maximale. Lorsque cette taille est atteinte, rsyslogd exécutera la commande action-on-max-size, puis rouvrira le fichier et réessayera. La commande doit être quelque chose comme un script de rotation de journal ou quelque chose de similaire.

S'il n'y a pas de commande action-on-max-size ou si la commande n'a pas résolu la situation, le fichier est fermé et jamais rouvert par rsyslogd (sauf, bien sûr, en le sautant). Cette logique a été intégrée lorsque nous avons rencontré pour la première fois de graves problèmes avec des fichiers de plus de 2 Go, ce qui pouvait entraîner le vidage de rsyslogd. Dans de tels cas, il est plus approprié d'arrêter d'écrire dans un seul fichier. Pendant ce temps, rsyslogd a été corrigé pour prendre en charge les fichiers de plus de 2 Go, mais évidemment uniquement sur les systèmes de fichiers et les versions de système d'exploitation qui le font. Il peut donc être judicieux d'appliquer une limite de taille de fichier de 2 Go.

Ici, la taille maximale est de 1 Mo, placez cette ligne avant la *.*; ...ligne

$outchannel mysyslog,/var/log/syslog,1048576

et changer la *.*; ...ligne en

*.*;auth,authpriv.none  :omfile:$mysyslog

Redémarrez rsyslogd

sudo service rsyslog restart

J'ai eu le même problème avec une Lexmark Pro915 pendant deux semaines. J'ai fait deux choses, et ça marche maintenant bien. J'ai réinstallé le pilote. (Ne pensez pas que c'est ce qui a aidé.) J'ai retiré l'extension USB que j'utilisais, ce qui rendait la longueur totale presque 15 'de long et qui n'était peut-être pas entièrement compatible. Je soupçonne que le pilote Lexmark pour les systèmes Linux pourrait détecter un signal médiocre ou mal synchronisé et vouloir vous en parler 10 milliards de fois par jour. Essayez d'améliorer votre connexion d'une manière ou d'une autre.

Logrotate et des solutions similaires ne m'ont pas aidé. Kern.log et syslog enregistraient ensemble plus de 1 To par jour! Logrotate pourrait vous aider si vous pouviez le configurer pour qu'il s'exécute toutes les douze minutes.