Voir en fin de page pour le téléchargement ds scripts "correcteurs" qui fonctionnent très bien sur la nouvelle VM en Ubuntu 20.04.

Mon installation de Zimbra est assez ancienne sur une Ubunto 16.04 LTS, mais maintenue régulièrement à jour avec le repository de Zimbra dans mon /etc/apt/sources.list.z/zimbra.list qui content : 
deb     [arch=amd64] https://repo.zimbra.com/apt/87 xenial zimbra 
deb     [arch=amd64] https://repo.zimbra.com/apt/8815 xenial zimbra 
deb-src [arch=amd64] https://repo.zimbra.com/apt/87 xenial zimbra 
Lors de la dernière mise à jour apt m'a proposé d'installer un paquet (...) pour bénéficier des mises à jour étendues (livepatch) de ma version 16.04 LTS. 
Après m'être inscrit sur le site de Canonical (gratuit jusqu'à 3 machines) j'ai installé la clef fournie et relancé une mise à jour qui m'a proposé plus de 100 paquets à mettre à jour, ce que je me suis empressé de lancer. 
A la suite de cette installation je reçois de Zimbra une multitude de messages signalant des disques pleins à 100%. Ces disques sont respectivement /dev/loop0 et /dev/loop1 sur lesquels sont montés (cf snap) les répertoires nécessaires à "livepatch". 
J'ai ainsi reçu plus de 800 messages en deux jours me signalant ces disques "pleins". 
Or c'est parfaitement normal que ces "disques" soient à 100%, c'est le fonctionnement normal de "snap",il faut donc inhiber la procédure "Zimbra" qui génère ces alertes. 
On dirait que les auteurs de Zimbra ont prévu le coup car il est possible très simplement de mettre à jour le paramètre "zmstat_df_exclude" qui doit régler ce problème. 

1) Voyons voir le paramètre "ad hoc" 
zmlocalconfig | grep zmstat_df_excludes 
qui renvoie 
zmstat_df_excludes = 
soit : aucune exclusion enregistrée. 

1) commencer par établir la liste de ces devices "loop..." 
df | grep loop 
/dev/loop0        101888   101888         0 100% /snap/core/11993 
/dev/loop1          9344     9344         0 100% /snap/canonical-livepatch/119 

Ensuite lancer la commande suivante (user "zimbra") : 
zmlocalconfig -e zmstat_df_excludes="/dev/loop0:/dev/loop1" 
Bien utiliser ":" comme séparateur. 
Et le tour est joué, plus de messages inutiles et ennuyeux, tout en gardant les alertes pour les autres systèmes de fichiers. 

Pour vérifier : 
zmlocalconfig | grep zmstat_df_excludes 
qui, maintenant renvoie : 
zmstat_df_excludes = /dev/loop0:/dev/loop1 
ce qui semble parfait et d'ailleurs je n'ai pas reçu d'autres messages au sujet de ces deux "disques". 
Note : il faut surveiller l'apparition de nouveaux "/dev/loopN" et les ajouter illico à la liste. 

J'ai eu la surprise, quelques jours après de recevoir une salve de mail pour un nouveau "livepatch" qui m'a créé un nouveau "loop" : 
/dev/loop2              9344     9344          0 100% /snap/canonical-livepatch/126 

J'ai donc du l'ajouter avec (en user "zimbra") : 
zmlocalconfig -e zmstat_df_excludes="/dev/loop0:/dev/loop1:/dev/loop2"

A vérifier immédiatement par : 
zmlocalconfig | grep zmstat_df_excludes 
zmstat_df_excludes = /dev/loop0:/dev/loop1:/dev/loop2 

.... A surveiller après chaque mise à jour ... Mais que fait-on après 20 mises à jour, a-t-on 21 /dev/loopNN ?

Suite à un problème de gestion de certificat j'ai monté une nouvelle machine virtuelle en Ubuntu 20.04, évidemment elle "souffrait" du même problème que la précédente ... mais, rien n'y fait, même en appliquant cette méthode cette fichue machine m'inonde de mails signalant que le disque /dev/snapxx est à 100%. 
C'est toutes les 10 minutes et il y a actuellement 13 "disques" snap. J'ai signalé cette anomalie sans avoir de réponse pour le moment ... 
Dernières nouvelles : après quelques jours la configuration des "df_exclude" est enfin active et je n'ai plus des centaines/milliers de mails intempestifs ... Mais pourquoi cela a mis plusieurs jours pour s'activer reste un mystère. 
En fait il semble qu'il faille effectuer un restart complet de zimbra pour que la nouvelle configuration soit activée. 
Note 2022 
Je suis depuis "passé" sur Ubuntu 20.04 LTS puisque le 16.04 est tombé hors "LTS". 
Mais le résultat est le même, zimbra s'entête à me déclarer tous les disques /dev/snap/... (nom du "répertoire" où sont montés les /dev/loopNN au nombre de 14 à ce jour. 
J'utilise deux petits scripts qui :

• RECUP_LOOP    récupère les "loop" et les répertoires associés sous forme de liste et appelle le script suivant, télécharger.
• SNAP_EXCLUDE qui met en forme les données et lance l'exécution de la commande zimbra "zmlocalconfig" avec la liste des "loop" et répertoires transmise par le premier script, télécharger.

J'ai mis dans la crontab l'exécution de RECUP_LOOP tous les soirs.