Jeedom 4.5 - un manque de logs dans les scénarios

Utilisation du core de Jeedom Scénarios
21

Bonjour,

Pas de souci de log ce matin.

  • Les logs de taille 0 reste à 0. Avec echo, il y a un caractère \0 qui s’ajoutait dans ces fichiers.
  • Les logs sont bien tronqués à 5000 lignes.

Ca pourrait encore être plus optimisé en combinant les options -n 5000 et -c10M de la commande tail. Ne fonctionne pas les options n et c sont exclusives.
Le tronquage n’est de toute façon pas toujours propre à cause des daemons qui tournent pendant que les fichiers de log sont tronqués.

22

Hello,

Je vais essayer ça aussi et je pense que l’on pourra proposer une PR ensuite

23

Hello @jpty,

C’est bon aussi chez moi avec ton code :+1:

L’équipe Jeedom on fait quoi du coup avec ce constat ? @Loic ? @Aurelien ?

1 « J'aime »
24

Bonjour,
Comme toujours nous avons bien pris le point et nous allons voir pour améliorer ce systeme mais vu qu’il est en place depuis plusieurs mois ce n’est pour le moment pas une urgence (le soucis arrivant chez très peu d’utilisateur).

Edit : ne pas oublier que vous pouvez proposer des PR pour accelerer les choses.

1 « J'aime »
25

Bonjour Loic,

OK merci de l’avoir indiqué, je n’avais pas vu de réaction de l’équipe donc je ne pouvais pas savoir que vous aviez pris le point :slight_smile:

Oui je sais que l’on peut faire une PR et c’était bien l’idée de ma sollicitation et de savoir ce que vous pensiez du code proposé par @jpty histoire d’avoir déjà une validation rapide et que l’on ne fasse pas de PR pour rien et encore moins si le point est déjà pris

26

Son code marche mais il va générer pas mal d’écriture disque (a l’inverse du traitement en mémoire) et donc réduira la durée de vie sur les systeme type rpi (sur carte SD) c’est pour ca qu’on avait choisi de pas faire cette méthode.

On va donc y réfléchir et voir ce qui est le mieux.

2 « J'aime »
27

Bonjour,

Dans tous les cas, il faut au moins supprimer le sudo (comme en 4.4) qui pose des pbs avec la taille de la ligne de commande.
La solution serait peut-être de créer le fichier intermédiaire en RAM dans un tmpfs comme /tmp/jeedom

28

Hello,

J’ai continué à réfléchir au sujet en partant de la proposition de jpty et de la contrainte des écritures sur les cartes SD.

Moi j’en suis là pour le moment :

        $sudo = system::getCmdSudo();
    	$uid = system::get('www-uid');
    	$gid = system::get('www-gid');
		try {
          	com_shell::execute("$sudo sh -c 'tail -n $maxLineLog $_path > $_path.tmp && mv $_path.tmp $_path && chown $uid:$gid $_path && chmod 664 $_path'");
		} catch (\Exception $e) {
		}

sh -c execute dans un shell root
tail lit le fichier et l’écrit dans un fichier temporaire sans charger quoi que ce soit en mémoire
mv remplace l’ancien fichier par le nouveau en modifiant le pointeur dans le système de fichiers ce qui sollicite vraiment très peu le disque

Du coup je pense que l’on ne sollicite pas plus le disque (ou la carte SD) qu’avec echo qui va charger en mémoire puis écrire d’un coup le résultat dans le fichier

L’avantage c’est que si la commande tail échoue pour une raison ou une autre, le fichier source ne sera pas écrasé

J’ai mis les chmod et chown à la fin parce que je ne comprends pas vraiment ce qu’il font en début de commandes. Vu que l’on exécute en root, il ne doit pas y avoir de problème de permission et ici owner/group sera cassés

Maintenant concrètement le chown ne devrait pas servir vu les 2 commandes après le try/catch

Je regarde encore demain matin ce que ça donne et je proposerais une PR sur la branche alpha

29

Avec mv, les daemons qui écrivait dans le fichier $_path à l’inode XXXX n’écriront jamais dans l’inode YYYY du nouveau fichier $_path créé par mv. Il faudrait relancer les daemons pour que le changement d’inode soit pris en compte.
Il faut faire cat $_path.tmp > $_path && rm $_path.tmp
En marche normale, les chown et chmod ne servent à rien. Il y a d’autres taches cron qui le font.

La fonction chunkLog avec :

  • le fichier intermédiaire dans le tmpfs de jeedom avec un nom fixe
  • le tronquage des fichiers à 10M puis à $maxLineLog lignes
  • la préservation de l’inode du fichier $_path pour les daemons
  • le tail étant exécuté en root, les chmod et chown ne sont pas utiles
  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';
	try {
		com_shell::execute("$sudo tail -c 10M $_path | tail -n $maxLineLog > $ftmp && cat $ftmp > $_path  && rm $ftmp");
	} catch (\Exception $e) {
	}
    // $uid = system::get('www-uid');
    // $gid = system::get('www-gid');
    // Eventuellement ???? 
    // @chown($_path, $uid); @chgrp($_path, $gid);
    // ou plutot pour avoir les privilèges root
    // com_shell::execute("$sudo chmod 664 $_path > /dev/null 2>&1; $sudo chown $uid:$gid $_path > /dev/null 2>&1");
  }
30

Le but était de prendre en compte la remarque de Loïc concernant les cartes SD.

Concernant ta remarque, concrètement, si un plugin a un démon, suite au mv il n’y aurait plus de nouvelles lignes de logs dans le fichier de log du démon ?

31

Oui exactement. mv crée un fichier avec un inode différent inconnu du daemon existant.
J’ai ajouté du code dans mon dernier post.
Le fichier intermédiaire est créé dans un tmpfs en RAM sans écriture sur la carte SD.
Il n’y a pas plus d’écriture sur la SD qu’avant

1 « J'aime »