{{tag>sysadmin linux logs logrotate}}


====== logrotate: rotation des fichiers logs ======

Principal intérêt de logrotate: limiter l'accroissement à l'infini des fichiers logs.

Pour chaque fichier journal logrotate agit en 2 étapes:
  - rotation: archive le fichier de log et supprime les anciennes versions.
  - compression: si définit, compression des fichiers archivés. 

<note>
L'opération de compression diminue l'occupation disque mais accroît les opérations d'I/O et l'usure disque ainsi que la consommation d’énergie.
</note>

Le système gère la planification de l’exécution régulière de logrotate, il suffit d'éditer les fichiers de configuration dans /etc/logrotate.d/ et de ne plus s'en soucier.

===== Principales directives =====

^ daily,weekly,monthly    | Périodicité de rotation du fichier de log |
^ rotate n                | Conserve n rotations                      |
^ create  nnnn user group | Création d'un fichier vide après rotation avec les droits d'accès spécifiés ici. |
^ compress, nocompress    | L' archive du log sera compressée ou pas.         |
^ delaycompress           | Si la compression est active, elle a lieu lors de la prochaine rotation. |
^ missingok               | Ne pgénère pas d'erreur si le ficheir de log est manquant. N’arrête pas le processus et poursuit avec le fichier de log suivant. |
^ notifempty              | Pas de rotation si le fichier de log est vide. |
^ size                    | Définir une taille limite déclenchant la rotation. Cette directive est prioritaire sur la périodicité de rotation. |
^ prerotate/endscript     | Actions/commandes a exécuter avant rotation. |
^ postrotate/endscript    | Actions/commandes a exécuter après rotation. |
^ sharedscripts           | Les scripts pre/postrotate sont exécutés une seule fois pour le fichier log considéré et non pas à chaque rotation. |
^ su user group           | Change l'utilisateur/groupe d’exécution de logrotate pour la création du fichier archive |
^ dateext                 | Ajouter une date en suffixe au nom du fichier archive. |

===== Syntaxe =====

Les directives sont groupées entre crochets { } et s'appliquent sur un ou plusieurs fichiers journaux:

<file>

/path/to/file-1.log
{
  directive 1
  directive 2
  ...
  directive n
}

/path/to/file-2.log
/path/to/file-3.log
...
/path/to/file-n.log
{
  directive 1
  directive 2
  ...
  directive n
}
</file>

===== Contrôle des rotations =====

logrotate trace ses actions dans le fichiers **/var/lib/logrotate/status** le fichier texte indique pour chaque entrée le nom du fichier de log et le timestamp de la dernière altération.

Pour lancer manuellement logrotate utiliser l'option **-f** ou **%%--force%%** avec le fichier de configuration à tester (configuration globale ou dédiée) 
<code bash>
logrotate --verbose --force /etc/logrotate.d/nextcloud
logrotate --verbose --force /etc/logrotate.conf
</code>

Pour déboguer/vérifier le bon fonctionnement la configuration courante utiliser l'option **-d** ou **%%--debug%%**:
<code bash>
logrotate -d /etc/logrotate.conf
</code>

<note>
Avec l'option **-d**, les notifications sont affichées mais aucune modification n'est apportée au système de fichier (exécution dry-run).
</note>


===== Sécurité et droits d'accès =====

Par sécurité logrotate interrompt le processus de rotation si les droits d'écritures sur le répertoire contenant les logs ne sont pas limités au groupe root. L'erreur est clairement remontée lors de l’exécution de logrotate avec l'option debug:

<file>
error: skipping "/path/to/log/file.log" because parent directory has insecure permissions (It'
s world writable or writable by group which is not "root") Set "su" directive in config file to tell
 logrotate which user/group should be used for rotation.
</file>

Si un groupe autre que root a le droit d’écriture sur le dossier contenant le fichier log, il doit être précisé dans la configuration de logrotate via la directive **su** afin que la rotation puisse s’effectuer.

<file>
# Exemple de rotation de fichiers de logs
# contenus dans un dossier ayant pour proprietaire www-data 

/srv/appweb/log/access.log
/srv/appweb/log/error.log
/srv/appweb/log/php_error.log
{
  su www-data www-data
  weekly
  rotate 4
  nocompress
  missingok
  create 0640 www-data www-data
}

