Pour faire suite à cette échange au sujet des sauvegardes planifiées (=> cron/card.php?id=6) sur un hébergement où le programme de dump de base de données est mariadb-dump et non mysqldump, je me pose la question de la déclaration de la variable SYSTEMTOOLS_MYSQLDUMP.
En effet, dans le détail du job planifié de « Sauvegarde locale de base » (=> cron/card.php?id=6), on voit que le Nom de fichier intégrant la classe est core/class/utils.class.php
Et dans core/class/utils.class.php on trouve à partir de la ligne 295 (dolibarr 21.0.1):
// MYSQL
if ($type == 'mysql' || $type == 'mysqli') {
if (!getDolGlobalString('SYSTEMTOOLS_MYSQLDUMP')) {
$cmddump = $db->getPathOfDump();
} else {
$cmddump = getDolGlobalString('SYSTEMTOOLS_MYSQLDUMP');
}
if (empty($cmddump)) {
$this->error = "Failed to detect command to use for mysqldump. Try a manual backup before to set path of command.";
return -1;
}
Mais où doit-on déclarer SYSTEMTOOLS_MYSQLDUMP initialisé à mariadb-dump ?
N’étant pas codeur, j’ai pensé à Configuration > Divers, mais l’erreur de sauvegarde planifiée perdure.
J’ajoute que, pour une sauvegarde manuelle (admin/tools/dolibarr_export.php), le Chemin complet vers la commande mysqldump est bien initialisé à mariadb-dump.
À toutes fins utiles, la portion du log de Dolibarr correspondant au lancement d’une sauvegarde planifiée.
2025-05-03 07:21:56 DEBUG <IP_address> 2281983 1228 Cronjob::run_jobs START Utils->dumpDatabase(gz,auto,1,auto,31,0,0); (Note: Log for cron jobs may be into a different log file)
2025-05-03 07:21:56 DEBUG <IP_address> 2281983 1228 Utils::dumpDatabase type=auto compression=gz file=auto
2025-05-03 07:21:56 INFO <IP_address> 2281983 1228 functions.lib::dol_mkdir: dir=/path/dolibarrdata/admin/backup
2025-05-03 07:21:56 DEBUG <IP_address> 2281983 1228 sql=SHOW VARIABLES LIKE 'basedir'
2025-05-03 07:21:56 INFO <IP_address> 2281983 1228 functions.lib::dol_mkdir: dir=/path/dolibarrdata/admin/backup
2025-05-03 07:21:56 INFO <IP_address> 2281983 1228 Utils::dumpDatabase execmethod=1 command:/usr/bin/mysqldump bd_name -h localhost -u bd_user -K --add-drop-table=TRUE --tables -c -e --hex-blob --default-character-set=utf8 --no-tablespaces -p"**********" 2>&1
2025-05-03 07:21:57 INFO <IP_address> 2281983 1228 dol_delete_file file=/path/dolibarrdata/admin/backup/mariadb-dump_bd_name_21.0.1_2505030921.sql.gz.err disableglob=1 nophperrors=0 nohook=0
2025-05-03 07:21:57 WARNING <IP_address> 2281983 1228 Failed to remove file /path/dolibarrdata/admin/backup/mariadb-dump_bd_name_21.0.1_2505030921.sql.gz.err
2025-05-03 07:21:57 INFO <IP_address> 2281983 1228 files.lib.php::dol_move srcfile=/path/dolibarrdata/admin/backup/mariadb-dump_bd_name_21.0.1_2505030921.sql.gz destfile=/path/dolibarrdata/admin/backup/mariadb-dump_bd_name_21.0.1_2505030921.sql.gz.err newmask=0 overwritifexists=1
2025-05-03 07:21:57 ERR <IP_address> 2281983 1228 Cronjob::run_jobs END result=-1 error=/usr/bin/mysqldump: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb-dump' instead
Alors c’est sûr, le job génère une sauvegarde « …err » qui a fait l’objet d’autres sujets, basedir vaut /usr/ (SHOW VARIABLES LIKE 'basedir'), et via SSH on peut voir que /usr/bin/mysqldump est un lien symbolique vers mariadb-dump.
Mais ma question concerne la variable SYSTEMTOOLS_MYSQLDUMP qui d’après le code dans utils.class.php devrait résoudre cette erreur très simplement.
bonjour,
Dans Configuration > Divers
Nouvelle constante
nom SYSTEMTOOLS_MYSQLDUMP
valeur /usr/bin/mariadb-dump
le chemin /usr/bin/mariadb-dump est a vérifier
Cela devrais régler le problème.
Explication du problème :
Lors d’une sauvegarde planifiée, Dolibarr utilise la constante globale SYSTEMTOOLS_MYSQLDUMP si elle existe ; sinon, il appelle une méthode pour « deviner » la commande (getPathOfDump()), souvent inadaptée si mysqldump est absent.
Ce très ancien sujet « SYSTEMTOOLS_MYSQLDUMP !! où est ce foutu paramètre » confirmerait que c’est bien dans llx_const (donc Configuration > Divers) mais non, ça ne change pas la commande de dump SQL utilisée pour la sauvegarde planifiée.
Sur cet hébergement (o2swicth), pour en dire un peu plus :
$ which mariadb-dump
/bin/mariadb-dump
$ ls -al /bin/mariadb-dump
-rwxr-xr-x 1 root root 5220200 30 janv. 19:33 /bin/mariadb-dump
La variable SYSTEMTOOLS_MYSQLDUMP est bien initialisée à /bin/mariadb-dump, mais c’est idem si je ne mets que mariadb-dump ou /usr/bin/mariadb-dump, le message d’erreur au lancement de la sauvegarde planifiée reste :
/usr/bin/mysqldump: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb-dump' instead
/**
* Return a Dolibarr global constant string value
*
* @param string $key Key to return value, return $default if not set
* @param string|int|float $default Value to return if not defined
* @return string Value returned
* @see getDolUserString()
*/
function getDolGlobalString($key, $default = '')
{
global $conf;
return (string) (isset($conf->global->$key) ? $conf->global->$key : $default);
}
Et donc si $conf->global->$key va bien chercher dans prefix_const (llx_const par défaut), ça devrait marcher non ?
Mais je viens de découvrir autre chose dans le champ dans « Outils > Sauvegarde manuelle » (admin/tools/dolibarr_export.php) est différent de la constante SYSTEMTOOLS_MYSQLDUMP. Le champ manuelle est stocké ailleurs et ne s’applique pas au cron.
Haaaaaaaaaaaaaaaaaaaaaaaa PAS de constante voilà pourquoi
Du moins c’est ce que je pense après un dev de Dolibarr pourrai faire une confirmation
admin/tools/dolibarr_export.php et gère les sauvegardes manuelles (pas celles des cronjobs). Le champ mysqldump du formulaire alimente dynamiquement SYSTEMTOOLS_MYSQLDUMP.
Les sauvegardes planifiées (via cron/card.php?id=6) n’ont pas de formulaire pour définir mysqldump, et donc elles ne mettent jamais à jour SYSTEMTOOLS_MYSQLDUMP dynamiquement.
Donc dans l’urgence mais pas propre htdocs/core/class/utils.class.php
$cmddump = getDolGlobalString('SYSTEMTOOLS_MYSQLDUMP');
if (empty($cmddump)) {
$cmddump = '/bin/mariadb-dump'; // Forçage si constante non initialisée ou mal lue
}
Cela permet de ne plus dépendre du comportement incertain dans les tâches cron.
Autrement un symlink au moins si mise a jour il y a de Dolibarr il n’y aura rien a refaire
sudo ln -s /bin/mariadb-dump /usr/bin/mysqldump
Toute commande mysqldump appellera en réalité mariadb-dump.
On peut se demander pourquoi ce message d’erreur de Dolibarr après lancement de la sauvegarde planifié, mais c’est un autre sujet, abordé par ailleurs. Car si message d’erreur rouge il y a, la sauvegarde est quand même faite ! et le dump porte le nom voulu + .err.
C’est adressé ailleurs, et ce n’est PAS ma question qui ne concerne que cette variable SYSTEMTOOLS_MYSQLDUMP.
