Jeedom 4.5 - un manque de logs après le passage du crondaily

Nemeraud · Avril 5, 2026, 8:01

Bonjour

Suite à ce poste, j’avais réglé le souci de mon log qui était tromqué mais depuis la maj 4.5.3 le problème semble revenu, je me retrouve avec mon log qui commence à 1h15 du jour en cours alors que j’ai habituellement +48H de log

Cette version ne devait pas corriger ce point ?

Bon we de Pâques à tous.

jpty · Avril 5, 2026, 8:07

Bonjour,

Oui, elle devait corriger mais aucun PR n’a été fait.
Entre temps le « tronquage » des logs a été aussi modifié dans la 4.5.3 pour être fait chaque heure s’ils dépassent une certaine taille. Il faut que la fonction de ce post soit réadaptée ( ou pas ? ).

Nemeraud · Avril 5, 2026, 8:15

Merci pour ton retour

C’est pourtant un problème qui est pourtant très chiant, j’avais besoin de mes logs de cette nuit pour comprendre un problème.

On va attendre les infos des spécialistes

jpty · Avril 5, 2026, 8:25

Vous pouvez aussi essayer de remettre le code de ce post Jeedom 4.5 - un manque de logs après le passage du crondaily - #34 par jpty
Il fonctionne encore.
L’adaptation à faire concerne la taille max qui est fixe en 4.5.2 (10M) et paramétrable dans la 4.5.3

Nemeraud · Avril 5, 2026, 8:28

Merci, je vais remettre le code

Xav-74 · Avril 5, 2026, 8:28

Je l’ai re modifié également suite à mon passage en 4.5.3. RAS depuis

Bison · Avril 5, 2026, 10:31

Hello,

Ce n’est malheuresement pas un sujet très prioritaire puisque ça n’a visiblement pas l’air de toucher grand monde d’après Loïc, j’ai pas encore compris pourquoi

tomitomas · Avril 5, 2026, 12:20

perso ca m’a plus d’une fois mis mon install a plat …

la rotation des logs ne se fait pas correctement

le fichier qui est censé être supprimé ne l est pas, le plugin continue de voir et d ecrire dans « l ancien » fichier de log (qui n est plus visibleme sur l interface jeedom) mais qui grossit, grossit, grossit… jusqu a atteindre la capacité max du disque et tout faire planter …

cote IHM

côté serveur :

[16:59:27] tomtom@JeedomProdD12: ~  $ sudo lsof -nP 2>/dev/null | grep deleted | awk '{size[$(NF-1)]+=$7} END {for (file in size) printf "%.2f GB\t%s\n", size[file]/(1024*1024*1024), file}' | sort -rh
8.59 GB /var/www/html/log/MQTTDiscovery_daemon
5.75 GB /var/www/html/log/unifi_deamon
1.25 GB /var/www/html/log/jMQTTd

la prochaine fois je compterai le nb de lignes qu il y a dans les fichiers, on doit etre pas mal aussi …

Bison · Avril 5, 2026, 12:23

Tu veux dire avec le code de la 4.5.2 ou avec le code qui avait été refait et proposé par jpty ?

tomitomas · Avril 5, 2026, 12:26

avec le code standard qui « ne touche pas grand monde » …

je vais voir ce que donne le code de jpty

jpty · Avril 5, 2026, 1:17

Bonjour,

Il faudra au moins relancer les daemons pour que les fichiers marqués deleted se supprime et que le daemon retrouve un log visible.
Comme il n’arrive pas à tronquer le fichier, il est passé par la suppression du fichier.

github.com

jeedom/core/blob/b5e67585c4dd6a89d874b4fc8c94a9269d06dc90/core/class/log.class.php#L179


      
          		}
          		@chown($_path, system::get('www-uid'));
          		@chgrp($_path, system::get('www-gid'));
          		if (filesize($_path) > (1024 * 1024 * 10)) {
          			com_shell::execute(system::getCmdSudo() . 'truncate -s 0 ' . $_path);
          		}
          		if (filesize($_path) > (1024 * 1024 * 10)) {
          			com_shell::execute(system::getCmdSudo() . 'cat /dev/null > ' . $_path);
          		}
          		if (filesize($_path) > (1024 * 1024 * 10)) {
          			com_shell::execute(system::getCmdSudo() . ' rm -f ' . $_path);
          		}
          	}
          
          	public static function getPathToLog($_log = 'core') {
          		return __DIR__ . '/../../log/' . $_log;
          	}
          
          	/**
          	 * Check authorisation to emptying log file
          	 */

Dans ce cas le fichier n’est plus visible, et le daemon continue à le remplir. Il ne sera jamais tronqué.

Vérifiez aussi que l’ouverture du fichier de log est faite en O_APPEND ( Ecriture toujours à la fin du fichier quelque soit l’endroit de l’écriture précédente ).
Le lancement du daemon avec daemon >> logdaemond fait l’ouverture correctement. Le fichier peut être tronqué. Le daemon écrira toujours à la fin du fichier.