</file>

===== Exécution par l'utilisateur =====

**logrotate** peut être lancé périodiquement par un tout utilisateur non privilégié du système. Pour cela l'utilisateur crée son fichier de configuration et utilise cron pour appeler logrotate avec la périodicité qu'il souhaite:

<code bash>
crontab -e
</code>

La commande présente dans le fichier cron sera de la forme:

<file>
# Exemple de contenu du crontab de l'utilisateur
15 * * * * /usr/sbin/logrotate /home/username/logrotate.conf --state /home/username/logrotate-state
</file>

===== Troubleshooting =====

==== La rotation des logs ne se produit pas ====

Lorsque logrotate est exécuté avec l'argument **-d** les messages ne retournent pas d'anomalies cependant la rotation des logs ne se fait pas.

Ceci peut être du à:
  * Des problèmes de droits d'accès lorsque logrotate s’exécute sous un autre compte que root (directive su) 
  * Si des scripts prerotate existent une erreur d'exécution peut interrompre le processus.

Invoquer la commande logrotate avec le fichier de configuration à tester et l'option -f pour forcer l’exécution d'une rotation et déclencher l'appel des scripts. Les erreurs retournées devront être corrigées.

 
==== Apache n’écrit pas dans le nouveau fichier de log ====

La rotation des logs de l'hôte virtuel apache s'est bien exécutée mais apache continue à écrire dans le fichier précédent xxx.log.1 au lieu d'utiliser xxx.log

Dans ce cas, utiliser la directive postrotate/endscript pour recharger la configuration apache après rotation:

<file>
postrotate
/usr/sbin/apache2ctl -k graceful
endscript
</file>

<note>
L'option **copytruncate** tronque le fichier log courant en place après avoir créer une copie plutôt que de renommer le fichier et de créer un nouveau fichier vide. Elle est nécessaire pour les services pour lesquels on ne peut pas demander la fermeture de leur fichiers de logs. 
</note>

==== UFW : le fichier ufw.log reste vide après rotation ====

Après rotation, le nouveau fichier ufw.log reste vide. Les événements continuent à être écris dans le fichier archive ufw.x.log

C'est le daemon rsyslogd qui se charge d'écrire les messages dans le fichier /var/log/ufw.log. Dans le fichier de configuration /etc/logrorate.d/ufw, on peut voir que la commande proposée par défaut retourne une erreur quand elle est exécutée manuellement.

<code bash>
invoke-rc.d rsyslog rotate
* Closing open files rsyslogd                                                            [fail]
</code>

Cela peut être du au fait que rsyslog géré comme unité  par **systemd**. Les commandes suivantes ont le même effet et ne retourne pas d'erreur:
<code bash>
# cette commande est aussi utilisée par d'autres fichiers de configuration
/usr/lib/rsyslog/rsyslog-rotate

# equivalent
systemctl kill -s HUP rsyslog.service
</code>

Ci-dessous un exemple de fichier **''/etc/logrotate.d/ufw''** modifié:

<file conf ufw>
/var/log/ufw.log
{
  su root syslog

  # Rotation quotidienne
  daily 

  # Conserve 30 fichiers (un mois) 
  rotate 30

  # Les fichiers archives ne sont pas compressés
  nocompress

  # Ne génère pas de message d'erreur si le fichier est manquant
  missingok

  # droit d'acces et propriétaire du fichier apres rotation
  create 0644 syslog adm

  sharedscripts
  postrotate
    /usr/lib/rsyslog/rsyslog-rotate
  endscript
}
</file>

===== Références =====

  * https://memo-linux.com/logrotate/
  * https://doc.ubuntu-fr.org/logrotate
  * https://www.croc-informatique.fr/2009/06/rotation-des-logs-avec-logrotate/
  * https://chasemp.github.io/2013/07/24/su-directive-logrotate/
  * https://www.techrepublic.com/article/manage-linux-log-files-with-logrotate/
  * https://linoxide.com/setup-log-rotation-logrotate-ubuntu/
  * https://www.digitalocean.com/community/tutorials/how-to-manage-logfiles-with-logrotate-on-ubuntu-20-04