Domoticz Offline malgrés service OK

[Chrominator]

je voulais dire 100% utilisé, 0 disponible.

[tonejay]

BOn je tourne toujours sur ce probleme...je ne trouve pas de solution..pas de probleme de FS...une autre piste ?

[lost]

BOn je tourne toujours sur ce probleme...je ne trouve pas de solution..pas de probleme de FS...une autre piste ?

Pour ma part, cela arrive environ une fois par mois: Service OK donc pas de redémarrage auto via systemd... mais pas de connection http possible!
Un script lancé par un cron toutes les 30mn check (via httping) que le serveur web de Domoticz est OK et rédémarre le PI si c'est pas le cas après 60s de pause et 1 retry toujours KO.

[tonejay]

BOn je tourne toujours sur ce probleme...je ne trouve pas de solution..pas de probleme de FS...une autre piste ?

Pour ma part, cela arrive environ une fois par mois: Service OK donc pas de redémarrage auto via systemd... mais pas de connection http possible!
Un script lancé par un cron toutes les 30mn check (via httping) que le serveur web de Domoticz est OK et rédémarre le PI si c'est pas le cas après 60s de pause et 1 retry toujours KO.

J'ai tenté avec un script que j'ai récupéré quelque part...mais ca ne change rien...peut etre une erreur...

Code : Tout sélectionner

#!/bin/bash
# Script qui vérifie l'état de domoticz et qui relance si off

now=$(date) #récupération de la date et heure pour les logs

#Récupération du retour de la commande de status
domoticz=$(sudo service domoticz.sh status)

#echo $domoticz

if [[ "$domoticz" != *"running"* ]] # Si le service n'est pas running
then
 echo "on relance"
 relance=$(sudo service domoticz.sh restart) #On le relance
 echo "$now relance : $relance" #On log la lancement
 else
 echo "$now Domoticz lancé" #On log l'état normal
fi

exit 0

et voilà ma crontab...

Code : Tout sélectionner

*/5 * * * * /home/pi/domotique/domoticz/scripts/check_domoticz_online.sh

Voilà aussi je que j'ai pu voir dans les logs de domoticz

Code : Tout sélectionner

2018-12-30 00:49:40.046  Error: Domoticz received fatal signal 6 !...
2018-12-30 00:49:40.049  Error:   /home/pi/domotique/domoticz/domoticz() [0x262154]
2018-12-30 00:49:40.050  Error:   /home/pi/domotique/domoticz/domoticz(_Z14signal_handleri+0x4c) [0x26220c]
2018-12-30 00:49:40.050  Error:   /lib/arm-linux-gnueabihf/libc.so.6(__default_sa_restorer+0) [0x76c936b0]
2018-12-30 00:49:40.050  Error:   /lib/arm-linux-gnueabihf/libc.so.6(gsignal+0xa0) [0x76c9245c]

[lost]

J'ai tenté avec un script que j'ai récupéré quelque part...mais ca ne change rien...peut etre une erreur...

Comme précisé, j'ai des cas ou le service domoticz est toujours OK... mais l'interface web KO. C'est pourquoi pour ma part je fais via httping.

