Demande #6364
fermé/var plein sur drupal6
100%
Description
Depuis le 20 février, un très grand nombre de "strict warning" PHP apparaissent dans les logs :
(April) root@drupal6:~# df -h /var/ Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_drupal6-var 6.6G 6.3G 0 100% /var (April) root@drupal6:~# ls -lh /var/log/apache2/www.april.org.error.log{,.1} -rw-r----- 1 root adm 2.6G Feb 27 00:13 /var/log/apache2/www.april.org.error.log -rw-r----- 1 root adm 2.1G Feb 26 06:27 /var/log/apache2/www.april.org.error.log.1 (April) root@drupal6:~# wc -l /var/log/apache2/www.april.org.error.log 2819608 /var/log/apache2/www.april.org.error.log (April) root@drupal6:~# grep -vF "strict warning" /var/log/apache2/www.april.org.error.log | wc -l 2428 (April) root@drupal6:~# zcat /var/log/apache2/www.april.org.error.log.7.gz | grep "strict warning" |wc -l 0 (April) root@drupal6:~# zcat /var/log/apache2/www.april.org.error.log.6.gz | grep "strict warning" |wc -l 2933163 (April) root@drupal6:~# zcat /var/log/apache2/www.april.org.error.log.6.gz | grep -m 1 "strict warning" [Tue Feb 20 14:51:15.029366 2024] [:error] [pid 14265] [client <redacted>:60766] PHP Warning: Duplicate entry '2147483647' for key 'PRIMARY'\nquery: INSERT INTO watchdog\n (uid, type, message, variables, severity, link, location, referer, hostname, timestamp)\n VALUES\n (0, 'php', '%message in %file on line %line.', 'a:4:{s:6:\\"%error\\";s:14:\\"strict warning\\";s:8:\\"%message\\";s:134:\\"Declaration of views_handler_filter::options_validate() should be compatible with views_handler::options_validate($form, &$form_state)\\";s:5:\\"%file\\";s:75:\\"/etc/drupal/6/sites/default/modules/views/handlers/views_handler_filter.inc\\";s:5:\\"%line\\";i:0;}', 3, '', 'https://www.april.org/april?amp=&page=205,1,5,5,2,8,7,3,3', '', '<redacted>#039;, 1708437075) in /usr/share/drupal6/includes/database.mysql.inc on line 135
Mis à jour par Pierre-Louis Bonicoli il y a 10 mois
- Statut changé de Nouveau à En cours de traitement
- Assigné à mis à Pierre-Louis Bonicoli
Mis à jour par Pierre-Louis Bonicoli il y a 10 mois
J'ai appliqué le patch ci-dessous le temps de forcer deux fois de suite la rotation du fichier avec logrotate --force /etc/logrotate.d/apache2
(April) root@drupal6:~# git -C /srv/common/etc diff logrotate.d/apache2 diff --git a/etc/logrotate.d/apache2 b/etc/logrotate.d/apache2 index d82bc76..b38e3dc 100644 --- a/etc/logrotate.d/apache2 +++ b/etc/logrotate.d/apache2 @@ -1,6 +1,7 @@ -/var/log/apache2/*/*.log -/var/log/apache2/*_log -/var/log/apache2/*.log { +#/var/log/apache2/*/*.log +#/var/log/apache2/*_log +#/var/log/apache2/*.log { +/var/log/apache2/www.april.org.error.log { daily missingok rotate 14
Mis à jour par Pierre-Louis Bonicoli il y a 10 mois
- Statut changé de En cours de traitement à Résolu
- % réalisé changé de 0 à 100
La colonne wid
de la table watchdog
et de type int
AUTO_INCREMENT=2147483648
a atteint sa valeur maximum.
Il n'y a que 100 lignes dans la table watchdog:
mysql> select count(*) from watchdog; +----------+ | count(*) | +----------+ | 100 | +----------+ 1 row in set (0.00 sec) mysql> select wid from watchdog order by wid asc limit 1; +------------+ | wid | +------------+ | 2147483548 | +------------+ 1 row in set (0.00 sec) mysql> select wid from watchdog order by wid desc limit 1; +------------+ | wid | +------------+ | 2147483647 | +------------+ 1 row in set (0.00 sec)
J'utilise cette commande mysqldump -p --no-data --compact drupal6
et cette query pour vérifier que wid
n'est pas réutiliser dans une autre table et je réinitialise le compteur: TRUNCATE TABLE watchdog
;
Une tâche cron de drupal ne conserve que les 100 dernières entrées de la table watchdog
. Cette tâche cron est exécutée tous les jours à minuit (cf /etc/cron.d/drupal6
).
Si je comprends bien la doc drupal, on ne peut pas choisir d'exclure les warnings des logs.
Mis à jour par Pierre-Louis Bonicoli il y a 10 mois
- Lié à Demande #1919: Patcher le Drupal pour éviter de remplir la table watchdog ajouté
Mis à jour par Pierre-Louis Bonicoli il y a 10 mois
- Lié à Anomalie #3532: Le filesystem de la VM Drupal partie Mysql se remplit dangereusement ajouté
Mis à jour par Pierre-Louis Bonicoli il y a 5 mois
Problème à nouveau rencontré ce jour et résolu via TRUNCATE TABLE watchdog
.