Docker continuously restarting, no logs created about arewedown

[shukriadams]

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.

[cubagithub]

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.

[shukriadams]

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

[cubagithub]

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

[shukriadams]

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

[cubagithub]

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

$ docker -v
Docker version 20.10.6, build 370c289

[shukriadams]

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

[cubagithub]

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

[shukriadams]

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.

[cubagithub]

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

[cubagithub]

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.

[shukriadams]

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.

[cubagithub]

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

[shukriadams]

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.

[shukriadams]

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.