Travaux planifiés Dolibarr

Bonjour ,

Je suis actuellement en train de développer des travaux planifiés.
Lorsque je lance la tache manuellement elle fonctionne .
Le seul problème c’est dés que je la met en automatique elle n’exécute pas le code PHP est met une icone d’erreur en dessous de la date de la prochaine exécution .

Retard

Comment résoudre ce problème ?

Bonjour,
c’est probablement lié au fait qu’il n’y a pas de « cron » qui lance votre moteur de tâches planifiées … donc vérifiez la configuration du module Travaux planifiés Gestion des travaux planifiées (alias cron ou table chrono) et si besoin petite pub pour https://webcron.dolizen.fr/ (mais il en existe d’autres).

1 « J'aime »

J’ai taper la ligne de commande ci dessous sur mon hébergeur sous linux (j’ai remplacer la clé par XXXX)
crontab -e

*/5 * * * * /pathtoscript/scripts/cron/cron_run_jobs.php XXXXXXXXXX Admin > /kunden/homepages/44/d568860549/htdocs/dolibarr_demo/documents/cron_run_jobs.php.log

faut il obligatoirement passer par un website « cron » ?
je possède déjà un module cron

Vous devez remplacer pathtoscript par le chemin d’accès au script sur votre serveur

1 « J'aime »

Merci beaucoup !

Non, le « webcron » n’est qu’un palliatif lorsqu’il n’est pas possible d’aller configurer le cron normal en ligne de commande !

@pascal_z merci :slight_smile:

Bonjour, je me permets de relancer le sujet.

Dans la liste des urls j’ai cette url :

https://xxxxxxxxxxxx.fr/public/cron/cron_run_jobs_by_url.php?securitykey=FOO93NSxxxxxxxxxxxmsb3U&userlogin=totouser9&id=cronjobid

Avec en bout « cronjobid » , si je comprends bien ce « cronjobid » est l’identifiant de la tâche numérotée, 6 pour la sauvegarde

Donc logiquement, pour exécuter la sauvegarde (numérotée 6) :

https://xxxxxxxxxxxx.fr/public/cron/cron_run_jobs_by_url.php?securitykey=FOO93NSxxxxxxxxxxxmsb3U&userlogin=totouser&id=6

En tapant cette url dans le navigateur, rien ne se passe. Result: No active jobs found. Alors que la tâche est bien planifiée.

Impossible non plus de lancer la commande depuis mon hébergeur

/pathtoscript/scripts/cron/cron_run_jobs.php FOO93Nxxxxxxxxxxxxxxxnmsb3U totouser [6]

Dans mon installation cron_run_jobs.php est dans le dossier :

/xxxxxxxx.fr/public/cron/cron_run_jobs.php

Est ce que quelqu’un peut m’éclairer là dessus ?

Merci

Bonjour,

Les taches ont une occurrence de définie :
image

Ce n’est pas normal, dans public il doit y avoir que cron_run_jobs_url.php et pas cron_run_jobs.php

Merci pour ta réponse ksar.

Je gère plusieurs installations. Dans l’une, le dossier public contient bien tout cela :

Dans les autres il n’y a que cron_run_jobs_url.php en effet, des installations différentes à des versions anciennes (14 ou 15 ) Je supporse que je dois déplacer le dossier cron_run_jobs.php dans son emplacement correct ?

La toute dernière version installée (A partir de la 18), MySQL Dump (mysqldump) ne se lance pas c’est MySQL Dump (php) qui est apparemment exécuté (Le fichier est plus gros, non zippé) cela serait il possible de cibler ce type d’export, car les sauvegardes MySQL Dump (mysqldump) sont bien.

Merci

Votre fichier cron_run_jobs.php date de 2020, vous avez un fichier index.html de 2021, et les autres fichiers datent de 2023.
Vous avez de toute évidence des mises à jour qui ont été mal faites.

Regardez le code sur github, il n’y a que deux fichiers pour la version 18 dans le répertoire public/cron

il faut remonter à la version 13 pour voir le fichier cron_run_jobs.php dans ce répertoire, mais il n’y a pas alors l’autre fichier

Donc vous avez une mise à jour mal faite à partir de la version 13, ce qui laisse supposer que vous avez potentiellement d’autres « mauvais » fichiers qui trainent dans les autres répertoires.

Merci, c’est bien ce que je pensais, je vais refaire une installation manuelle et reprendre la base de données.

Bonjour,

J’ai refait les installations (manuel via l’install de Dolibarr) et remis en place les modules qui vont bien.

L’installation de base, pour info, était faite avec Softaculous de chez O2switch, je déconseille, nous avions déjà eu des soucis avec des Prestashop, mieux vaut faire l’installation en manuel.

Je vais faire un résumé sur ce qui a été fait (Cela pourra servir à d’autres) : car on ne peut pas totalement compter sur les sauvegardes des hébergeurs.

Il y a une tâche cron (serveur) qui s’exécute dans la nuit de ce type :

