Asustor Docker après Maj ADM : Conteneur non redémarré malgré le setting adéquat

  • Vague de SPAM

    Suite à une vague de spam sur le forum, les inscriptions sont temporairement limitées.

    Après votre inscription, un membre de l'équipe devra valider votre compte avant qu'il ne soit activé. Nous sommes désolés pour la gêne occasionnée et vous remercions de votre patience.

MilesTEG

Administrateur
Membre du personnel
6 Septembre 2020
3 895
927
313
Bonjour,
J’ai un souci récurent après chaque mise à jour de adm et avec docker.
J’ai des conteneurs non redémarré malgré le paramétre suivant dans les docker-compose :
YAML:
    restart: always

Et tous les conteneurs qui ont ce réglage ne sont pas soumis à ce bug…
Dans ma stack Plex, seul tautulli avait redémarré. Plex et un autre conteneur non.
Même chose pour d’autres stack.

Précisons : tout est installé via portainer avec des docker-compose.yml.

@Dami1 : est-ce un problème déjà connu chez Asustor ?

Dans tous les cas c’est pas pratique. Y a t’il une solution pour que ça redémarre normalement après une maj de adm ?
 
@shaks2022
Après reboot, seul mon conteneur Plex n'est pas redémarré avec les autres :
1692880305507.png
Le log indique ceci :
1692880368091.png
et en tentant le démarrage, j'ai cette erreur (nouveau pour moi de voir ça) :
1692880425609.png

j'ai tente de "Pull and redeploy"
1692880582769.png
Sans succès.
Il a fallu que je stoppe la stack et que je fasse ensuite le "Pull and redeploy"

Vraiment étrange...
 
@shaks2022
Après reboot, seul mon conteneur Plex n'est pas redémarré avec les autres :
Voir la pièce jointe 9814
Le log indique ceci :
Voir la pièce jointe 9815
et en tentant le démarrage, j'ai cette erreur (nouveau pour moi de voir ça) :
Voir la pièce jointe 9816

j'ai tente de "Pull and redeploy"
Voir la pièce jointe 9817
Sans succès.
Il a fallu que je stoppe la stack et que je fasse ensuite le "Pull and redeploy"

Vraiment étrange...
Bonjour
je n'utilise pas Plex , encore moins sous docker , mais je dirais que ça ressemble à un soucis de configuration lié au hostname.. Si un hostname est à définir quelque part , il faudrait vérifier sa valeur .
Par ailleurs , l'erreur de syntaxe sur kill , c'est un bon vieux bug des familles, genre on stocke le pid d'un process à tuer dans une variable puis on utilise kill avec la variable sans vérifier si elle contient bien un pid....sans doute pas bloquant ( tentative de kill d'un process déjà arrêté ) mais ça donne un mauvais signal sur la qualité du code...