Oui je me suis fait avoir, oui je suis parti en mode R&D pour comprendre d’où sortait cette erreur sans cause apparente, oui j’ai tenté de bidouiller mon my.cnf pour rajouter la variable « language » et définir ainsi le path vers ce fameux « errmsg.sys » inconnu au bataillon de mon serveur MySQL…
Faute avouée est à demi-pardonnée, alors autant dire que publiée sur un blog elle est carrément excusée 
« L’astuce » est donc la suivante :
Vérifiez que vos « clients » MySQL lisent bien le bon my.cnf… La doc ne fait pourtant pas mystère de la façon dont les fichiers de configuration (my.cnf en tête de gondole) sont lus.
« If multiple instances of a given option are found, the last instance takes precedence. » Autrement dit, le dernier qui parle à raison et mon my.cnf (/etc/my.cnf) était écrasé par d’autres copies de my.cnf dont je n’avais pas vérifié l’existence cette fois-ci.
Pour vérifier les fichiers lus par défaut (et dans quel ordre) :
> mysql --help | grep 'my.cnf'
On obtient sur cette machine :
order of preference, my.cnf, $MYSQL_TCP_PORT,
/etc/my.cnf /etc/mysql/my.cnf /usr/local/mysql/etc/my.cnf ~/.my.cnf
Si vous ne souhaitez pas que le /etc/mysql/my.cnf écrase ou redéfinisse certaines de vos variables (« datadir » et « basedir » par exemple) du /etc/my.cnf précédent, un renommage du my.cnf superflu résoudra le problème.
Mots-clefs : pratique