wget -O /dev/null « URL » >/dev/null 2>&1

URL étant l’URL que vous trouvez au niveau du réglage de votre module (Page de configuration du module - Gestion des travaux programmés)

Vérifiez que l’URL est bien en https (Sur une installation en 17 elle reste en http)

Si vous voulez exécuter une tache en lançant un fichier PHP il faudra utiliser la syntaxe suivante :

/opt/alt/php74/usr/bin/php /cron.php (Il faudra modifier le binaire PHP de la commande par la version de PHP que vous utilisez sur votre hébergement).

Ces infos m’ont été fournies par la hot line d’O2switch, toujours très compétente et réactive, je tiens à le préciser (Ce qui est loin d’être le cas chez tous les hébergeurs, hélas).

Perso, pour faire simple j’ai utilisé : wget -O /dev/null « URL » >/dev/null 2>&1

Ceci lance un « travail planifié » (Dolibarr) qui est également programmée pour s’exécuter à une heure particulière…

Exemple : si le « travail planifié » est prévu pour être lancé à 01 h 00 alors prévoyez le cron à 02 h 30 par exemple, vous êtes certain que « travail planifié » « attendra » d’être exécuté, sinon votre tache cron se lancera mais rien ne se passera (Sans vous donner d’erreur).

Pour ma part, je ne mettrai pas de tâches cron sur des services externes, qui plus est payants… encore une cb qui se ballade…

Il me reste a résoudre, afin de sauvegarder une base qui est assez volumineuse, qui génère une erreur SQL (?) 1.4 Go, le travail est long ceci peut dépasser le temps imparti par le serveur d’exécution de scripts.

Le dernier problème restant à résoudre est de faire en sorte que la sauvegarde soit zippée (Ce qui n’est pas le cas des sauvegardes avec les méthodes décrites) .

Espérant avoir été clair et utile, à vos remarques.

1 « J'aime »

Raison pour laquelle nous avons mis en place https://webcron.dolizen.fr/ gratuit et porté par un partenaire officiel dolibarr :slight_smile:

Merci erics, oui cela peut être très utile pour certains.

Oui j’avais déjà vu, mais il affiche ceci ?
→ Composer detected issues in your platform: Your Composer dependencies require a PHP version « >= 8.0.2 ».

Pour ma part les sauvegardes des bases de données sont faites en utilisant restic avec rclone, et en déclenchant un mysqldump juste avant de lancer le backup avec restic.

La configuration sous NixOS est la suivante

    services = {
      mysql = {
        enable = true;
        package = pkgs.mariadb;
        settings = {
          "mysqld" = {
            "bind-address" = "127.0.0.1";
            "port" = 3306;
            sql_mode = "";
          };
        };
        ensureUsers = [{
          name = "restic";
          ensurePermissions = {
            "*.*" = "SELECT, SHOW VIEW, TRIGGER, LOCK TABLES, EVENT";
            # https://forums.mysql.com/read.php?10,668311,668315#msg-668315
            "function sys.extract_table_from_file_name" = "execute";
            "function sys.format_path" = "execute";
            "function sys.format_statement" = "execute";
            "function sys.extract_schema_from_file_name" = "execute";
            "function sys.ps_thread_account" = "execute";
            "function sys.format_time" = "execute";
            "function sys.format_bytes" = "execute";
          };
        }];
      };
      restic = {
        backups = {
          mysql = {
            user = "restic";
            repository = "rclone:ovh:restic.${hostName}.${bucketHash}/mysql";
            initialize = true;
            passwordFile = config.age.secrets."restic.pwd".path;
            rcloneConfigFile = config.age.secrets."rclone.conf".path;
            paths = [ "${cfg.location}" ];
            backupPrepareCommand = ''
              for DB in $(${mariadb}/bin/mysql -e 'SHOW DATABASES WHERE `Database` NOT IN ("information_schema","sys","performance_schema","mysql")' -s --skip-column-names); do
                  dest="${cfg.location}/$DB-$(date +%Y-%m-%d-%H-%M-%S).gz"
                  if ${mariadb}/bin/mysqldump --single-transaction --routines --triggers $DB | ${gzip}/bin/gzip -c > $dest.tmp; then
                      mv $dest.tmp $dest
                  else
                      echo "Failed to back up to $dest"
                      rm -f $dest.tmp
                      failed="$failed $DB"
                  fi
              done
            '';
            # Suppression des dumps de plus de 24h
            backupCleanupCommand = ''
              find ${cfg.location} -type f -name '*.gz' -mmin +1440 -delete;
            '';
            pruneOpts = [ "--keep-last 7" ];
            timerConfig = {
              OnCalendar = "*-*-* *:00:00";
              Persistent = true;
              RandomizedDelaySec = "10min";
            };
          };
        };
      };
    };

Un user restic est spécialement créé avec juste les droits nécessaires pour faire le backup.
Dans la config du backupPrepareCommand il y a le mysqldump avec compression gzip dans la foulée.