Description
Is there an existing issue for this?
- I have searched the existing issues
Current Behavior
I'm attempting to run systemd (/usr/sbin/init
) as PID 1 in my EC2 instances. This works when running the container using docker tools, but fails when run under localstack.
The reason for this is, when launching an EC2 instance as a dockerized container, localstack overrides the container command with sleep infinity
. There appears to be no way to inhibit this behavior.
-
If the Dockerfile sets
CMD ["/usr/sbin/init"]
then the container starts, but runssleep infinity
rather than the specified RUN command. -
If the Dockerfile for the container sets
ENTRYPOINT ["/usr/sbin/init"]
, the actual command becomes/usr/sbin/init sleep infinity
which causes init to exist due to the invalid arguments.
Please consider adding a flag of some sort to override an EC2 Docker container's command.
Expected Behavior
Localstack runs the entrypoint from the Dockerfile without additional arguments.
How are you starting LocalStack?
With a docker-compose file
Steps To Reproduce
How are you starting localstack (e.g., bin/localstack
command, arguments, or docker-compose.yml
)
export EC2_DOCKER_INIT=0 EC2_DOWNLOAD_DEFAULT_IMAGES=0 DEBUG=1 EC2_VM_MANAGER=docker
docker compose -f localstack-pro-compose.yml up
Client commands (e.g., AWS SDK code snippet, or sequence of "awslocal" commands)
awslocal ec2 run-instances --image-id ami-1 --count 1 --instance-type t3.nano --key-name local-key
Dockerfile:
FROM amazonlinux:2023
ENV container docker
RUN dnf install -y systemd kernel-libbpf openssh-server
VOLUME [ /sys/fs/cgroup /tmp /run ]
EXPOSE 22
ENTRYPOINT [ "/usr/sbin/init" ]
docker-compose.yml
services:
systemd:
image: local/amazonlinux-systemd:2023
build:
context: .
tty: true
cgroup: host
cap_add:
- SYS_ADMIN
- NET_ADMIN
volumes:
- /sys/fs/cgroup:/sys/fs/cgroup:rw
Environment
- OS: Fedora 40 x86_64
- LocalStack:
LocalStack version:
LocalStack Docker image sha: d888ed0af94f9df906553ef5cbb37db479257ef32fbfbecdbd884442b31ff848
LocalStack build date: 2024-09-04T14:26:28.222188386Z
Anything else?
Unsure whether to mark this as a bug or feature request. It feels like a misfeature.