Suite à une mise à jour de Debian de Jessie vers Stretch, je pensais avoir résolu tous les problèmes mais j’en ai eu un nouveau ce matin, que je ne sais pas trop comment aborder.
Les faits :
Plus de réponse de Jeedom au niveau interface
le serveur tourne toujours (je peux me connecter dessus)
le health.sh est OK
syslog ne montre rien de spécial (ou je n’ai rien trouvé)
beaucoup de sql dans l’arborescence htop
Au final je décide de redémarrer le service apache2. Et toute l’interface revient.
Le log http m’apprend que (apache) « server reached MaxRequestWorkers setting » cette nuit. Bien sûr il y a d’autres erreurs ailleurs, mais ça semble plutôt lié aux plugins qui n’arrivent plus à communiquer correctement avec le core.
Quelqu’un peut-il m’aider sur cette erreur ? Faut il refaire une customisation des paramètres après mise à jour de l’OS (j’ai bien gardé tous les paramètres custom à chaque fois que la question m’a été posée) ?
Où dois-je chercher pour résoudre ce problème ?
Regarde si le script d’install jeedom a bouger pour la partie apache. Normalement Loïc l’a tester sur buster maintenant.
Et en passant en buster, les versions logiciels changent, potentiellement avec de nouveaux paramètres (ou pas, pour ça d’abord regarde le script install ce qu’il fait en custo et si t’as bien tout)
Il semble que tous les paramètres de custo du php ne soient pas appliqués sur mon install… par exemple, je n’ai pas la bonne valeur de « memory_limit » (128M au lieu de 256M).
Est-ce que je peux créer un script qui ne reprend que l’étape 7 du script d’install de Jeedom (customisation) sur une install existante sans risquer de tout détruire ?
Car je ne comprends pas très bien ce que fait la première partie où on vient modifier des fichiers de config de Apache ; notamment ce genre d’instruction :
sed -i -e "s%WEBSERVER_HOME%${WEBSERVER_HOME}%g" /etc/apache2/sites-available/000-default.conf
(qui d’après google est censée me donner le nombre de connexions actives) je n’obtiens que 4 lignes en réponse.
Autre chose, j’ai le problème suivant dans les logs après un redémarrage :
2020-01-22 10:27:02 starting Jeedom rm: impossible de supprimer '/tmp/jeedom/cache': Le dossier n'est pas vide
mkdir: impossible de créer le répertoire « /tmp/jeedom/cache »: Le fichier existe
Salut,
Oui je veux bien mais je sais pas faire ça !
Est ce que c’est dû à ça que le fichier log se remplis de vide (des retours à la ligne)?
Voici le début de mon fichier ensuite que du vide.
PHP Warning: Error while sending QUERY packet. PID=18010 in /var/www/html/core/class/DB.class.php on line 84
2020-11-30 18:04:14 starting Jeedom rm: impossible de supprimer '/tmp/jeedom/cache': Le dossier n'est pas vide
mkdir: impossible de créer le répertoire « /tmp/jeedom/cache »: Le fichier existe
Enable scenario : OK
Enable task : OK
Rhooo… Pourtant on en parle souvent…
Je suis de bonne humeur donc en ssh :
sudo chown -R www-data:www-data /tmp/jeedom
Non pas besoin d’aller si loin, l’erreur est indiquée en caractères visibles dans ce que tu cites… Et si c’est juste de l’anglais donc au pire un petit coup de traduction quand on coince ça éclaire la situation… Mais là c’est traduit
Donc pour ce deuxième souci : Le mieux c’est d’ouvrir un nouveau sujet car ça n’a pas de rapport avec la précédente discussion.
Et puis comme d’habitude, il va falloir donner les informations qui vont bien et les circonstances qui amène à ce message. Particulièrement le fait que ça ressemble à un message en relation avec le backup… Et je vois pas le lien avec un redémarrage de jeedom
j’ai deja ouvert un sujet sur l’origine du probleme ici Message cron_execution
j’ai reussi a ne plus avoir l’erreur en supprimant le plugin qui avait l’air de poser problème et depuis c’est le fichier qui se rempli de cette facon.
Je vais refaire un autre sujet alors.
Je te remercie
