NPM fails to start : s6-rc fatal error

[Soupolait]

Hi there, since the first timeI installed NPM it never started well. After a reboot of my server the container does start but there’s still this weird error : s6-rc: info: service s6rc-oneshot-runner: starting s6-rc: info: service s6rc-oneshot-runner successfully started s6-rc: info: service fix-attrs: starting s6-rc: info: service fix-attrs successfully started s6-rc: info: service legacy-cont-init: starting s6-rc: info: service legacy-cont-init successfully started s6-rc: info: service prepare: starting s6-rc: fatal: timed out s6-sudoc: fatal: unable to get exit status from server: Operation timed out /run/s6/basedir/scripts/rc.init: warning: s6-rc failed to properly bring all the services up! Check your logs (in /run/uncaught-logs/current if you have in-container logging) for more information. I have to go to portainer and recreate the container at each of my server reboot so it starts well. Here’s the steps to reproduce : use this docker compose and just reboot your device where NPM is installed. version: '3.8'services: app:
image: 'jc21/nginx-proxy-manager:latest' restart: unless-stopped ports: - '80:80' - '81:81' - '443:443'
volumes:
- /home/louise/docker/NGINX/data:/data - /home/louise/docker/NGINX/letsencrypt:/etc/letsencrypt 

If anyone has any idea about how to fix s6-rc not working (I don’t even know what it is tbh), I take !

[apriliars3]

I have same issue

❯ Configuring npmuser ... id: 'npmuser': no such user s6-rc: fatal: timed out s6-sudoc: fatal: unable to get exit status from server: Operation timed out /run/s6/basedir/scripts/rc.init: warning: s6-rc failed to properly bring all the services up! Check your logs (in /run/uncaught-logs/current if you have in-container logging) for more information.

[redtripleAAA]

I have this instance running for many years, after rebooting the host. The host started.

Note: using this tag fixed the issue for me for now # 2.9.22

[Soupolait]

Since NPM works well when it's first created but not after a reboot I created a script that recreates the container at every startup. Here's the script if anyone's interested (it could definitely need improvements but it works). NPM.txt

[dlzdwxdt]

I also have this problem, docker deployment, please let me know if it is solved

❯ Setting ownership ... s6-rc: fatal: timed out s6-sudoc: fatal: unable to get exit status from server: Operation timed out /run/s6/basedir/scripts/rc.init: warning: s6-rc failed to properly bring all the services up! Check your logs (in /run/uncaught-logs/current if you have in-container logging) for more information.

[yurividal]

same problem here. had to roll back to 2.9.22

[Dremor]

I'm not entirely sure, but it may be linked to a problem I'm experiencing on TrueNAS Scale, where NPM works on SSDs based pools, and not on HDDs pools. May be a clue to what the problem is coming from.

One of the main TrueCharts (a community k3s charts repository) developer said that most apps that uses s6 are affected by this timeout problem, due to "chowning and copying their files" and not finishing this it time before the 5 minute K8S window expire.

[IamTaoChen]

I have similar bug.

ngx-app-1  | ❯ Configuring npm user ...
ngx-app-1  | ❯ Configuring npm group ...
ngx-app-1  | ❯ Checking paths ...
ngx-app-1  | ❯ Setting ownership ...
ngx-app-1  | ❯ Dynamic resolvers ...
ngx-app-1  | s6-rc: warning: unable to start service prepare: command exited 127
ngx-app-1  | /run/s6/basedir/scripts/rc.init: warning: s6-rc failed to properly bring all the services up! Check your logs (in /run/uncaught-logs/current if you have in-container logging) for more information.

This is my docker-compose.yml:

version: '3'
services:
  app:
    image: jc21/nginx-proxy-manager:v3
    restart: unless-stopped
    ports:
      - '9080:80'
      - '81:81'
      - '9443:443'
    volumes:
      - ./data:/data

[doodlebro]

This has been an ongoing issue for months, even on 2.9.22 I have to occasionally restart the container manually.

Can we just roll back whatever change caused these constant permissions issues?

[jackyaz]

I had to pull jc21/nginx-proxy-manager:2.10.3 specifically, latest seemed to still pull 2.10.2 which still had the error reported here

[thisisnotfez]

export: fatal: unable to exec /etc/s6/init/init-stage1: No such file or directory

Throwing my name into the hat. I get this after rolling back to 2.9.20. Been running for years, and this just started the other day.

  nginxpm:
    image: jc21/nginx-proxy-manager:2.9.20
    container_name: nginx-proxy-manager
    #security_opt: #an attempt to fix, didn't work.
    #  - seccomp:unconfined
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
    ports:
      - 80:80
      - 81:81
      - 443:443
    labels:
      - docker.group=monitor
    volumes:
      - ${LOCALTIME}:${LOCALTIME}:ro
      - ${NGINX_CONF}:/config:rw
      - ${NGINX_CONF}/letsencrypt:/etc/letsencrypt
      - ${NGINX_CONF}/data:/data
      - ${NGINX_CONF}/etc:/etc
    healthcheck:
      test:
        - CMD
        - /bin/check-health
      interval: 10s
      timeout: 3s
    restart: always

UPDATE: Manually pulling 2.10.3 did not resolve the issue for me.

[thisisnotfez]

New discovery.

s6-rc-compile: fatal: during resolution of bundle top: undefined service name user2

EDIT: UGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH

For some reason I had /etc defined as a local folder. Came right up as soon as I had commented it out.

[jeongsu816]

hello.

I faced similar problem when reboot my device and now it works fine after add this environment variable.

S6_CMD_WAIT_FOR_SERVICES_MAXTIME

default value is 5000 (5 seconds). I set it to 60000.

[Aiakio]

I faced similar problem when reboot my device and now it works fine after add this environment variable.

S6_CMD_WAIT_FOR_SERVICES_MAXTIME

default value is 5000 (5 seconds). I set it to 60000.

        environment:
            - S6_CMD_WAIT_FOR_SERVICES_MAXTIME=60000

That doesnt work for me sadly. Same exact error in logs. Only on v3 though. Latest works, even without the environment variable.

[github-actions[bot]]

Issue is now considered stale. If you want to keep it open, please comment :+1:

[Dremor]

Still a problem.

[github-actions[bot]]

Issue is now considered stale. If you want to keep it open, please comment :+1:

[Dremor]

Still a problem, but the upstream proposed workaround works, and a more definitive fix proposal seem to be worked on upstream.