[BUG] custom-init doesn't run before docker mods applies

[Diluka]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

custom-init scripts run after docker mods

Expected Behavior

custom-init scripts run before all

Steps To Reproduce

1. mount init scripts to /custom-cont-init.d
2. start container
3. see logs. I add HERE 1 and HERE 2 markers

HERE 1 is at beginning, it says no scripts found. And HERE 2 is after docker mods it says found some scripts and executed.

Environment

- OS: any
- How docker service was installed: get from docker.com

Docker creation

-compose.yml
services:
  nginx:
    image: linuxserver/nginx
    volumes:
      - ./init.d:/custom-cont-init.d:ro
      - ./repositories:/etc/apk/repositories
    environment:
      - DOCKER_MODS=linuxserver/mods:swag-auto-reload

Container logs

[custom-init] No custom services found, skipping...  <--- HERE 1
[mod-init] Attempting to run Docker Modification Logic
[mod-init] Applying linuxserver/mods:swag-auto-reload files to container
[mod-init] linuxserver/mods:swag-auto-reload applied to container
[migrations] started
[migrations] 01-nginx-site-confs-default: skipped
[migrations] done
usermod: no changes

-------------------------------------
          _         ()
         | |  ___   _    __
         | | / __| | |  /  \
         | | \__ \ | | | () |
         |_| |___/ |_|  \__/


Brought to you by linuxserver.io
-------------------------------------

To support LSIO projects visit:
https://www.linuxserver.io/donate/
-------------------------------------
GID/UID
-------------------------------------

User uid:    911
User gid:    911
-------------------------------------

using keys found in /config/keys
**** Adding swag-auto-reload deps to package install list ****
[mod-init] **** Installing all mod packages ****
fetch http://mirrors.aliyun.com/alpine/v3.17/main/x86_64/APKINDEX.tar.gz
fetch http://mirrors.aliyun.com/alpine/v3.17/community/x86_64/APKINDEX.tar.gz
(1/2) Installing inotify-tools-libs (3.22.6.0-r0)
(2/2) Installing inotify-tools (3.22.6.0-r0)
Executing busybox-1.35.0-r29.trigger
OK: 144 MiB in 180 packages
[custom-init] Files found, executing <--- HERE 2
[custom-init] 00-hello.sh: executing...
hello world!
[custom-init] 00-hello.sh: exited 0
MOD Auto-reload: Watching the following files/folders for changes (excluding .sample and .md files):
/config/nginx
[ls.io-init] done.

[Diluka]

Since override env is not working #91. I want to use custom-init to change apk repos. But it executed too late.

[thespad]

That env is only used in the rootfs build stage, it's not available in the final image or at runtime. What you're seeing is by design, the init order is:

• Built-in init scripts
• Mod scripts
• Custom scripts
• Services

What you're doing with mounting your own repositories file will achieve what you want, but it's not something we intend to provide direct support for changing.

[nemchik]

Following your trail in #91 it looks like the only place you would be affected is when the mod init script finds that jq or curl are missing during init. These are now included in the base image and SWAG has been rebased to alpine 3.17, so that step should be skipped during init.

Aside from that, when the images are built we use dl-cdn.alpinelinux.org and unless you are building the images yourself (including the base images) this wouldn't be something you would need to change. When you run the images we have built, sometimes additional packages are installed during the container init, but we try to minimize that.

If you update swag and/or nginx they should not require installing jq/curl during init.

[Diluka]

mount repositories will do but base image update alpine version will fail restart

there is a init log([custom-init] No custom services found, skipping...) before mod. I wonder if I can take advantage of it

[thespad]

No, while custom services are processed before the init starts, they're started after everything else.

Unfortunately, as it stands, the repositories mount is your best option. It will break when we change the base image to a different Alpine version, but that's relatively rare (every 6 months at most) and called out in the change logs.