En consultant les logs d’un serveur mail Postfix, je suis tombé sur un message qui revenait régulièrement :
close database /var/lib/postfix/verify_cache.db: No such file or directory (possible Berkeley DB bug)Code language: JavaScript (javascript)À première vue, le message fait un peu peur. On lit Berkeley DB bug, on pense base de données corrompue, puis on commence à imaginer le serveur mail en train de mâcher ses propres fichiers. Bonne nouvelle : dans la plupart des cas, ce n’est pas dramatique.
Cette erreur concerne le cache de vérification d’adresses de Postfix. Lorsque Postfix utilise la vérification d’adresses, il peut stocker les résultats dans une base persistante. Ainsi, il évite de refaire les mêmes vérifications après un postfix reload ou un redémarrage du service.
Le problème survient généralement lorsque Postfix tente d’utiliser le fichier verify_cache.db, mais que la configuration de la map de vérification n’est pas assez explicite. Le démon verify essaye alors de manipuler un cache qui n’existe pas encore, ou auquel le service n’accède pas correctement via proxymap.
À quoi sert verify_cache.db dans Postfix ?
Postfix peut vérifier une adresse expéditeur ou destinataire avant d’accepter définitivement un message. Il effectue alors une sorte de test SMTP, sans livrer réellement le courrier. Le résultat de cette vérification peut ensuite être conservé en cache.
Ce cache évite de solliciter inutilement les mêmes serveurs distants. Il accélère aussi les décisions de Postfix lorsqu’une adresse a déjà été testée récemment.
La documentation Postfix indique que le paramètre address_verify_map définit la base de données persistante utilisée pour ces résultats de vérification. Sans ce paramètre, les informations de vérification sont perdues après un postfix reload ou un arrêt du service.
En clair : le fichier verify_cache.db n’est pas une boîte mail. Ce n’est pas non plus un fichier vital contenant vos messages. C’est un cache technique utilisé par Postfix pour garder en mémoire les résultats des vérifications d’adresses.
Marre des agences qui sous-traitent ?
Avec moi, vous parlez directement au développeur qui fait le travail. Pas d'intermédiaire, pas de promesses creuses. Juste du code propre et un interlocuteur joignable.
Travaillons directement ensemble →Le message est-il grave ?
Dans beaucoup de cas, non. Le message peut être sans conséquence immédiate. Le courrier continue de circuler, Postfix fonctionne, et aucune boîte mail ne disparaît dans un trou noir.
Cela dit, un log qui répète la même erreur toutes les quelques minutes mérite correction. D’abord, parce qu’un journal propre facilite le diagnostic. Ensuite, parce qu’une configuration explicite de la base de vérification évite à Postfix de travailler avec un cache mal défini.
Autrement dit, ce n’est pas forcément une urgence rouge clignotante, mais c’est le genre de petite anomalie qu’il vaut mieux corriger proprement.
Solution : déclarer address_verify_map dans main.cf
La solution consiste à déclarer explicitement la map utilisée par Postfix pour le cache de vérification d’adresses, puis à autoriser son écriture via proxy_write_maps.
Commencez par éditer le fichier de configuration principal de Postfix :
sudo nano /etc/postfix/main.cfAjoutez ensuite les lignes suivantes :
# Fix verify_cache.db warning.
address_verify_map = proxy:btree:$data_directory/verify_cache
proxy_write_maps =
$smtp_sasl_auth_cache_name
$lmtp_sasl_auth_cache_name
$address_verify_mapCode language: PHP (php)La ligne importante est celle-ci :
address_verify_map = proxy:btree:$data_directory/verify_cacheCode language: PHP (php)Elle indique à Postfix où stocker le cache persistant de vérification d’adresses. Ici, on utilise $data_directory, ce qui correspond normalement à /var/lib/postfix sur les distributions Debian et Ubuntu.
Postfix recommande d’utiliser une table btree pour ce cache, plutôt qu’une table hash. Cela explique le préfixe btree: dans la configuration.
Le préfixe proxy:, lui, indique que la table passe par le service proxymap. Dans ce cas, proxy_write_maps doit inclure $address_verify_map, afin que Postfix puisse écrire dans cette map.
Vérifier la configuration avant de recharger Postfix
Avant de recharger Postfix, vérifiez que la configuration est syntaxiquement correcte :
sudo postfix checkVous pouvez aussi contrôler les valeurs effectivement prises en compte par Postfix :
postconf -n address_verify_map proxy_write_maps data_directoryVous devriez obtenir quelque chose dans ce genre :
address_verify_map = proxy:btree:$data_directory/verify_cache
data_directory = /var/lib/postfix
proxy_write_maps = $smtp_sasl_auth_cache_name $lmtp_sasl_auth_cache_name $address_verify_mapCode language: PHP (php)Enfin, rechargez Postfix :
sudo postfix reloadou, sur une distribution utilisant systemd :
sudo systemctl reload postfix
Vérifier que l’erreur a disparu des logs
Après le rechargement, surveillez les logs Postfix :
sudo journalctl -u postfix -fSur Debian ou Ubuntu, selon votre configuration syslog, vous pouvez aussi utiliser :
sudo tail -f /var/log/mail.logCode language: JavaScript (javascript)Si tout est correct, le message suivant ne devrait plus revenir :
close database /var/lib/postfix/verify_cache.db: No such file or directory (possible Berkeley DB bug)Code language: JavaScript (javascript)Faut-il créer verify_cache.db à la main ?
Non, normalement, ce n’est pas nécessaire. Le démon verify de Postfix crée la base lorsqu’il en a besoin.
Il vaut mieux éviter les bricolages du type :
sudo touch /var/lib/postfix/verify_cache.dbCode language: JavaScript (javascript)Ce fichier n’est pas un simple fichier texte vide. Il s’agit d’une base de données Berkeley DB. Postfix doit donc la créer et la gérer lui-même.
Si la base existe déjà mais semble corrompue, vous pouvez la renommer puis recharger Postfix. Cela permet à Postfix de repartir sur un cache propre :
sudo mv /var/lib/postfix/verify_cache.db /var/lib/postfix/verify_cache.db.old
sudo postfix reloadCode language: JavaScript (javascript)Attention toutefois : ne supprimez pas des fichiers dans /var/lib/postfix au hasard. Ici, on ne parle que du cache de vérification d’adresses.
Conclusion
L’erreur close database /var/lib/postfix/verify_cache.db: No such file or directory (possible Berkeley DB bug) vient généralement d’une configuration incomplète du cache de vérification d’adresses de Postfix.
La correction consiste à définir proprement address_verify_map, puis à ajouter cette map à proxy_write_maps si vous utilisez le préfixe proxy:.
Une fois Postfix rechargé, les logs devraient redevenir propres. Et franchement, un mail.log propre, c’est presque aussi satisfaisant qu’un postfix check silencieux.
Pour référence, le rapport Debian original mentionne également ce comportement : bug Debian #578862.
Sources
- Documentation officielle Postfix sur la vérification d’adresses
- Manuel Postfix verify(8)
- Manuel Postfix proxymap(8)
- Rapport Debian #578862
Marre des agences qui sous-traitent ?
Avec moi, vous parlez directement au développeur qui fait le travail. Pas d'intermédiaire, pas de promesses creuses. Juste du code propre et un interlocuteur joignable.
Travaillons directement ensemble →
