Docker container keeps restarting

[aleexnunez]

Im working on a Raspberry Pi Zero W with fresh Debian 9 and Docker installed. I followed the wiki's installation in docker steps but, when I start the container, it gets stuck in "restart" status.

docker run --name="motioneye" \ -p 8765:8765 \ --hostname=raspberrypi \ -v /etc/localtime:/etc/localtime:ro \ -v /etc/motioneye:/etc/motioneye \ -v /var/lib/motioneye:/var/lib/motioneye \ --restart="always" \ --device=/dev/video0 ccrisan/motioneye:dev-armhf

Do I need to create the motioneye.conf file in /etc/motioneye/ or any other file in order to run the command?

[kleini]

Please provide the output of docker container log -f motioneye so we can see, what the problem is.

[aleexnunez]

It doesnt show any output. Even when I use docker run doesnt show any.

[kleini]

This sounds weird. Did you try to run any other container within that installation of Docker runtime?

[aleexnunez]

Yes, and the rest behave properly. I think the problem is related to the config.

Do I need to have the motioneye.conf in /etc/motioneye to run it or any other file?

[kleini]

No, normally not. The start script copies the sample configuration file to /etc/motioneye when the container starts and no motioneye.conf file is there. Does the file exist there after you tried to start the container?

[aleexnunez]

No, the folder is empty. I tried changing permissions of volume paths too but keeps restarting.

[kleini]

I will try to reproduce that.

[l0gik]

I've had the same issues here on my Raspberry Pi Zero W.

Now I'm no Docker wizard, but after some poking around, I found that it appears to stem from the parent image used (the line FROM multiarch/debian-debootstrap:armhf-stretch in the Dockerfile). In my case, the container was always returning a 139 exit status (SIGSEGV) -- maybe the container as-provided is not being built for the right architecture? I haven't tried the qemu emulation method because the "Install in Docker" documentation explains that this is not necessary if building on the Pi.

Anyhow, try changing the Dockerfile's parent image to something compatible (e.g. FROM resin/rpi-raspbian:stretch) and build manually. It works great, although I suspect with some package bloat in the case of that image.

[aleexnunez]

@l0gik I will give it a try. Thanx!

[aleexnunez]

I changed the base image to resin/rpi-raspbian:stretch as @l0gik suggested and now it works perfect.

[kleini]

Unfortunately GitHub Travis CI does not provide any support for running code on armhf plaforms. This makes me unable to provide ready to use images on Docker Hub. The multiarch/debian-debootstrap:armhf-stretch gives the possibility to run the Docker image on x86 platforms through an additional statically linked qemu binary in the image. This gives the ability to create ready to use Docker images for armhf on x86 platforms. I will have a look, why this statically linked qemu binary makes problems and how to get around that on Raspberry Pis.

[agilob]

I noticed similar behaviour when run in command line but when I use docker-compose (without -d or detach mode) I get errors in console.

version: "3.3"

services:
  motioneye:
    container_name: motioneye
    image: ccrisan/motioneye:master-armhf
    hostname: motioneye
    ports:
      - "8081:8081"
      - "8765:8765"
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - $HOME/dockers/motioneye:/etc/motioneye
      - /var/lib/motioneye:/var/lib/motioneye
    devices:
      - /dev/video0:/dev/video0
    restart: unless-stopped

HypriotOS/armv6: pirate@rpi0 in ~
$ docker-compose -f compose.yml up
Creating network "pirate_default" with the default driver
Pulling traefik (ccrisan/motioneye:master-armhf)...
master-armhf: Pulling from ccrisan/motioneye
8f61c09516dd: Pull complete
a992f15c75f9: Pull complete
a47029a42eb2: Pull complete
ec3b4b31856c: Pull complete
ea321cc11639: Pull complete
Creating motioneye ... done
Attaching to motioneye
Exception in thread Thread-4 (most likely raised during interpreter shutdown):
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
  File "/usr/lib/python2.7/threading.py", line 754, in run
  File "/usr/local/lib/python2.7/dist-packages/compose/cli/log_printer.py", line 214, in watch_events
  File "/usr/local/lib/python2.7/dist-packages/compose/project.py", line 425, in events
  File "/usr/local/lib/python2.7/dist-packages/docker/types/daemon.py", line 33, in __next__
<type 'exceptions.AttributeError'>: 'NoneType' object has no attribute 'exceptions'

I'm running this on RPI 0W

[mailergfp]

Hi all, Just tried to install in a docker too with a Raspberry Pi 3 Model B Rev 1.2 with buster lite. I have the same problem both if I use the pre-built container, according to the instruction issuing the command "docker pull ccrisan/motioneye:master-armhf" or if i build it by myself. issuing the command: "docker build --build-arg VCS_REF=$(git rev-parse HEAD) --build-arg BUILD_DATE=$(date +"%Y-%m-%dT%H:%M:%SZ") -t ccrisan/motioneye:master-armhf -f extra/Dockerfile.armv7-armhf ."

Please note this is different from the command in the instruction, ruuning this i compiled it with out error (simply change s/-t ccrisan/motioneye:master-amd64 -f extra/Dockerfile /-t ccrisan/motioneye:master-armhf -f extra/Dockerfile.armv7-armhf).

Unfortunately the result is the same from docker logs motioneye is: standard_init_linux.go:211: exec user process caused "exec format error" standard_init_linux.go:211: exec user process caused "exec format error" standard_init_linux.go:211: exec user process caused "exec format error" and so on ...

Any suggestion? Regards

[kleini]

Maybe the docker image for ARM architectures is completely broken in the meantime. I don't actually have any Raspberry Pi, so I can only test it with qemu and there everything works fine. But maybe qemu behaves differently than a native ARM architecture.

[agilob]

standard_init_linux.go:211: exec user process caused "exec format error"

this error means binary file you're trying to run is not compatible with your CPU

[mailergfp]

@kleini I have built & run in a windows environment and it works uploaded to my hub docker pulled in raspberry and it works. (still some issue but I am working on it)

So it seems docker image for ARM is broken

[kleini]

It is possible, that the ARM image is broken. See the .travis.yml file, how the ARM image is built on Travis CI infrastructure. Some qemu docker image is used to emulate ARM architecture. So within the created image, I have to check, which executables are collected there, that are not for ARM architecture. @mailergfp If you build the image in a windows environment, how to you provide there the ARM architecture?