Crash de Emby: "s6-svscanctl: fatal: unable to control /var/run/s6/services: supervisor not listening"

[mrjay42 5]

Bonjour à tous,

Ce n'est pas la première fois que je vois ce bug sur Emby, je pensais que c'était de ma faute
Sauf que bon, mon setup est on ne peut plus simple.

Commencons deja par l'erreur à laquelle je suis confronté:
 

Info App: All entry points have started
s6-svscanctl: fatal: unable to control /var/run/s6/services: supervisor not listening
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done. [s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.
[s6-finish] sending all processes the KILL signal and exiting.

 

Ma stack est configurée comme ceci
 

version: "2.3"

services:
  emby:
    image: emby/embyserver
    container_name: embyserver3.1
    #runtime: cpu # Expose NVIDIA GPUs
    networks:
      - private_secured_network
    #network_mode: bridge # Enable DLNA and Wake-on-Lan
    environment:
      - UID=1000 # The UID to run emby as (default: 2)
      - GID=1000 # The GID to run emby as (default 2)
      - GIDLIST=1000 # A comma-separated list of additional GIDs to run emby as (default: 2)
    volumes:
      - /home/mrjay/Desktop/apps/emby:/config # Configuration directory
      - /home/mrjay/Desktop/data/Downloads/transmission/completed:/mnt/share1
    ports:
      - 8096:8096 # HTTP port
    #  - 8920:8920 # HTTPS port
    devices:
      - /dev/dri:/dev/dri # VAAPI/NVDEC/NVENC render nodes
    #  - /dev/vchiq:/dev/vchiq # MMAL/OMX on Raspberry Pi
    restart: on-failure
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.emby.rule=Host(`ca.vous.regarde.pas.com`)"
      - "traefik.http.routers.emby.entrypoints=websecure"
      - "traefik.http.routers.emby.tls.certresolver=myresolver"
      - "traefik.http.services.emby.loadbalancer.server.port=8096"

networks:
  private_secured_network:
    external: true

 

Sur la machine hôte on peut voir ceci:

$ id mrjay
uid=1000(mrjay) gid=1000(mrjay) groups=1000(mrjay),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),101(netdev),102(scanner),108(bluetooth),110(lpadmin),981(docker)

Donc c'est bien le bon UID, qui correspond aux dossiers suivants:

drwxrwx--- 3 mrjay mrjay        4096 21 juil. 22:00 Downloads

$ ll
total 160
drwxrwx---  13 mrjay mrjay  4096  3 oct.  13:30 .
drwxrwx---   5 mrjay mrjay  4096 26 juil. 15:48 ..
drwxrwx---  19 mrjay mrjay  4096 22 avril 16:40 audio
drwxrwx--- 112 mrjay mrjay 12288  1 oct.  13:47 audiobooks
drwxrwx---   8 mrjay mrjay  4096  1 oct.  13:48 books
drwxrwx--- 171 mrjay mrjay 69632  2 oct.  14:44 films
drwxrwx---  50 mrjay mrjay 20480  1 oct.  23:33 filmsfr
drwxrwx---   2 mrjay mrjay  4096 28 sept. 23:43 games
drwxrwx---  13 mrjay mrjay  4096  2 oct.  15:50 new
drwxrwx---  19 mrjay mrjay  4096 20 août  14:14 old
drwxrwx--- 143 mrjay mrjay 20480  2 oct.  14:56 series
drwxrwx---  57 mrjay mrjay  4096  2 oct.  14:56 seriesfr
drwxrwx---   3 mrjay mrjay  4096 29 sept. 23:05 softs
mrjay@minibip:~/Desktop/data/Downloads/transmission/completed

