Impossible d'envoyer un mailing ou un courriel

[laurentblaise]

Bonjour,
Depuis quelques jours, je n'arrive plus à envoyer de courriel. Lorsque je clique sur "Envoyer le(s) courriel(s)", il indique "Traitement", la page charge sans fin ("en attente de www.oxfammagasinsdumonde.be) et rien ne se passe.
J'ai le même problème avec CiviMail : quand je veux passer de l'étape 3 (Contenu du publipostage) à l'étape 4 (Mail de test), la page charge aussi dans le vide.
C'est très problématique parce que je dois envoyer une newsletter à 15000 personnes vendredi.
J'ai tout essayé : j'ai désactiver les autres plugins, j'ai vidé les caches, j'ai essayé avec d'autres navigateurs, j'ai désactivé l'éditeur WYSIWYG.
Par contre, l'envoi d'un mail test sur la page "Administrer > Paramètres système > Courrier sortant" fonctionne correctement.
Quelqu'un peut m'aider ? Est-ce un problème avec MySQL ?
Merci

[mathieu]

Bonjour Laurent,

C'est étrange.. normalement si on clique "envoyer les courriels", tout ce que ça fait c'est de mettre à jour un indicateur dans la base de données pour démarrer l'envoi lors de la prochaine exécution du cron.

Quelques questions au hasard, pour essayer de trouver une piste:

* Est-ce que le problème se produit même avec un petit envoi CiviMail? (ex: vers un groupe test de 5-10 personnes).

* Est-ce que vous utilisez une passerelle de courrier pour faire les envois? (serveur smtp dédié, civismtp, etc?) ou bien l'envoi se fait directement à partir de votre serveur? (quoique j'imagine que l'envoi test ne fonctionnerait pas si c'était là le problème)

* Est-ce que c'est possible de voir le "process list" dans MySQL? Ex: "show full processlist" dans MySQL (drush sqlc). On dirait un "lock" mysql qui cause problème.

* Y a-t-il eu des mises à jour de CiviCRM ou du serveur depuis le dernier envoi massif?

* Au hasard, vérifier les logs dans /var/log/syslog, /var/log/apache2/error.log, etc. Si c'est un serveur avec systemd, "sudo journalctl -f".

Si vous êtes vraiment bloqué, je pourrais jeter un coup d'oeil sur le serveur? (mathieu@symbiotic.coop)

Mathieu

[PhilippeS]

Bonjour Laurent,

Pour trouver d'où viens le problème, il faut le décomposer.

* Tu arrives à envoyer un email de test. Donc coté serveur SMTP, c'est bon.

* Rencontres-tu des problèmes d'envoi d'email hors Civimail ? Comme dis Mathieu, essaie d'envoyer un email à 4-5 personnes via un action sur plusieurs contacts.

* Ensuite, avec CiviMail, essaie de rédiger un mailing minimum et d'arriver à l'étape 4 pour envoyer un mail de test.

* Si tu arrives jusque là, alors je dirais que ton mailing est trop complexe. Essaie d'enlever des éléments pour voir celui qui t'empêche de passer à l'étape 4.

Voilà, comment moi je procéderai pour déceler le problème.
Bonne recherche,
Philippe

[laurentblaise]

Bonjour et merci pour votre réponse,
Comme je l'expliquais, le problème se pose aussi pour l'envoi des courriels simples, même avec un seul destinataire et un contenu simple. J'ai aussi testé dans CiviMail avec juste "test" comme contenu et ça ne change rien.
Dans CiviMail, le problème se pose entre l'étape 3 (rédaction) et l'étape 4 (envoi d'un test). En fait, je n'arrive jamais à cette étape 4, donc le problème n'a rien à voir avec l'envoi proprement dit (étape 5).
Je réponds aux quelques question :

* Est-ce que le problème se produit même avec un petit envoi CiviMail? (ex: vers un groupe test de 5-10 personnes).

Oui

* Est-ce que vous utilisez une passerelle de courrier pour faire les envois? (serveur smtp dédié, civismtp, etc?) ou bien l'envoi se fait directement à partir de votre serveur? (quoique j'imagine que l'envoi test ne fonctionnerait pas si c'était là le problème)

Comme expliqué, le problème ne vient pas de l'envoi proprement dit.

* Est-ce que c'est possible de voir le "process list" dans MySQL? Ex: "show full processlist" dans MySQL (drush sqlc). On dirait un "lock" mysql qui cause problème.

Effectivement, je vois dans les logs "ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/bdd/mysql.sock' (2)". Je transmets au support d'OVH

* Y a-t-il eu des mises à jour de CiviCRM ou du serveur depuis le dernier envoi massif?

Le problème est apparu le 28/11. J'ai fait la mise à jour ce mardi vers la version 4.5.4 en espérant que ça résolve le problème, mais non.

* Au hasard, vérifier les logs dans /var/log/syslog, /var/log/apache2/error.log, etc. Si c'est un serveur avec systemd, "sudo journalctl -f".

