Container constantly restarts

[arduino43]

Container is constantly restarting. Perhaps a DBUS issue?

Feb 14 06:48:24 raspberrypi containerd[549]: time="2022-02-14T06:48:24.082248809Z" level=info msg="shim disconnected" id=98a5b401b745f554ffc939401f811fd3ae5c9dcbcbf83ae36fa5e4faece72809
Feb 14 06:48:24 raspberrypi systemd[1]: var-lib-docker-overlay2-e476640d70104e735d4f789346c5c8ccd5f50470a74b07ee91abac90d2e8f561-merged.mount: Succeeded.
Feb 14 06:48:24 raspberrypi systemd[765]: var-lib-docker-overlay2-e476640d70104e735d4f789346c5c8ccd5f50470a74b07ee91abac90d2e8f561-merged.mount: Succeeded.
Feb 14 06:48:25 raspberrypi dockerd[544]: time="2022-02-14T06:48:25.735476668Z" level=warning msg="path in container /dev/i2c-1 already exists in privileged mode" container=98a5b401b745f554ffc939401f811fd3ae5c9dcbcbf83ae36fa5e4faece72809
Feb 14 06:48:25 raspberrypi containerd[549]: time="2022-02-14T06:48:25.788880605Z" level=info msg="starting signal loop" namespace=moby path=/run/containerd/io.containerd.runtime.v2.task/moby/98a5b401b745f554ffc939401f811fd3ae5c9dcbcbf83ae36fa5e4faece72809 pid=7766

Docker run:

docker run -d --init
--ulimit nofile=64000:64000
--env REGION_OVERRIDE=EU868
--restart always
--publish 1680:1680/udp
--publish 44158:44158/tcp
--name miner
--device /dev/i2c-1
--net host
--privileged
-v /var/run/dbus:/var/run/dbus
--mount type=bind,source=/home/pi/Helium/overlay/docker.config,target=/opt/miner/releases/2021.09.27.0/sys.config
--mount type=bind,source=/home/pi/Helium/miner_data,target=/var/data \
quay.io/team-helium/miner:miner-arm64_2021.09.27.0_GA

overlay/docker.config

%% -- erlang --

[
"config/sys.config",
{lager,
[
{log_root, "/var/data/log"}
]},
{blockchain,
[
]},
{miner,
[
{jsonrpc_ip, {0,0,0,0}}, %% bind jsonrpc to host when in docker container
%% {use_ebus, false},
{radio_device, { {0,0,0,0}, 1680,
{0,0,0,0}, 31341} }
]}
].

[arduino43]

@sprhawk I notice you had a similar issue - are you able to share how you resolved? Much appreciated.

[controllinohelium]

You are binding the sys.config wrong here:

--mount type=bind,source=/home/pi/Helium/overlay/docker.config,target=/opt/miner/releases/2021.09.27.0/sys.config

[sprhawk]

You are binding the sys.config wrong here:

--mount type=bind,source=/home/pi/Helium/overlay/docker.config,target=/opt/miner/releases/2021.09.27.0/sys.config

I was using steps listed in here. but if the binding target is .../releases/xxxxx/sys.config, then during each upgrade it will need match the release version string?

[serbyxp]

Might need to make that into a docker-compose file, with some variables in the run command that matches the version to the binding point for that sys.config file , if it’s not implemented in the miners update mechanism . 🤷‍♀️ Just a thought . For future proofing your auto update script … most manufacturers only update on _GA releases or latest, so just the date would be the part that changes or varies … on fleet managed miners I noticed that the script has some [{version.xxx}] which links to the other parts of the docker-compose file where -bind ..sys.config:../sys.config is located and /or other version specific docker variables

*but just having it in docker-compose and using docker-compose up name/image should plug that in for you that way your sys.config: part is static and the :../sys.config part is from the image itself , I could be totally off bases here tho…

Like when your miner restarts it should run that docker-compose file , or every x amount of time have a script that runs to check the current quay.io repo and finds / matches / compares your current _GA release to the one in the official repo, and does whatever docker stop service name , docker rm service name , and the script needs to copy that portion and insert it to your docker-compose file … heh complicated , but like python RE < does find / match stuff, then it needs to drop it into that path with something like a quay.io….miner:{xx} < being what the script finds from quay repo

the alternative is just having the docker-compose file image linked to the “latest” pull link that would solve your issues with no code or scripting

*the script most likely needs to insert that into a docker-compose template, which then the script can execute and creates a real docker-config.yml file that it then runs , heh that’s part of the price tag on the miners, is the manufacturers software update feature , otherwise you got to figure it out on your own, hope that helps…

[arduino43]

You are binding the sys.config wrong here:

--mount type=bind,source=/home/pi/Helium/overlay/docker.config,target=/opt/miner/releases/2021.09.27.0/sys.config

Do you know the correct binding? Thanks for the response!

[arduino43]

Might need to make that into a docker-compose file, with some variables in the run command that matches the version to the binding point for that sys.config file , if it’s not implemented in the miners update mechanism . 🤷‍♀️ Just a thought . For future proofing your auto update script … most manufacturers only update on _GA releases or latest, so just the date would be the part that changes or varies … on fleet managed miners I noticed that the script has some [{version.xxx}] which links to the other parts of the docker-compose file where -bind ..sys.config:../sys.config is located and /or other version specific docker variables

*but just having it in docker-compose and using docker-compose up name/image should plug that in for you that way your sys.config: part is static and the :../sys.config part is from the image itself , I could be totally off bases here tho…

Like when your miner restarts it should run that docker-compose file , or every x amount of time have a script that runs to check the current quay.io repo and finds / matches / compares your current _GA release to the one in the official repo, and does whatever docker stop service name , docker rm service name , and the script needs to copy that portion and insert it to your docker-compose file … heh complicated , but like python RE < does find / match stuff, then it needs to drop it into that path with something like a quay.io….miner:{xx} < being what the script finds from quay repo

the alternative is just having the docker-compose file image linked to the “latest” pull link that would solve your issues with no code or scripting

*the script most likely needs to insert that into a docker-compose template, which then the script can execute and creates a real docker-config.yml file that it then runs , heh that’s part of the price tag on the miners, is the manufacturers software update feature , otherwise you got to figure it out on your own, hope that helps…

Thanks so much for the response!