Par ailleurs, le container est lancé en root de toutes facons (c'est critiquable je sais, mais là je ne pense pas que ce soit le sujet):

s$ docker exec -it embyserver3.1 id
uid=0(root) gid=0(root) groups=0(root),10(wheel)

 

Pour le contexte, la distrib linux c'est ca
 

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux forky/sid
Release:        n/a
Codename:       forky

-----

Pensant qu'il s'agit probablement d'un problème de permissions, j'ai fait lancé les commandes suivantes:

Sur la machine hôte, sur le repertoire "/home/mrjay/Desktop/apps/emby" juste au cas où je viens de lancer cette commande:

sudo chown -R 1000:1000 emby/

De même sur le repertoire "/home/mrjay/Desktop/data/Downloads":

sudo chown 1000:1000 -R Downloads/

 

Donc, je ne sais pas si mon problèm est résolu pour l'instant. Je vais supposer que ce n'est pas le cas, parce que je ne vois pas comment un container lancé un root peut avoir des problèmes d'écritures dans les repertoires qui lui sont donnés en accès.
 

Si vous avez des idées je suis preneur

Si j'ai oublié des infos, n'hésitez pas à demander
 

Merci d'avance pour votre aide  

 

[vincen 71]

Salut

 

Pour la partie Docker je laisserais les experts te répondre  Par contre 2 remarques malgré tout:

• Essayer de faire tourner Emby sur une distro pas finalisée je pense pas que ça soit une bonne idée et à part s'attirer beaucoup de problèmes je ne vois pas du tout l'intérêt !
• Ton inage s'appelle Embyserver3.1 j'espère que c'est pas la version du serveur Emby que tu essayes de faire tourner ? parce qu'on en est à la 4.9 actuellement

Vincèn

[mrjay42 5]

Merci pour ta réponse ^^
 

"Embyserver3.1" c'est juste un nom, ca doit dater de la premiere install que j'ai faite de Emby y'a longtemps, mais c'est vraiment juste une chaine de caractères. 

Je viens de vérifier je suis en version 4.8.11.0, d'ailleurs ca me dit que la nouvelle version est dispo, je vais voir ce que je peux faire pour faire l'update de suite

 

 

Quant à la distro, sans rentrer dans un débat sans fin, dire que Debian testing c'est pas stable, c'est pas faux, mais c'est pas non une distrib complètement instable.
Par ailleurs, j'avais eu le même bug (celui du message original) sur ma distrib d'avant (Linux Mint 21.2 -> une vieille distrib desktop que j'ai voulu remplacer par quelque chose de plus moderne). À l'inverse, si j'avais mis une Debian stable, je prends le "risque" d'être un peu "en retard" sur certains paquets, et ca m'aurait grave cassé les pieds pour d'autres projets.

 

Bref, il y a certainement quelque chose de "faux" ou d'incorrect avec mon setup

Et je ca sent grave le problème de permissions Linux, mais je vois pas comment c'est possible, mon container literallement fonctionne en root :') et les deux seuls dossiers auxquels le container accède ont les bonnes permissions

 

 

[mrjay42 5]

C'est tout bon, c'est mis à jour 

 

 

J'ai aussi modifié un truc dans mon docker compose, j'ai commenté la partie "ports", puisque de toutes facons mon Traefik (reverse proxy) gère l'accès au container directement, donc je n'ai plus besoin d'exposer le port 8096

Voici le nouveau code

version: "2.3"

services:
  emby:
    image: emby/embyserver
    container_name: embyserver3.1
    #runtime: cpu # Expose NVIDIA GPUs
    networks:
      - private_secured_network
    #network_mode: bridge # Enable DLNA and Wake-on-Lan
    environment:
      - UID=1000 # The UID to run emby as (default: 2)
      - GID=1000 # The GID to run emby as (default 2)
      - GIDLIST=1000 # A comma-separated list of additional GIDs to run emby as (default: 2)
    volumes:
      - /home/mrjay/Desktop/apps/emby:/config # Configuration directory
      - /home/mrjay/Desktop/data/Downloads/transmission/completed:/mnt/share1
    #ports:
    #  - 8096:8096 # HTTP port
    #  - 8920:8920 # HTTPS port
    devices:
      - /dev/dri:/dev/dri # VAAPI/NVDEC/NVENC render nodes
    #  - /dev/vchiq:/dev/vchiq # MMAL/OMX on Raspberry Pi
    restart: on-failure
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.emby.rule=Host(`ca.vous.regarde.pas.com`)"
      - "traefik.http.routers.emby.entrypoints=websecure"
      - "traefik.http.routers.emby.tls.certresolver=myresolver"
      - "traefik.http.services.emby.loadbalancer.server.port=8096"

networks:
  private_secured_network:
    external: true

 

[vincen 71]

3 minutes ago, mrjay42 said:

J'ai aussi modifié un truc dans mon docker compose, j'ai commenté la partie "ports", puisque de toutes facons mon Traefik (reverse proxy) gère l'accès au container directement, donc je n'ai plus besoin d'exposer le port 8096

Du coup c'était le mappage de port qui mettait le bazard pour démarrer le container ?

[mrjay42 5]

3 minutes ago, vincen said:

Du coup c'était le mappage de port qui mettait le bazard pour démarrer le container ?

Ah pardon je réalise que je n'ai pas été clair, le container démarre très bien et fonctionne très bien. MAIS à un moment donné, complètement random -> il crash. Et je peux le 'restart' sans problème et ca marche à nouveau.

J'ai recherché ce problème de "s6-svscanctl: fatal: unable to control /var/run/s6/services: supervisor not listening" et je ne suis vraiment pas le seul à en parler sur Internet. Toutes sortes de gens ont ce problème sur différents services qu'ils essayent d'administrer.

Du coup, ca veut dire déjà que ce n'est pas lié à Emby.

C'est quelque chose en amont, ou "autour" de Emby: docker? portainer? docker compose? Traefik? Permissions Linux? Conflit de port Docker/reverse proxy? -> j'en sais rien :3

 

 

Bref, je reviendrai ici pour dire si mon container Emby "tient" le coup ou pas ^^

 

Edited October 3, 2025 by mrjay42

[vincen 71]

Effectivement merci pour les précisions  Peut être regarder les logs d'Emby lui-même juste avant le crash du container ? ou essayer peut être aussi de désactiver temporairement la section 

devices:

mais en tout cas c'est plutôt la partie docker qu'il faut investiguer puisque si le problème se pose avec d'autres images Docker c'est pas un problème Emby. En plus si c'était un problème de l'image Emby tu as mis le restart donc normalement Docker redémarrerait l'image si elle crashe.

Jette un oeil aux logs Docker aussi...

[mrjay42 5]

Bon.

Je pense avancer sur un truc.
 

En utilisant l'image linuxserver/emby, tout d'un coup, plus aucun films/medias ne voulait se lancer. Donc Emby se lancait bien, MAIS il n'était plus capable de lire les medias alors que les permissions étaient bien définies.

Par ailleurs, j'ai remarqué que soit linuxserver/emby, soit linuxserver/emby créait/définissait les permissions de /home/mrjay/Desktop/apps/emby en 911:911. Qui sont un user et un group qui n'existent pas.

Mais, comme j'ai récup ma config Emby en provenance de mon vieux serveur, voir ici 

Je me dis que ce 911 est un signe que quelque chose ne tourne pas rond sur mes permissions

Et j'ai vu que je n'étais pas le seul à avoir ce problème voir ici 

On lui dit sur ce thread Reddit, que si ca part en 911:911 c'est que y'a un problème de definitions des droits -> ok super :')

Et apparemment, la solution du mec a été tout simplement de suivre le flow, accepter sa défaite et créer un user et un groupe 911

C'est ce que j'ai fait aussi

# Create group with GID 911 (if it doesn’t exist)
sudo groupadd -g 911 embygroup

# Create user with UID 911 and assign to the group
sudo useradd -u 911 -g 911 -M -s /usr/sbin/nologin embyuser

Bien sur j'ai switch les permissions qui vont bien

# Set ownership: user 1000 (mrjay), group 911 (embygroup)
sudo chown -R 1000:911 /home/mrjay/Desktop/apps/emby
sudo chown -R 1000:911 /home/mrjay/Desktop/data/Downloads/transmission/completed

# Set permissions: owner rwx, group rwx, others nothing
sudo chmod -R 770 /home/mrjay/Desktop/apps/emby
sudo chmod -R 770 /home/mrjay/Desktop/data/Downloads/transmission/completed

Et parce que je suis un peu maniaque et parce que je pense aux nouveaux medias qui vont arriver (par torrent) et qui ne seront peut être pas lus correctement, j'ai rajouté à mon user root, un ptit crontab qui tourne toutes les trois minutes pour définir les bonnes permissions

*/3 * * * * chown -R 1000:911 /home/mrjay/Desktop/apps/emby /home/mrjay/Desktop/data/Downloads/transmission/completed && chmod -R 770 /home/mrjay/Desktop/apps/emby /home/mrjay/Desktop/data/Downloads/transmission/completed

Bon, c'est pas parfait

J'ai dû faire des erreurs quelque part.

Mais maintenant j'en suis quasi certain, le problème ne vient PAS de Docker, pas de Traefik, pas de Emby lui même, pas de Linux, mais du fait que j'ai recup une vieille config de Emby qui doit avoir des "vieux morceaux" de config qui trainent dedans. Et comme je ne veux pas tout perdre (mes users, l'etat de ce qui a été vu/pas vu, etc. etc.) -> j'ai préféré faire cette solution.

 

Juste au cas où la config à laquelle j'arrive est celle-ci

version: "2.3"

services:
  emby:
    image: linuxserver/emby
    container_name: embyserver
    #runtime: cpu # Expose NVIDIA GPUs
    networks:
      - private_secured_network
    #network_mode: bridge # Enable DLNA and Wake-on-Lan
    environment:
      - UID=1000 # The UID to run emby as (default: 2)
      - GID=1000 # The GID to run emby as (default 2)
      - GIDLIST=1000 # A comma-separated list of additional GIDs to run emby as (default: 2)
    volumes:
      - /home/mrjay/Desktop/apps/emby:/config # Configuration directory
      - /home/mrjay/Desktop/data/Downloads/transmission/completed:/mnt/share1
    #ports:
    #  - 8096:8096 # HTTP port
    #  - 8920:8920 # HTTPS port
    devices:
      - /dev/dri:/dev/dri # VAAPI/NVDEC/NVENC render nodes
    #  - /dev/vchiq:/dev/vchiq # MMAL/OMX on Raspberry Pi
    restart: always
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.emby.rule=Host(`blablabla.com`)"
      - "traefik.http.routers.emby.entrypoints=websecure"
      - "traefik.http.routers.emby.tls.certresolver=myresolver"
      - "traefik.http.services.emby.loadbalancer.server.port=8096"

networks:
  private_secured_network:
    external: true

 

[Luke 42077]

Hi there, please attach the Emby server log from when the problem occurred:

How to Report a Problem

Thanks!

 

[mrjay42 5]

17 hours ago, Luke said:

Hi there, please attach the Emby server log from when the problem occurred:

How to Report a Problem

Thanks!

 

 

Thanks for your reply and suggestion.
I'm working on it
I have two ideas:

1.
send a few reports from yesterday with errors in them that seem to make sense

2.

Wait for the problem to happen again, and then I'll send the corresponding report

 

Either way, there's something annoying, I grep'd the logs, and it spams my domain name in them. So I'll want to clean the reports before sharing them as I don't see any valid reason why my domain name should be on display anywhere

 

I don't know if that makes any sense as a suggestion: but anonymous logs could be an option? (maybe it already exist and I missed it?)

[Luke 42077]

HI, make sure to download the log files from the server web interface rather than going straight to the actual log files. Please let us know if this helps.

[mrjay42 5]

Alright, in doubt, I have "re-installed" (more correct to say "redeployed") a new instance of Emby on my server.

I see too many things going a little wrong here and there. And it can't be right.
Now I have set up my new instance as properly as I could, following the documentation.

So I'm gonna mark this topic as solved, because, technically my 'old' Emby install, hasn't crashed again since I created a specific user with that specific number (911).

But that's a solution that I find inelegant and unsatisfying.

So -> clean new install -> I'll post here to say if the problem happens again with that new install.

[Luke 42077]

OK thanks for following up. Please keep us posted.

[mrjay42 5]

11 hours ago, Luke said:

OK thanks for following up. Please keep us posted.

Thanks for your help btw!

In the meantime, as I said, I installed a new instance, I bought Emby Premiere and I'm trying to enable GPU acceleration on Linux but I failed so far. I posted my struggle here:

 

But  it seems so complex  I've read tons of topics on the forum, tons of stuff online (reddit, etc.) the documentation of course, so far GPU acceleration is not working.

I'm so desperate that I'm asking Perplexity to find the info for me Xd

[mrjay42 5]

Ok actually, I think I've figured out the solution to this problem and my other problem (GPU acceleration).

It is possible that the problem is the following:

• I am running on Debian testing, yes @vincenyou were right
• I get kernel updates quite often
• Therefore, if I update my Linux (apt dist-upgrade), I end up updating the computer
• But let's say the NVIDIA drivers are the same (not updated during the dist-upgrade)
• Then, after reboot (and possibly also without reboot)-> boom, new kernel, new headers (most likely NOT downloaded automatically), nvidia drivers are not available (and possibly other drivers too?)
• In any case it means that this /dev/dri:/dev/dri -> causes a crash and the Emby container won't even start
• And guess which error I get when this happens? -> s6-svscanctl: fatal: unable to control /var/run/s6/services: supervisor not listening

So the solution is:

Don't be a dumbass like me and don't install Debian testing.

But more accurately, if you do update your Linux and you get a crash on Emby it might most likely be a problem of -> new kernel -> new headers must be downloaded -> driver needs to be recompiled and modprobed in the kernel

 

Good news is:

As far as I know, realizing this, made me solve my crashing issue AND I managed to have GPU acceleration (transcoding with GPU) on Emby+Linux+Docker.

And because I'm super nice  I wrote a little tutorial there