Docker continuously restarting, no logs created
cubagithub opened this issue · 15 comments
I've followed exact steps at https://github.com/shukriadams/arewedown#setup-in-docker on a Raspberry Pi Model B+.
Using with example config files with docker-compose 1.29.2 on docker images 0.2.1-arm and 0.2.0-arm.
Container is created but constantly restarts. No logs are created in the ./logs
folder.
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e9747b77ae2c shukriadams/arewedown:0.2.0-arm "/bin/sh -c 'cd /etc…" 3 minutes ago Restarting (132) 24 seconds ago arewedown
Check Docker's own logs with docker logs arewedown
(or the name specified in the compose file). If that output doesn't help, feel free to post it here. The container exiting immediately and not writing to local ./logs folder is often caused by it not having write permission to that folder.
Docker logs shows nothing:
$ docker-compose up
Creating network "dietpi_default" with the default driver
Creating arewedown ... done
Attaching to arewedown
I followed the step in the readme to chown -R 1000 ./logs
but to no avail.
that looks like docker-compose's output, what does docker logs arewedown
give?
that looks like docker-compose's output, what does
docker logs arewedown
give?
Sorry, yes you're right.
But it's the same blank output and detach behaviour as when I run the container:
$ docker-compose logs
Attaching to arewedown
Interesting - haven't see this before. Which distro/version are your running on your Pi? Also which version of docker? (docker -v
)
Using DietPi Buster, which is effectively Raspbian 10 (Buster).
$ docker -v
Docker version 20.10.6, build 370c289
$ docker-compose logs Attaching to arewedown
hmm. just to be totally sure on this, you did run docker logs arewedown
, right? Not docker-compose logs
, those are two different things. Not really too interested in what docker-compose is logging, a failure to spin up the container will happen on the docker
level, regardless of orchestrator.
My understanding of docker-compose logs
is that is will produce the app output logs from all containers defined in the compose file.
Anyhow, docker logs arewedown
produces nothing i.e. blank output:
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c2071e93f259 shukriadams/arewedown:0.2.0-arm "/bin/sh -c 'cd /etc…" 17 minutes ago Restarting (132) 15 seconds ago arewedown
$ docker logs arewedown
That is really interesting - I should have a Model B+ lying around somewhere, haven't tried running on that, so far the oldest Pi that I can confirm it works on is a Pi 3. I'll look into it- thanks for flagging this.
No worries. I am also thinking it's maybe to do with the B+, like being armhf architecture not being happy with the image.
Using the non-arm tagged Docker image, I get some output that suggests that it has a problem with the architecture of the image not built for the architecture of the host, which makes sense.
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0fafcbe1ab17 shukriadams/arewedown:0.2.0 "/bin/sh -c 'cd /etc…" 6 minutes ago Restarting (1) 33 seconds ago arewedown
$ docker-compose logs
Attaching to arewedown
arewedown | standard_init_linux.go:219: exec user process caused: exec format error
arewedown | standard_init_linux.go:219: exec user process caused: exec format error
$ arch
armv6l
$ dpkg --print-architecture
armhf
So using arewedown:0.2.0-arm
doesn't error out this way because of wrong architecture, but it still doesn't produce any logs.
Didn't get an alert for your follow-up post. Yeah, my guess is the container is completely failing to start on the original Pi CPU, assuming that's what you got this on. Still haven't had time to set up a testing station on a model B yet, will try for this weekend.
If you have any test cases/steps I'm happy to run them for you on my Pi and report back.
Ok, dug a bit deeper. Error confirmed on my own Pi B+, also confirmed on the base ubuntu 20.04 image I'm building from. Turns out Ubuntu works on armv7 only (read the fine print I guess), I will add an additional build for arm6 on Alpine to cover this gap, should be out next release.
Thanks for catching, wasn't planning on building this project on Alpine, but this turns that decision around.
So it turns out ARM6 Docker builds aren't feasible, not as things are now. I managed to build a working container image, but I do all release builds via automated Github Actions, and I just noticed that Actions can't run on ARM6 at all (actions/runner#688).
If I can find another way to automate the builds for that architecture (such as via cross compilation) I will revisit this. Disappointed as I would have loved to include older models. You can still install AWD? from source as a NodeJS app.