Je suis sur un hébergement mutualisé OVH donc je pense que je n'ai pas accès à ça. CiviCRM est sur un SQL privé.

Si vous êtes vraiment bloqué, je pourrais jeter un coup d'oeil sur le serveur?

Quel type d'accès vous faut-il ?

Merci pour votre aide

[mathieu]

Hmm, je n'avais pas réalisé que c'était un hébergement mutualisé. Généralement ce type d'hébergement impose de nombreuses restrictions, que ce soit sur la durée des requêtes mysql, le nombre de fichiers ouverts, etc. Ceci dit, si ça fonctionnait par le passé, à moins d'un changement de configuration de leur côté, ça devrait continuer à fonctionner..

Par exemple, j'ai déjà rencontré un problème semblable sur un hébergement mutualisé parce qu'un fichier était ouvert dans leur éditeur texte (par le panneau de contrôle) et ça bloquait l'exécution des scripts (je n'ai jamais compris pourquoi, ni la logique d'une telle chose).

"ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/bdd/mysql.sock' (2)".

Bizarre.. avec un serveur mysql dédié, ça devrait connecter par le réseau, mais un socket c'est toujours local. (http://guide.ovh.com/CantConnectToLocalMySQL ?)

Quel type d'accès vous faut-il ?

Idéalement, un accès ssh. http://guide.ovh.com/SshMutualise

Je vais envoyer plus d'information par message privé.

Mathieu

[laurentblaise]

Pour être plus précis, notre site en Wordpress est hébergé en mutualisé chez OVH, mais la base de données de CiviCRM est sur un SQL privé (http://guides.ovh.com/GuideSqlPrive). J'ai dû passé par là parce que l'installation de CiviCRM nécessitait des "trigger privileges" et ce n'était pas possible sur l'hébergement mutualisé lui-même.
Comme ils le disent eux-mêmes, "Avec SQL privé, vous disposez de votre propre serveur SQL, tout en bénéficiant de la tranquilité d'un hébergement mutualisé géré par OVH." Il y a donc beaucoup plus de possibilités, mais c'est aussi plus compliqué à paramètrer, et c'est peut-être de là que vient le problème (je suis loin d'être un expert).
Voici le contenu de mon fichier my.cnf

Code: [Select]

[mysqld]

tmp_table_size=1M
query_cache_size=1M

skip-locking
key_buffer_size = 12M
max_allowed_packet = 1M
table_cache = 4
sort_buffer_size = 64K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
net_buffer_length = 2K
thread_stack = 128K

max_binlog_cache_size = 1M
max_join_size = 1M
max_seeks_for_key = 2M
max_write_lock_count = 512K
myisam_max_sort_file_size = 1M

########################
##Configuration Innodb##
##Uncomment the next line to disable Innodb

#skip-innodb

innodb_buffer_pool_size         = 16M
innodb_additional_mem_pool_size = 2M

innodb_log_file_size            = 10M
innodb_log_buffer_size          = 4M

innodb_flush_log_at_trx_commit=1

tmp_table_size = 2M
max_heap_table_size = 32M
thread_cache_size = 4
table_open_cache = 8



[mathieu]

Je ne suis pas sûr que la configuration MySQL soit en cause, mais c'est effectivement très minimal comme configuration.

Pour comparaison, j'utilise généralement (sur un serveur avec 4 GB ram pour web + mysql dans un VPS) :

Code: [Select]

# Attention: valeurs ridiculement élevées
# Pourrait dépasser la limite de fichiers ouverts du système d'exploitation
table_cache            = 8192
open_files_limit       = 25000

tmp_table_size  = 256M
max_heap_table_size = 256M
innodb_file_per_table
innodb_buffer_pool_size = 256M
join_buffer_size = 512K

# http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/
innodb_flush_method=O_DIRECT

query_cache_limit       = 4M
query_cache_size        = 64M

log_slow_queries       = /var/log/mysql/mysql-slow.log
long_query_time = 1

Le plus important dans cette configuration, à mon avis: c'est d'augmenter la cache de tables ouvertes, surtout si le serveur sert principalement à CiviCRM. CiviCRM + Wordpress, c'est facilement > 200 tables dans la base de données.

Selon les configurations, c'est 2 à 3 fichiers ouverts par table, d'où ma valeur ridiculement élevée par défaut.

L'autre configuration importante, c'est le "tmp_table_size". Au delà de cette limite, MySQL crée un fichier temporaire sur le disque, plutôt que de le faire en mémoire, ce qui a un coût de performance énorme.

Ceci dit, la configuration MySQL est un peu de magie, un peu de "hit and miss". L'outil mysqltuner aide beaucoup, mais il faut faire attention.

[PhilippeS]

Mailing bien reçu. 

Apparemment, tu as pu résoudre le problème. Bravo.

Par curiosité, quel était le problème ?

[laurentblaise]

C'est un mystère. Du bureau ça ne marchait pas mais de chez moi, oui. À voir la prochaine fois.