Je viens de tester le tronquage sur le log de jMQTT. En debug, il y a beaucoup de trafic. Le log est passé de +65000 à 2000 lignes et le daemon écrit encore dans le fichier.

jpty · Avril 5, 2026, 2:31

Version adaptée pour le paramètre maxSizeLog de la 4.5.3
Modif compatible avec la 4.5.2

Voir Jeedom 4.5 - un manque de logs après le passage du crondaily - #59 par jpty

jpty · Avril 5, 2026, 3:03

J’ai ajouté une issue ICI pour qu’il y ait une trace.

Nemeraud · Avril 6, 2026, 6:17

Bonjour

Mes logs sont OK ce matin avec la version précédente de ta fonction, je viens de la mettre à jour avec la nouvelle version, merci @jpty

Mips · Avril 6, 2026, 6:53

Pourquoi ne fais-tu pas un PR?

jpty · Avril 6, 2026, 3:51

Bonjour,

Je ne fais plus de PR. Je ne maitrise pas la façon de programmer Jeedom.
Exemple dans ce cas: Pas de variable $sudo mais des appels multiples de system::getCmdSudo() Expérience vécue sur un PR de plugin-weather

Le code ci-dessus est une proposition que Jeedom adaptera au besoin.

Bison · Avril 13, 2026, 1:57

Hello,

J’ai mis à jour Jeedom hier en 4.5.3 puis utilisé cette version. Ce matin j’ai eu une erreur

Caught exception in chunkLog(): Erreur sur sudo tail -c 5M /var/www/html/core/class/../../log/Diagramme relationnel | tail -n 10000 > /tmp/jeedom/log.tmp && sudo cat /tmp/jeedom/log.tmp > /var/www/html/core/class/../../log/Diagramme relationnel 2>&1 valeur retournée : 1. Détails :

Un problème avec les noms de logs avec des espaces je pense ?

jpty · Avril 13, 2026, 2:07

Hi,

Oui, c’est un pb avec les espaces.
L’ID du plugin doit être utilisé pour les noms de log. Ca devrait être diagrelationnel

J’ai fait un grep sur ton plugin en beta. Il n’y a pas de log::add("Diagramme....

jpty · Avril 13, 2026, 2:59

Petite correction pour les noms de fichier log avec espace:

  public static function chunkLog($_path) {
    if (strpos($_path, '.htaccess') !== false) {
      return;
    }
    $maxLineLog = self::getConfig('maxLineLog');
    if ($maxLineLog < self::DEFAULT_MAX_LINE) {
      $maxLineLog = self::DEFAULT_MAX_LINE;
    }
    $sudo = system::getCmdSudo();
    $ftmp = jeedom::getTmpFolder() .'/log.tmp';
    $maxSizeLog = self::getConfig('maxSizeLog', '10');
    $path = escapeshellarg($_path);
    try {
      com_shell::execute("$sudo tail -c {$maxSizeLog}M $path | tail -n $maxLineLog > $ftmp && $sudo cat $ftmp > $path");
    } catch (\Exception $e) {
      message::add(__CLASS__, "Caught exception in " .__FUNCTION__ ."(): " .$e->getMessage());
    } finally {
      com_shell::execute("$sudo rm -f $ftmp");
    }
  }

Comme toi, j’avais mis à jour en 4.5.3 hier mais en oubliant la correction de chunkLog()
Résultat:
Une 20aine de lignes dans cron_execution

sh: 1: sudo: Argument list too long

et des fichiers supprimés mais encore utilisés

[2026-04-13 10:17:46][SCENARIO] LSOF:
[2026-04-13 10:17:46][SCENARIO] 588.44 MB	/usr/bin/node
[2026-04-13 10:17:46][SCENARIO] 187.76 MB	/var/www/html/log/mqtt2d
[2026-04-13 10:17:46][SCENARIO] 47.37 MB	/var/www/html/log/jMQTTd

Pour /usr/bin/node c’est normal. J’avais fait aussi un apt upgrade qui a MAJ node. Ca sera résolu au prochain reboot ou à l’arrêt des daemons node.
Pour les 2 logs de daemon, vu leur taille, la fin du tronquage des fichiers ne doit pas dater d’hier. Le pb semble subsister. J’ai mis en surveillance la création des lsof dans le scénario qui surveille les logs.

Bloc code surveillance lsof:

// liste des fichiers ouverts et supprimés
$cmd = 'sudo lsof -nP 2>/dev/null | grep deleted | awk \'{size[$(NF-1)]+=$7} END {for (file in size) printf "%.2f MB\t%s\n", size[file]/(1024*1024), file}\' | sort -rh';
exec($cmd, $output, $retval);
if(count($output)) {
  $scenario->setLog("LSOF:");
  foreach($output as $l) {
    $size = floatval($l);
    if ($size > 10)
      $scenario->setLog("$l");
  }
}

Bison · Avril 13, 2026, 3:41

J’ai codé en utilisant log::add(__CLASS__, 'debug',...)

J’ai vérifié dans le répertoire et j’ai un fichier « Diagramme relationnel » qui ne devrait pas être là …