Crash install 4.3

Bonjour,
Il m’a été demandé de faire une maj système en 4.3.
Malheureusement, lors de l’installation le process a crashé, du coup, tout à réinstaller.
Suis-je le seul à avoir constater ce phénomène .?
Merci
Ma config DIY intel I5

edit : Je test également update

non, il m’a proposé de l’installer en bêta

1 « J'aime »

Loic avait prévenu
https://community.jeedom.com/t/core-4-3-beta/89558?u=kaktusatomik

2 « J'aime »

J’ai lancé update je crains aussi avoir un crash a l’installation, c’est bloqué a 55% :

Cleaning folders | OK
Create temporary folder | OK
Unzip in progress | OK
Clean temporary files (tmp) | OK
Disable all task
kill: (11058): No such process
. | OK
Disable all scenario | OK
Moving filesIgnore file /tmp/jeedom_unzip/core-beta///docs/de_DE/noteVersion.md because size is 0
Ignore file /tmp/jeedom_unzip/core-beta///docs/en_US/noteVersion.md because size is 0
Ignore file /tmp/jeedom_unzip/core-beta///docs/es_ES/noteVersion.md because size is 0
Ignore file /tmp/jeedom_unzip/core-beta///docs/fr_FR/noteVersion.md because size is 0
Ignore file /tmp/jeedom_unzip/core-beta///docs/pt_PT/noteVersion.md because size is 0 | OK
Remove temporary files | OK
Remove useless files
Cleaning 3rdparty
Cleaning desktop
Cleaning mobile
Cleaning core
Cleaning docs
Cleaning install
Cleaning script
find: '/var/www/html/install//script/*': No such file or directory
Cleaning vendor
Update system into : 4.3.0warning: commands will be executed using /bin/sh
job 15 at Mon Aug 29 20:40:00 2022
Ensure Content-Security-Policy (Report-Only) is enabled in apache | OK
Check jeedom consistency
[START CONSISTENCY]

J’ai relancé la mise a jours et elle est bien passé !! pas de problème finalement pour moi

1 « J'aime »

Bonsoir,
vu que l’alpha est passé en Béta, a voir si ce post n’est pas similaire :
https://community.jeedom.com/t/alpha-mise-a-jour-bloque/58948

Non, je n’ai pas ce plugin

Bonsoir @mich0111, j’ai moi aussi fait la mise à jour ce soir et mon jeedom s’est aussi planté.
Grrr… J’ai relancé la mise à jour en ssh. Ca ne s’est pas planté mais jeedom ne se lance pas.

Bonsoir,
Je n’ai pas voulu insister, réinstallation complète.

par contre pendant le premier crash, j’avais toujours jeedom accessible. j’ai pu relancé l’installation depuis le centre de mise à jours

Dis-toi bien que tu as eu de la chance.

Oui tu as eu de la chance car moi je n’ai plus d’accès à jeedom. J’ai relancé la mise à jour en ssh. C’est bien passé mais jeedom ne marche pas. J’ai restauré la dernière sauvegarde effectué juste avant la mise à jour et c’est toujours pareil pas d’accès…

Il me semble que le serveur Apache est dans les choux.
Si c’est le cas, soit tu arrives à le restaurer et tu es fort, soit réinstallation complète.

A moins d’avoir de l’aide, j’ai bien peur que ça dépasse mes compétences… C’est bizarre qu’on soit pas plus a être plante quand même…

Même soucis chez moi, crash et plus accès au jeedoms (sur pi3 et pi4).
Comment relancer en ssh?
Merci pour votre aide.

Pour info, testé sur une VM, lors tu passage stable → Beta, j’ai le même soucis.
blocage a 55%, mais Jeedom toujours accessible.

Cleaning vendor
Update system into : 4.3.0warning: commands will be executed using /bin/sh
job 3 at Tue Aug 30 00:32:00 2022
Ensure Content-Security-Policy (Report-Only) is enabled in apache | OK
Check jeedom consistency
[START CONSISTENCY]
[START CHECK AND FIX DB]
[END CHECK AND FIX DB]
Check jeedom package

Mes log s’arrêtent durant la vérification des packages !

Edit :
j’ai relancé aussi l’update, celle-ci c’est conclu par un succès, seul chose que j’ai remarqué c’est qu’il y avait 2 popup de confirmation (l’une sur l’autre) :

image