Car ici, c'est l'état "running" du service qui est vérifié par le script et si cet état est resté bon, il n'y aura pas de redémarrage. Et si le service est KO, je serais fort étonné que la commande de redémarrage via sudo fonctionne. Ou bien il faudrait que l'utilisateur sous lequel le cron lance le script soit configuré pour être sudoer sans mot de passe (cela se fait, possiblement pour une commande précise d'ailleurs ce qui niveau sécurité est mieux)... Ou que ce soit fait via le cron de l'utilisateur root (mais sudo non nécessaire, alors).

Par ailleurs, c'est une chaine contenant "running" qui est vérifiée... alors qu'il serait possible (et plus fiable/simple) de vérifier la valeur de retour de la commande (dans $? on récupère cette valeur pour la dernière commande ; nulle = pas d'erreur, c'est la convention en shell). Bref, entre le mode de vérification et le sudo, le script semble écrit par qqun qui débute un peu!

Pas chez moi, mais si je teste (en root) sur une machine Linux avec un autre service (dnsmasq, partant d'un service stoppé, puis redémarré):

root@ServLab:~# service dnsmasq stop 2&> /dev/null
root@ServLab:~# echo $?
0
root@ServLab:~# service dnsmasq status 2&> /dev/null
root@ServLab:~# echo $?
3
root@ServLab:~# service dnsmasq start 2&> /dev/null
root@ServLab:~# echo $?
0
root@ServLab:~# service dnsmasq status 2&> /dev/null
root@ServLab:~# echo $?
0

On voit que les commandes stop/start réussissent (avec sortie texte ignorées et envoyée vers device null)... et que quand stoppé, la demande de status renvoit 3 et si démarré, la même renvoie 0.

Donc un test type:

Code : Tout sélectionner

service domoticz status 2&> /dev/null
[ $? -ne 0 ] && service domoticz start

Ferait l'affaire...

Mais bon, normalement, systemd est capable de redémarrer un service qui plante automatiquement sans faire de script (ca se configure si pas déjà le cas). Ce script+cron est donc normalement inutile... Par contre, la version httping reste utile en complément (justement pour les cas, objet du post, ou planté mais service resté "running").

[tonejay]

J'ai tenté avec un script que j'ai récupéré quelque part...mais ca ne change rien...peut etre une erreur...

Comme précisé, j'ai des cas ou le service domoticz est toujours OK... mais l'interface web KO. C'est pourquoi pour ma part je fais via httping.

Car ici, c'est l'état "running" du service qui est vérifié par le script et si cet état est resté bon, il n'y aura pas de redémarrage. Et si le service est KO, je serais fort étonné que la commande de redémarrage via sudo fonctionne. Ou bien il faudrait que l'utilisateur sous lequel le cron lance le script soit configuré pour être sudoer sans mot de passe (cela se fait, possiblement pour une commande précise d'ailleurs ce qui niveau sécurité est mieux)... Ou que ce soit fait via le cron de l'utilisateur root (mais sudo non nécessaire, alors).

Par ailleurs, c'est une chaine contenant "running" qui est vérifiée... alors qu'il serait possible (et plus fiable/simple) de vérifier la valeur de retour de la commande (dans $? on récupère cette valeur pour la dernière commande ; nulle = pas d'erreur, c'est la convention en shell). Bref, entre le mode de vérification et le sudo, le script semble écrit par qqun qui débute un peu!

Pas chez moi, mais si je teste (en root) sur une machine Linux avec un autre service (dnsmasq, partant d'un service stoppé, puis redémarré):

root@ServLab:~# service dnsmasq stop 2&> /dev/null
root@ServLab:~# echo $?
0
root@ServLab:~# service dnsmasq status 2&> /dev/null
root@ServLab:~# echo $?
3
root@ServLab:~# service dnsmasq start 2&> /dev/null
root@ServLab:~# echo $?
0
root@ServLab:~# service dnsmasq status 2&> /dev/null
root@ServLab:~# echo $?
0

On voit que les commandes stop/start réussissent (avec sortie texte ignorées et envoyée vers device null)... et que quand stoppé, la demande de status renvoit 3 et si démarré, la même renvoie 0.

Donc un test type:

Code : Tout sélectionner

service domoticz status 2&> /dev/null
[ $? -ne 0 ] && service domoticz start

Ferait l'affaire...

Mais bon, normalement, systemd est capable de redémarrer un service qui plante automatiquement sans faire de script (ca se configure si pas déjà le cas). Ce script+cron est donc normalement inutile... Par contre, la version httping reste utile en complément (justement pour les cas, objet du post, ou planté mais service resté "running").

Je viens de test...

Avec le service "active (exited)"

Code : Tout sélectionner

service domoticz status 2&> /dev/null
pi@krydbox:~ $ echo $?
0

Apres redémarrage du service, et donc avec le service "active (running)"

Code : Tout sélectionner

service domoticz status 2&> /dev/null
pi@krydbox:~ $ echo $?
0

J'ai le meme retour pour les deux... :-/

[lost]

Je viens de test...

Avec le service "active (exited)"

Code : Tout sélectionner

service domoticz status 2&> /dev/null
pi@krydbox:~ $ echo $?
0

Apres redémarrage du service, et donc avec le service "active (running)"

Code : Tout sélectionner

service domoticz status 2&> /dev/null
pi@krydbox:~ $ echo $?
0

J'ai le meme retour pour les deux... :-/

Car tu avais fait un stop explicitement. Dans ce cas, le "exited" n'est pas vraiment une erreur.
Il faudrait voir sur un vrai plantage ce que dis le status.

Ou faire via httping en complément de ce que systemd est supposé déjà faire (version restart simple du service ou restart complet du PI, ici en commentaire):

Code : Tout sélectionner

#!/bin/bash
# Check domoticz (from a crontab) is up a restart whole PI if needed...

domoticzUrl=localhost:8080
BN=`basename $0`

httping -c 5 -i 0 -t 1 --ts -v -Wsqg $domoticzUrl

if [ $? -ne 0 ]
then
  logger $BN: Domoticz httping-ed KO, retry after 1mn... 
  sleep 1m
  # Retry once
  httping -c 5 -i 0 -t 1 --ts -v -Wsqg $domoticzUrl
  if [ $? -ne 0 ]
  then
    logger $BN: Still KO. Get last logs and REBOOT...
    tail -n 20 /tmp/domoticz.txt | logger
    #shutdown -r now &
    service domoticz restart
    exit 1
  else
    logger $BN: Retry OK !
  fi
else
  logger $BN: Domoticz ALIVE !
fi
exit 0

[Wolfen38]

Salut

T'as pu régler ton problème ?

Car j'ai exactement le même, dz offline tous les matins.

Comme toi j'ai mis en place le check et crontab maps rien n'y fait, obligé de faire un restart en manuel....

[plouf34]

Moi pareil. Depuis 1 semaine plus possible de me connecter en 4g sur domoticz.

[tonejay]

Mon probleme est résolu depuis une semaine...et je ne sais pas pourquoi...de mémoire, il me semble qu'en essayant d'installer dashticz j'ai mis à jour php et certains autres paquets....c'est depuis ce moment que tout est rentré dans l'ordre...