Closed Gipetto closed 3 months ago
Hi @Gipetto - thanks for reporting this!
Will investigate - in the meantime, to help narrow-down on any edge-cases, could you also provide the Docker runtime version used to build the image?
Sure thing.
$ docker info
Client:
Version: 24.0.5
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.11.2
Path: /nix/store/gdyxcsv9w1aghvgjy1j4c4mmdh35hi93-docker-plugins/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: 2.23.1
Path: /nix/store/gdyxcsv9w1aghvgjy1j4c4mmdh35hi93-docker-plugins/libexec/docker/cli-plugins/docker-compose
Server:
Containers: 11
Running: 11
Paused: 0
Stopped: 0
Images: 16
Server Version: 24.0.5
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: journald
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc io.containerd.runc.v2
Default Runtime: runc
Init Binary: docker-init
containerd version: v1.7.9
runc version:
init version:
Security Options:
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.6.3
Operating System: NixOS 23.11 (Tapir)
OSType: linux
Architecture: x86_64
CPUs: 12
Total Memory: 31.14GiB
Name: ****
ID: ********-****-****-****-************
Docker Root Dir: /var/lib/docker
Debug Mode: false
Username: *******
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Facing a similar issue. Any update here
@Gipetto @pcnc - hi. Any luck on solving this?
@rbkayz unfortunately we were not able to reproduce the problem across Ubuntu, NixOS, and MacOS.
Using dos2unix
across these systems doesn't seem to modify the file whatsoever - does it modify the file at all on your machine?
Curious if this a git config-related issue. Would you mind checking the value returned by git config --get core.autocrlf
?
The error when trying to deploy to fly.io
@pcnc I do definitely use autocrlf
in git.
$ git config --get core.autocrlf
true
@Gipetto @rbkayz - just merged a fix to ensure that the entrypoint is flagged as executable during the build step.
A bit of a long shot but given we couldn't reproduce it on our end, wondering if this does address the issue on yours.
Thanks a lot. Let me check this and get back
In my use case, these changes don't seem to affect the issue as I'm still receiving the issue:
supabase-grafana-1 | exec /entrypoint.sh: no such file or directory
I just did some more digging and I managed to fix this issue by converting the line endings. Try doing the following:
Visual Studio Code: Open entrypoint.sh
, and at the bottom right of the editor, click on the "CRLF" (or "LF") indicator. Choose "LF" to convert the line endings to Unix format.
Notepad++: Open entrypoint.sh
, go to Edit -> EOL Conversion -> Unix (LF).
Am closing this per #28
Am relying upon @ethan-davies 's assertion that it fixes the issue. I haven't been able to reproduce it, so lmk if it's still not fixed and we can re-open it.
Bug report
Describe the bug
First run starting up per the directions results in the docker container unable to execute the entrypoint file:
To Reproduce
Steps to reproduce the behavior, please provide code snippets or a repository:
Expected behavior
I expect the docker containers to run.
System information
Additional context
Resolution was to run
dos2unix entrypoint.sh
, clear build caches, and re-run withdocker compose up --build
to force the rebuild.