Edit2 :
Pour la team Jeedom
dans les log lors de la 2ème exécution j’ai remarqué que
"Update system into : " . $nextVersion . "..." n’était pas présent, j’en déduit que lors de la 1ère update :
config::save('version', $curentVersion); a bien update en 4.3.0 et donc lors de la 2eme update le fichier update/4.3.0.php n’est pas éxecuté.
je me demande donc si il n’y aurait pas un soucis avec le fichier update/4.3.0.php
je ne suis pas très calé dans ce langage mais
shell_exec('echo "systemctl restart apache2" | sudo at now'); ça redémarre apache ? ça pose pas de problème pour la suite de l’update ?

Bonne soirée.

C’est moi qui ai fait le script 4.3.0.php.
En effet, j’ai peut être été un peu agressif sur le redémarrage d’apache en plein update… Juste recharger la conf devrait être suffisant.

Il me semblait avoir vu un reload d’apache dans des scripts précédents, mais je ne le retrouve pas. Je vais PR pour fix dès ce matin.

EDIT: Juste pour être sûr, quel sont les derniers messages que vous avez dans le log http.error ?

2 « J'aime »

La 4.3 n’est pas une version stable.
C’est bien pour cela qu’il ne faut pas installer une version bêta sans savoir

Bonjour à tous,
Je viens de lancer l’install en ssh… update ok sur rpi3 et rpi4 mais pas de web… apache en vrac:

[Mon Aug 29 23:19:20.244233 2022] [core:notice] [pid 589] AH00052: child pid 18548 exit signal Segmentation fault (11)
[Mon Aug 29 23:19:20.509212 2022] [core:notice] [pid 589] AH00052: child pid 12947 exit signal Segmentation fault (11)
[Mon Aug 29 23:19:20.509746 2022] [core:notice] [pid 589] AH00052: child pid 24563 exit signal Segmentation fault (11)
[Mon Aug 29 23:19:20.510681 2022] [mpm_prefork:notice] [pid 589] AH00169: caught SIGTERM, shutting down

aussi à la relance du service apache2:

root@rpi4:~# systemctl restart apache2.service
Warning: The unit file, source configuration file or drop-ins of apache2.service changed on disk. Run 'systemctl daemon-reload' to reload units.
Job for apache2.service failed because the control process exited with error code.

resultat du status:

root@rpi4:~# systemctl status apache2.service
Warning: The unit file, source configuration file or drop-ins of apache2.service changed on disk. Run 'systemctl daemon-reload' t
● apache2.service - The Apache HTTP Server
   Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
  Drop-In: /lib/systemd/system/apache2.service.d
           └─override.conf
           /etc/systemd/system/apache2.service.d
           └─privatetmp.conf
   Active: activating (auto-restart) (Result: exit-code) since Tue 2022-08-30 08:55:53 CEST; 9s ago
     Docs: https://httpd.apache.org/docs/2.4/
  Process: 14937 ExecStart=/usr/sbin/apachectl start (code=exited, status=1/FAILURE)

en enfin le journal:

root@rpi4:~# journalctl -xe
-- Subject: Unit process exited
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- An ExecStart= process belonging to unit apache2.service has exited.
--
-- The process' exit code is 'exited' and its exit status is 1.
Aug 30 08:57:25 rpi4 systemd[1]: apache2.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- The unit apache2.service has entered the 'failed' state with result 'exit-code'.
Aug 30 08:57:25 rpi4 systemd[1]: Failed to start The Apache HTTP Server.
-- Subject: A start job for unit apache2.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A start job for unit apache2.service has finished with a failure.
--
-- The job identifier is 203003 and the job result is failed.

J’éspère que ces infos sont utiles.

OK, je viens de tester plus profondément et le problème vient bien de mon script 4.3.0.php

Contrairement à ce que j’ai pu croire en regardant rapidement les sources et les process en cours d’execution pour faire mon script, ni jeedom::update(), ni system::php() ne décroche pas complètement le processus d’update d’Apache (bien quelle tourne en tache de fond).

Pour corriger, il ne faudrait pas utiliser & pour lancer le sous-process, mais faire executer php par le daemon at avec une commande type 'php <update.php> <params>' | at now, mais la fonction jeedom::update() de la version n-1 qui est utilisé pour monter dans la version n…

Donc avec le script d’update actuel, il n’y a aucun moyen de redémarrer ou recharger la configuration d’Apache sans couper l’install, de fait, je vais simplement supprimer la ligne qui pose problème et la config sera appliquée lors du prochain reboot/restart d’apache.

Je vais donc proposer un patch sur les 2, indépendamment.

3 « J'aime »