web-dev-qa-db-fra.com

Comment limiter la taille de mon syslog?

L'ordinateur de ma mère utilise Ubuntu 12.04 LTS. Cela fonctionne très bien, mais soudainement, syslog s'est rempli. Et en remplissant, je veux dire que je viens de supprimer un /var/log/syslog d’une taille de 400 Go. Oui - gigaoctets.

Bien que je sois sûr qu'il contienne des informations utiles, je ne suis pas sûr que 400 Go soit une sorte d'information à parcourir. Et ce qui est vraiment étonnant, c’est que cela s’est passé dans un délai de 8 heures - j’avais couru dfvers midi, et entre-temps et maintenant, son lecteur s’est rempli à 30% (d’un peu moins de 70% à 100%).

Quelle pourrait en être la cause et comment pourrais-je résoudre le problème?

EDIT On dirait que l'USB est le coupable:

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
syslogusbfs
13
Wayne Werner

Vous devriez savoir ce qui cause la grande quantité de messages, car si vous corrigez ce problème, vous corrigez le fichier journal volumineux.

Cependant, jusque-là, vous pouvez créer une base de rotation de journal sur l’un des éléments suivants.

  • heure (ex. rotation tous les jours)
  • taille (par ex. rotation lorsque le fichier atteint 10 Mo)

Ce 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
 }

Vous pouvez voir à partir de cela qu'il fera pivoter le fichier/var/log/syslog quotidien et conservera 7 copies du fichier pivoté.

Vous pouvez changer cette taille en faisant pivoter une limite de taille, par exemple 1 Mo ou en réduisant le nombre de copies stockées.

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

  • Source: /etc/logrotate.d/rsyslog
  • Source: man logrotate
12
dannyla

Limiter la taille de logrotate

Ouvrez le fichier de configuration /etc/logrotate.d/syslog

Sudo nano /etc/logrotate.d/syslog

Le fichier a l'air qc. comme

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

Ajouter 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 des fichiers en rotation, et non le fichier syslog réel. Enregistrez le fichier. La prochaine fois que le travail logrotate chron démarrera, il limitera la taille des journaux pivotés.

Limiter la taille du syslog actuel

Pour limiter la taille de /var/log/syslog, vous devez éditer le /etc/rsyslog.d/50-default.conf et 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 de manuel de rsyslog :

Les canaux de sortie sont définis via une directive $ outchannel. Sa syntaxe est la suivante: $ nom outchannel, nom de fichier, taille maximale, action-on-max-size nom est le nom du canal de sortie (pas le fichier), nom de fichier est le nom du fichier dans lequel écrire , max-size la taille maximale autorisée et l'action-on-max-size qu'une commande doit être émise lorsque la taille maximale est atteinte. Cette commande a toujours exactement un paramètre. Le binaire est la partie de action-on-max-size 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 de journal dans le fichier. Veillez donc à définir une limite suffisamment basse pour que tout message puisse tenir. Pour la version actuelle, il est utile de le régler 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 (tels que 1k, 1m,…) à ce stade de développement. Gardez à l'esprit que $ outchannel définit simplement un canal avec “name”. Cela ne l’active pas. Pour ce faire, vous devez utiliser une ligne de sélection (voir ci-dessous). Cette ligne de sélecteur comprend le nom de la chaîne et un signe $ devant celle-ci. Voici un exemple: . : omfile: $ mychannel Dans sa forme actuelle, les canaux de sortie permettent principalement 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 devrait être quelque chose comme un script de rotation de journal ou une chose similaire.

S'il n'y a pas de commande action-on-max-size ou si la commande n'a pas résolu le problème, le fichier est fermé et jamais rouvert par rsyslogd (sauf, bien sûr, en le survolant). Cette logique a été intégrée lorsque nous avons rencontré pour la première fois de graves problèmes avec des fichiers de taille supérieure à 2 Go, ce qui pourrait entraîner une décharge de base de rsyslogd. Dans de tels cas, il est plus approprié d'arrêter l'écriture dans un seul fichier. Pendant ce temps, rsyslogd a été corrigé pour prendre en charge les fichiers plus volumineux, mais uniquement sur les systèmes de fichiers et les versions de système d'exploitation qui le font. Il peut donc toujours ê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 remplacez la ligne *.*; ... par

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

Redémarrez rsyslogd

Sudo service rsyslog restart
5
abu_bua

J'ai eu le même problème avec une Lexmark Pro915 pendant deux semaines. J'ai fait deux choses, et cela fonctionne maintenant bien. J'ai réinstallé le pilote. (Ne croyez pas que c'est ce qui a aidé.) J'ai sorti l'extension USB que j'utilisais, qui faisait presque 15 pieds de long et qui n'était peut-être pas tout à fait compatible. Je soupçonne que le pilote Lexmark pour systèmes Linux pourrait détecter un signal médiocre ou mal synchronisé et vouloir vous en informer 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 s'exécuter toutes les douze minutes.

0
Dale F.