Docker continuously restarting, no logs created

Question

Docker continuously restarting, no logs created

cubagithub opened this issue 3 years ago · 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

Answer 1 · 2021-05-17T07:30:19.000Z

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.

Answer 2 · 2021-05-17T07:50:22.000Z

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.

Answer 3 · 2021-05-17T07:55:16.000Z

that looks like docker-compose's output, what does docker logs arewedown give?

Answer 4 · 2021-05-17T07:56:13.000Z

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

Answer 5 · 2021-05-17T08:01:47.000Z

Interesting - haven't see this before. Which distro/version are your running on your Pi? Also which version of docker? (docker -v)

Answer 6 · 2021-05-17T08:15:15.000Z

Using DietPi Buster, which is effectively Raspbian 10 (Buster).

$ docker -v
Docker version 20.10.6, build 370c289

Answer 7 · 2021-05-17T08:37:37.000Z

$ 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.

Answer 8 · 2021-05-17T08:45:52.000Z

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

Answer 9 · 2021-05-17T09:49:03.000Z

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.

Answer 10 · 2021-05-17T10:29:17.000Z

No worries. I am also thinking it's maybe to do with the B+, like being armhf architecture not being happy with the image.

Answer 11 · 2021-05-17T23:51:20.000Z

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.

Answer 12 · 2021-05-21T11:12:35.000Z

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.

Answer 13 · 2021-05-21T11:35:42.000Z

If you have any test cases/steps I'm happy to run them for you on my Pi and report back.

Answer 14 · 2021-06-02T19:12:26.000Z

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.

Answer 15 · 2021-06-06T18:01:13.000Z

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.